Bugtraq mailing list archives
Re: Websphere cookie/sessionid predictable
From: Arun Kumar <akumar () austin ibm com>
Date: 28 Sep 2001 22:34:48 -0000
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
Current thread:
- Websphere cookie/sessionid predictable Marc Heuse (Sep 19)
- Re: Websphere cookie/sessionid predictable Job de Haas (Sep 27)
- <Possible follow-ups>
- RE: Websphere cookie/sessionid predictable Dawes, Rogan (ZA - Johannesburg) (Sep 20)
- Re: Websphere cookie/sessionid predictable Arun Kumar (Sep 29)