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: marcat_private [mailto:marcat_private]
Sent: 19 September 2001 07:44
To: bugtraqat_private
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: marcat_private 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
This archive was generated by hypermail 2b30 : Thu Sep 20 2001 - 09:04:51 PDT