RE: [Full-disclosure] Session Token Remains Valid After Logout in IBM Lotus Domino Web Access

["Ferguson, David" <Dave.Ferguson@xxxxxxxxxxxxxxxxxxx>]

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:midnitrcr@xxxxxxxxx] 
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
<http://www-1.ibm.com/support/docview.wss?rs=463&uid=swg21245589> 
&uid=swg21245589 ) on the subject.
 
Dave
 
  _____  

From: Trey Keifer [mailto:midnitrcr@xxxxxxxxx] 
Sent: Tuesday, September 12, 2006 10:58 AM
To: Ferguson, David
Cc: full-disclosure@xxxxxxxxxxxxxxxxx
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 < Dave.Ferguson@xxxxxxxxxxxxxxxxxxx
<mailto:Dave.Ferguson@xxxxxxxxxxxxxxxxxxx> > 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
<http://www-1.ibm.com/support/docview.wss?rs=463&uid=swg21245589> 
&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/
 
 

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/