Re: Websphere cookie/sessionid predictable

[Arun Kumar <akumar () austin ibm com>]

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 
unsupported
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
http://www-
4.ibm.com/software/webservers/appserv/support.html
.
After applying the aforementioned patches to 3.02 or 
3.5, the session
generation algorithm is identical to that of Websphere 
Application
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
UnauthorizedSessionRequestException.

--Arun Kumar
IBM
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) (66.38.151.26)
>  by mail.securityfocus.com with SMTP; 20 Sep 
2001 16:01:28 -0000
> Received: from lists.securityfocus.com 
(lists.securityfocus.com [66.38.151.19])
>       by outgoing.securityfocus.com (Postfix) 
with QMQP
>       id 319048F2B9; Thu, 20 Sep 2001 
09:55:05 -0600 (MDT)
> Mailing-List: contact bugtraq-
help () securityfocus com; run by ezmlm
> Precedence: bulk
> List-Id: <bugtraq.list-id.securityfocus.com>
> List-Post: <mailto:bugtraq () securityfocus com>
> List-Help: <mailto:bugtraq-
help () securityfocus com>
> List-Unsubscribe: <mailto:bugtraq-
unsubscribe () securityfocus com>
> List-Subscribe: <mailto:bugtraq-
subscribe () securityfocus com>
> Delivered-To: mailing list 
bugtraq () securityfocus com
> Delivered-To: moderator for 
bugtraq () securityfocus com
> Received: (qmail 2797 invoked from network); 20 
Sep 2001 11:14:28 -0000
> Message-ID: 
<98A3855A9087D411952F00508B61BD400268C688
@ZAJNBNT006>
> From: "Dawes, Rogan (ZA - Johannesburg)" 
<rdawes () deloitte co za>
> To: "'marc () suse de'" <marc () suse de>, 
bugtraq () securityfocus com
> Subject: RE: Websphere cookie/sessionid 
predictable
> 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"
>
> Hi,
>
> 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
> TWGYLZIAAACVDQ3UUSZQV2I        
        10:27:12
> TWGY0WYAAACVFQ3UUSZQV2I        
        10:27:13
> TWGZNZAAAACVHQ3UUSZQV2I        
        10:27:14
> TWG0BUYAAACVJQ3UUSZQV2I        
        10:27:15
> TWG0VIAAAACVLQ3UUSZQV2I        
        10:27:16
> TWG1ICIAAACVNQ3UUSZQV2I        
        10:27:17
> TWG111YAAACVPQ3UUSZQV2I        
        10:27:18
>          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?
>
> Rogan
>
> -----Original Message-----
> From: marc () suse de [mailto:marc () suse de]
> Sent: 19 September 2001 07:44
> To: bugtraq () securityfocus 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)
>
> INTRO
> 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
> TWGYLZIAAACVDQ3UUSZQV2I        
        10:27:12
> TWGY0WYAAACVFQ3UUSZQV2I        
        10:27:13
> TWGZNZAAAACVHQ3UUSZQV2I        
        10:27:14
> TWG0BUYAAACVJQ3UUSZQV2I        
        10:27:15
> TWG0VIAAAACVLQ3UUSZQV2I        
        10:27:16
> TWG1ICIAAACVNQ3UUSZQV2I        
        10:27:17
> TWG111YAAACVPQ3UUSZQV2I        
        10:27:18
>   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
> char
> * 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 
second.
> 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.
>
>
> THE RISK
> 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
>
>
> THANKS
> to the IBM websphere team, which fixed the bug 
pretty fast for the customer.
> Greets,
>       Marc
> --
>   E@mail: marc () suse 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: 
http://www.suse.de/security
>