Trey,
I understand what you mean about a design
trade-off. In this case I believe
IBM has a conflicting design. They
clear the cookie, which makes the user appear to be logged out of all
applications. However, they leave
the token valid on the server, which doesn’t serve any useful purpose.
-Dave
From: Trey Keifer
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 12, 2006 11:34
AM
To: Ferguson, David
Subject: Re: [Full-disclosure]
Session Token Remains Valid After Logout in IBM Lotus Domino Web Access
> The problem I see is that the user explicitly chose to log out.
The issue is when it comes to SSO, you don't know if the user wanted to log out
of *that* application or *all applications* and that is the "design tradeoff"
I mentioned in my response. Some vendors choose to invalidate all sessions,
some make attempts to invalidate the specific instances. It is against
best-practices in single-instance application design, but it is an immutable
logic problem in SSO application design. The app can't guess what the user
intends to do.
On 9/12/06, Ferguson, David wrote:
The problem I see is that the user explicitly
chose to log out. I have tested other SSO applications where if you log
out of the application, then the token is invalidated and you become
unauthenticated in all of the apps that are part of the SSO group. To me
that is the correct behavior. In fact I would say that IBM agrees with
that, because their software goes to some extent to delete the cookie from the
browser so that if the user tries to access any of the apps after logging out,
he is given a login page to re-authenticate. IBM believes it is valid and
has released a technote (http://www-1.ibm.com/support/docview.wss?rs=463&uid=swg21245589
) on the subject.
Dave
From: Trey Keifer [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, September 12, 2006
10:58 AM
To: Ferguson, David
Cc: [email protected]
Subject: Re: [Full-disclosure]
Session Token Remains Valid After Logout in IBM Lotus Domino Web Access
How is this a vulnerability? this is a common design
trade-off of SSO tokens. In order to support the user opening and closing
multiple applications and not requiring them to login again to individual
applications (which is the point of SSO) they must invalidate the token in
specific instances while leaving a more encompassing SSO token valid until a
defined timeout.
You also say you didn't test the difference between SSO mode and "Single
Server" mode. It seems to me that this would be a key test, is it possible
that this functionality *does* change when the server knows it does not have to
worry about session management across multiple instances?
Furthermore, this alert requires access to the token (which we are left to make
assumptions about since no details on length or algorithm were included) which,
unless the application only supports HTTP, is a pretty obvious issue and not
even worth reporting. If we include web applications that don't invalidate
sessions on the server side as reportable instances of vulnerabilities, then we
open the flood-gates for worthless advisories.
On
9/12/06, Ferguson, David < [EMAIL PROTECTED]> wrote:
I.
SYNOPSIS
Title: Session Token Remains Valid After Logout in IBM Lotus Domino Web Access
7.0.1
Release Date: 09/12/2006
Affected Application: IBM Lotus Domino Web Access 7.0.1
(versions prior to 7.0.1 were not tested but may still be vulnerable).
Nominal Severity: Low
Severity If Successfully Exploited: High
Impact: Attacker impersonates legitimate user
Mitigating Factors: Requires discovery of a valid LtpaToken to exploit.
Discovery: Dave Ferguson, Security Consultant, FishNet Security
Initial Notification of Vendor: 08/28/2006
Permanent Advisory Location:
http://www.fishnetsecurity.com/csirt/disclosure/ibm
II. EXECUTIVE SUMMARY
Vulnerability Overview:
In Lotus Domino Web Access (DWA) 7.0.1, the session token used to identify the
user (called
"LtpaToken") is not invalidated on the server upon user
logout. The cookie is removed from the
browser, but the token continues to be recognized by the server until a
configurable expiration time
is reached.
Attack Overview:
The most likely attack scenario is session hijacking or session
stealing. Knowing a valid session
token would allow a malicious person to access all functionality of the web
application (except
changing password, which requires knowledge of the current
password). Lotus DWA is a personal
information management application that includes e-mail, calendar, and task
management. By hijacking
(or stealing) a session, an attacker is able to impersonate a legitimate user,
and can read the user's
e-mail, send e-mail as the user, or change the user's preference settings.
III. TECHNICAL DETAIL
Vulnerability Details:
When a Lotus DWA user logs in, a cookie called "LtpaToken" is set
into the browser and is used
throughout the session to uniquely identify the user. When a user
logs out of DWA, the cookie is
cleared from the browser, but this action has no effect on the
server. The token eventually expires
on the server after some configurable amount of time. A user who
explicitly logs out of DWA may have
a false sense of security. The LtpaToken cookie in his browser is
deleted, but the token is still
valid from the server's perspective and can be used by an attacker if he can
discover it. Best
practices in web application security would call for the LtpaToken to be
invalidated/destroyed at
logout time. Note that the vulnerability described here was observed
with Session authentication
under the Domino Web Engine tab set to "Multiple Servers
(SSO)". The same behavior may occur with the
"Single Server" configuration as well, but this was not tested.
The "LtpaToken" described here is a component in IBM's Lightweight
Third-Party Authentication (LTPA)
technology. The LTPA technology was designed to be a defacto
standard across the IBM product family.
LTPA is used in both IBM WebSphere and Lotus Domino products and allows for
single sign-on across
physical servers. For example, Domino can recognize and accept LTPA
tokens created by WebSphere. For
more information, please see the IBM redpaper at
http://www.redbooks.ibm.com/redpieces/pdfs/redp4104.pdf
IV. MITIGATING FACTORS
Keeping the LtpaToken confidential is critical to mitigating this
issue. An attacker must be able to
discover a valid LtpaToken before it expires. Because the LtpaToken
is sent with each request, Lotus
DWA should be deployed as a secure application. This means an SSL
certificate should be installed on
the server so that encrypted (https) communication between the browser and the
server occurs.
Cross-site scripting (XSS) is a common application-level attack that can be
used to steal cookies such
as LtpaToken. Running the application under SSL does not hinder XSS
attacks. Fortunately, Lotus
Domino includes a module called Active Content Filter that is highly effective
at removing potentially
harmful scripts in e-mail messages. Active Content Filtering should
be turned on.
Finally, the overall risk level can be lowered by enabling an idle session
timeout in addition to the
absolute expiration time. Ideally, from an application security
perspective, the idle (inactivity)
timeout would be much smaller than the absolute expiration. Be aware
that the increased security from
having small timeout values may negatively affect end-user satisfaction in the
application.
V. VENDOR RECOMMENDED ACTIONS
IBM recommends running Lotus DWA run under SSL and using a token expiration
time of 30 minutes.
Please see IBM technote #1245589:
http://www-1.ibm.com/support/docview.wss?rs=463&uid=swg21245589
VI. CONTACT
You can reach the author of this advisory at:
dave.ferguson[at]fishnetsecurity(dot)com
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
|
