Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
From: Arun Kumar (akumaraustin.ibm.com)
Date: Fri Sep 28 2001 - 17:34:48 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    Hi Everyone,

    It is critically important to note that the reported issue
    of session ID
    generation is NOT an issue in any version of
    Websphere Application
    Server 4.X. It has been reported that PQ47663V302
    should be applied
    to Websphere Application Server V4.X. Please do
    not follow these
    directions. This patch is not supported on
    Websphere Application
    Server 4.X, hence any server with this patch is in an
    configuration. The issue is, however, a reasonably
    accurate description
    of a known and resolved issue in 3.X versions of
    Websphere Applicaton Server.
    PQ47663V302 is a resolution to this issue on any
    release of Websphere
    Application Server V3.02. There are versions of this
    patch available
    for 3.5.1, 3.5.2 and 3.5.3 as well. These fixes have
    been available
    since 5/1/2001. The site to obtain these from is
    After applying the aforementioned patches to 3.02 or
    3.5, the session
    generation algorithm is identical to that of Websphere
    Server V4.X. This algorithm is essentially totally
    random and is based
    on JCE which is widely recognized as one of the
    most sophisticated
    random ID generators.

    Also, we do not recommend relying on the session ID
    alone as a form of
    securing session data. If security is enabled and the
    accessed URLs
    are protected, the user must be authenticated to
    proceed. Websphere
    session and security code have been integrated such
    that each session
    access compares the authenticated user with the
    owner of the session.
    If these do not match, the session access is rejected
    with an

    --Arun Kumar
    WebSphere Service and Support.

    >Received: (qmail 29550 invoked from network); 20
    Sep 2001 16:01:28 -0000
    >Received: from outgoing2.securityfocus.com
    (HELO outgoing.securityfocus.com) (
    > by mail.securityfocus.com with SMTP; 20 Sep
    2001 16:01:28 -0000
    >Received: from lists.securityfocus.com
    (lists.securityfocus.com [])
    > by outgoing.securityfocus.com (Postfix)
    with QMQP
    > id 319048F2B9; Thu, 20 Sep 2001
    09:55:05 -0600 (MDT)
    >Mailing-List: contact bugtraq-
    helpsecurityfocus.com; run by ezmlm
    >Precedence: bulk
    >List-Id: <bugtraq.list-id.securityfocus.com>
    >List-Post: <mailto:bugtraqsecurityfocus.com>
    >List-Help: <mailto:bugtraq-
    >List-Unsubscribe: <mailto:bugtraq-
    >List-Subscribe: <mailto:bugtraq-
    >Delivered-To: mailing list
    >Delivered-To: moderator for
    >Received: (qmail 2797 invoked from network); 20
    Sep 2001 11:14:28 -0000
    >From: "Dawes, Rogan (ZA - Johannesburg)"
    >To: "'marcsuse.de'" <marcsuse.de>,
    >Subject: RE: Websphere cookie/sessionid
    >Date: Thu, 20 Sep 2001 13:13:37 +0200
    >MIME-Version: 1.0
    >X-Mailer: Internet Mail Service (5.5.2653.19)
    >Content-Type: text/plain;
    > charset="iso-8859-1"
    >I did a similar analysis with an older version of
    WebSphere (3.2) for a
    >client, and have one comment to make that maybe
    you didn't pick up (or may
    >have been fixed in the interim):
    >SessionID TIME
    > yyy
    >What I found was that the section marked "yyy"
    incremented by 2 for each
    >REQUEST made, not by time. So it is trivial to make
    a request every second,
    >making sure that the next number is only two from
    what your last number was.
    >If it was not, then someone ELSE has requested a
    session, and you should
    >begin brute forcing the interval between your
    previous and current
    >sessionids. The shorter the interval between
    requests, the smaller the space
    >to brute force, obviously.
    >Perhaps someone can check if this patch also fixes
    that property of the
    >sessionid generation?
    >-----Original Message-----
    >From: marcsuse.de [mailto:marcsuse.de]
    >Sent: 19 September 2001 07:44
    >To: bugtraqsecurityfocus.com
    >Subject: Websphere cookie/sessionid predictable
    >Hi folks,
    >about three weeks ago, I discovered a hole in IBM's
    websphere 4.0 session ID
    >generation. Over a week ago, IBM made a fix for this
    available, so here is
    >the information about the vulnerability:
    >(everybody who don't want to read about this
    vulnerability and just want to
    >know the patch info: install the eFix PQ47663V302)
    >websphere can generate sessionids which are put
    into cookies for users, to
    >be able to supply user tracking, e.g. user
    authenticates with userid and
    >password, and access to data is checked by
    checking if the sessionid is
    >authenticated or not.
    >THE BUG
    >during a security assessment for a bank, I collected
    several sessionids and
    >they did not look that random to me ...
    >SessionID TIME
    > xxxx y
    >You can see that for seven requests, only 5
    characters changed, and:
    >* the characters A-Z and 0-9 are used, hence 36
    combinations possible per
    >* the sessionid is based on two counters which are
    counted up, the rest of
    > the string seems to be fixed.
    >* the first counter (xxxx) seems to count
    milliseconds (TWGxxxx), but
    > counts a bit too slow (see seconds 15 and 16,
    where both 1st rows of the
    > counters start with a 0). well, to cut a long story
    short, it is really
    > a counter which increases 65536 times per
    second and is then encoded to
    > the A-Z0-9 format.
    >* If you collect many sessionids (I collected 1000,
    it's obvious then),
    > you'll see that the the least signifcant char of the
    first counter are 95%
    > of the time showing a Y, I, A or Q. The reason for
    that is (my guess) that
    > the clock of the machine only can increase 7.500-
    10.000 times instead of
    > 65536 because it's not a realtime clock and the
    server type is not a cray
    >* The second counter (y) is increasing by two every
    >The counters are in fact longer than 4, but this is the
    visible changes in
    >the example above.
    >Then the guess was that the fixed strings may be
    based on the IP of the
    >client. So I checked with different IP addresses, but
    no difference in the
    >fixed strings of the sessionID.
    >If someone knows the time of the connect to the
    server (even with SSL
    >encrypted) an attacker can issue requests with
    changing sessionids until
    >it's the correct one. If an attacker just wants to have
    any user data, he
    >can constantly try some guessing.
    >As the first counter only has 7.500-10.000 values
    per second, and the
    >seconds counters just increases approx. once per
    second (or perhaps per
    >request), the sessionid can have 7.750 to 10.500
    different values.
    >If a user is normaly connected for 15 minutes after
    authentication to an
    >eCommerce system (and does not forget to logout,
    otherwise the time is
    >extended by the session timeout). As an attacker is
    likely to succeed after
    >50% of the keyspace, he needs 3.875 to 5.250
    attempts, so 4 to 5 requests
    >per second are enough.
    >Two customers were using the sessionids for the
    security of their eCommerce
    >system ... we are not talking about some weird
    feature nobody uses.
    >Short: it is an easy and likely attack.
    >THE FIX
    >install eFix PQ47663V302 and feel better
    >to the IBM websphere team, which fixed the bug
    pretty fast for the customer.
    > Marc
    > Email: marcsuse.de Function: Security
    Research and Advisory
    > PGP: "lynx -source
    http://www.suse.de/~marc/marc.pgp | pgp -fka"
    > Key fingerprint = B5 07 B6 4E 9C EF 27 EE 16 D9
    70 D4 87 B5 63 6C
    >Private: http://www.suse.de/~marc SuSE: