full-disclosure - Re: stompy the session stomper

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 27 Jan 2007 16:29:08 -0500
From: Simon Smith <simon@...soft.com>
To: Michal Zalewski <lcamtuf@...ne.ids.pl>, <webappsec@...urityfocus.com>,
	<pentest@...urityfocus.com>
Cc: Untitled <full-disclosure@...ts.grok.org.uk>, bugtraq@...urityfocus.com
Subject: Re: stompy the session stomper - tool availability

Very cool.


On 1/27/07 7:29 AM, "Michal Zalewski" <lcamtuf@...ne.ids.pl> wrote:

> Hi all,
> 
> I'd like to announce the availability of 'stompy', a free tool to perform
> a fairly detailed black-box assessment of WWW session identifier
> generation algorithms. Session IDs are commonly used to track
> authenticated users, and as such, whenever they're predictable or simply
> vulnerable to brute-force attacks, we do have a problem.
> 
> [ The reason I'm cc:ing BUGTRAQ is that this tool already revealed several
>   new, potential weaknesses in application platforms, and can be readily
>   used to find more - for example, it is my impression that BEA WebLogic
>   and Sun Java System Web Server both have problems with their JSESSIONIDs
>   [1]; proprietary solutions by some of the larger portals / e-commerce
>   sites didn't always earn a passing grade, either. ]
> 
> Why bother?
> ===========
> 
> Some session ID cookie generation mechanisms are well-studied and
> well-documented, and believed to be cryptographically secure (example:
> Apache Tomcat, PHP, ASP.NET builtins). This is not necessarily so for
> certain less researched enterprise web platforms - and almost never so for
> custom solutions that are frequently implemented inside the web
> application itself.
> 
> Yet, while there are several nice GUI-based tools designed to analyze HTTP
> cookies for common problems (Daves' WebScarab, SPI Cookie Cruncher,
> Foundstone CookieDigger, etc), they all seem to rely on very trivial, if
> any, tests when it comes to unpredictability ("alphabet distribution" or
> "average bits changed" are top shelf); this functionality is often not
> better than a quick pen-and-paper analysis, and can't be routinely used to
> tell a highly vulnerable linear congruent PRNG (rand())  from a
> well-implemented MD5 hash system (/dev/urandom).
> 
> As far as I can tell, today's super-bored pen-testers can at best collect
> data by hand, determine its encoding, write conversion scripts, and then
> feed it to NIST Statistical Test Suide or alike - but few will.
> 
> What's cool?
> ============
> 
> In order to have a fully automated, hands-off tool to reliably detect
> anomalies that are not readily apparent at a first glance, I devised an
> utility that:
> 
>   - Automatically finds session IDs encoded as URLs, cookies, and
>     in form inputs, then collects a statistically significant sample
>     of data,
> 
>   - Determines alphabet structure to transparently handle base64,
>     uuencode, base32, hex, and any other sane encoding scheme
>     without user intervention,
> 
>   - Translates the data to isolated time-domain bitstreams to
>     examine how SID bits at each position change in time,
> 
>   - Runs a suite of FIPS-140-2 PRNG evaluation tests on the sample,
> 
>   - Runs an array of n-dimensional phase space tests to find
>     deterministic correlations, PRNG hyperplanes, etc, etc.
> 
> Of course, the tool cannot prove the correctness of an implementation, and
> it is possible to devise predictable, cryptographically unsafe PRNGs that
> would pass these tests; still, the tool can find plenty of problems and
> oddities.
> 
> Well, that's it. For more, see the included README file. The application,
> in a fairly decent shape (not a wobbly PoC) and tested under Linux,
> FreeBSD, and CYGWIN, can be downloaded here:
> 
>   http://lcamtuf.coredump.cx/stompy.tgz
> 
> Cheers,
> /mz
> 
> [1] BEA Weblogic test output: http://lcamtuf.coredump.cx/BEA.log; in
>     response to WebScarab analysis, BEA stated some time ago that the
>     beginning of the identifier might be deterministic at MSB positions:
>     
> http://dev2dev.bea.com/blog/neilsmithline/archive/2006/03/jsessionid_valu_1.ht
> ml
>     ...but 'stompy' output seems to clearly indicate that all the
>     data exhibits strong biases, irregularities, and correlation
>     patterns, and as such, the randomness of their "very large random
>     number" is questionable at best.
> 
> .
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/