lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b017de10609120857g2b8b040bn40a3eb0a7c85b7ac@mail.gmail.com>
Date: Tue, 12 Sep 2006 10:57:56 -0500
From: "Trey Keifer" <midnitrcr@...il.com>
To: "Ferguson, David" <Dave.Ferguson@...hnetsecurity.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: 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@...hnetsecurity.com> 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/
>

Content of type "text/html" skipped

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ