[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <45C77A78.2080902@gmail.com>
Date: Mon, 05 Feb 2007 20:42:00 +0200
From: Amit Klein <aksecurity@...il.com>
To: NGSSoftware Insight Security Research <nisr@...software.com>
Cc: bugtraq@...urityfocus.com, vulnwatch@...nwatch.org
Subject: Re: Jetty Session ID Prediction
NGSSoftware Insight Security Research wrote:
> =================
> Technical Details
> =================
>
> java.util.random implements a linear congruential generator, of the
> following form:
>
> synchronized protected int next(int bits) {
> seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1);
> return (int)(seed >>> (48 - bits));
> }
>
> Jetty generates a 64-bit session id by generating two 32-bit numbers in
> this way, so we end up with an encoded 64-bit integer. By decoding the
> integer and splitting it into its two component 32-bit integers, we can
> easily brute-force the generator's internal state.
So it outputs the full 64 bit integer (encoded), huh? consider yourself
lucky ;-)
With Apache JServ, I had to deal with a session ID constructed in a
similar manner, yet only the last 6 symbols were output (~31 bits out of
the 64).
You can read about this in my "Hacking Web Applications Using Cookie
Poisoning" (April 2002) -
http://www.cgisecurity.com/lib/CookiePoisoningByline.pdf
Apache JServ is "example #2" in that text. You may find part of my
analysis relevant to this (Jetty) case as well (BTW - do you plan to
make your tool/source available?)
Regards,
-Amit
Powered by blists - more mailing lists