Perhaps, I am making a big deal over a small theoretical issue, but I
don't think I am. In my mind, if you're ever in a situation to
guess/predict/brute force a valid and current session token, there are a
range of session hijacking possibilities that are all potentially bad.
If you'd really like to learn more about why it is a potentially big
deal, I'm providing some references:
Credential/Session Prediction
http://www.webappsec.org/projects/threat/classes/credential_session_prediction.shtml
"iDefense: Brute-Force Exploitation of Web Application Session ID's", By
David Endler - iDEFENSE Labs
http://www.cgisecurity.com/lib/SessionIDs.pdf
"Best Practices in Managing HTTP-Based Client Sessions", Gunter Ollmann
- X-Force Security Assessment Services EMEA
http://www.technicalinfo.net/papers/WebBasedSessionManagement.html
[see: Brute Forcing]
<http://www.itsecurity.com/papers/iss9.htm>
"A Guide to Web Authentication Alternatives", Jan Wolter
http://www.unixpapa.com/auth/homebuilt.html
Also see sections A5/A7/A8 of the OWASP Top 10 for 2007
http://www.owasp.org/index.php/Top_10_2007
A5 - Cross Site Request Forgery (CSRF)
<http://www.owasp.org/index.php/Top_10_2007-A5>
http://www.owasp.org/index.php/Top_10_2007-A5
A7 - Broken Authentication and Session Management
<http://www.owasp.org/index.php/Top_10_2007-A7>
http://www.owasp.org/index.php/Top_10_2007-A7
A8 - Insecure Cryptographic Storage
<http://www.owasp.org/index.php/Top_10_2007-A8>
http://www.owasp.org/index.php/Top_10_2007-A8
* *Do not* *create cryptographic algorithms*. Only use approved
public algorithms such as AES, RSA public key cryptography, and
SHA-256 or better for hashing.
* *Do not* *use weak algorithms*, such as MD5 / SHA1. Favor safer
alternatives, such as SHA-256 or better.
PDF: http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf
Thanks,
Minoo Hamilton
Mark Thomas wrote:
Filip Hanik - Dev Lists wrote:
you don't need to lobby, simply create a patch in Bugzilla
Although it is likely to get ignored / end up as WONTFIX. I don't see
what the security issue is here. How does an MD5 collisions affect the
security of the session ID?
Mark
Minoo Hamilton wrote:
I'd like to re-raise an issue, since I didn't get too much of a
response, originally. Who can I talk to to lobby to get the default
behavior of using MD5 session token hashes to change? If you weren't
aware of it, there has been a recent and highly-publicized breaking of
SSL, by creating a rogue certificate authority, using collisions in
MD5. Creating collisions in MD5 are no longer a "highly theoretical"
attack for potential session hijacking. I'd very much like to see the
default behavior of Tomcat session tokens become more secure by
default (possibly SHA-256). I think the default hashing algorithm
should not be a known broken and insecure one.
MD5 considered harmful today
Creating a rogue CA certificate
http://www.win.tue.nl/hashclash/rogue-ca/
Any thoughts?
Thanks,
Minoo Hamilton
Tim Funk wrote:
It is probably due to old code which works just fine when SHA might
not have been "easily available" in all JVM's. (back in 2002?)
So a quick recap for folks ... a session id is generated by
1) Getting a random number
2) Hashing it
3) Converting the hashed bytes to something text [base64] so they fit
in a cookie without extra work
Steps 1-3 are repeated until enough chars are present for the
configured session ID length.
So if an attacker *could* get reverse of the hash - it would be a
random number. SessionId length is configurable - so you could change
your session length to be larger so that mulitple random numbers
become digested. And then keep the session length small enough so
that next hash is not completely concatenated into the id. So at best
the attack has a one full hash plus part of a another hash to work
with. (As of this writing - I cant recall how times digest is called
by default so I'm not sure if a single full hash is in the session
id, or part of one, or multiples)
*** BUT *** If the random number and entropy to get the random number
are "good enough" - hashing is already overkill. But in the case
where the entropy and random number generator are "bad" - hashing
provides another line of defense against determining the current
random number and then being able to guess the next random number.
-Tim
Minoo Hamilton wrote:
Greetings Tomcat Developers,
I am a security researcher who has recently been getting into
Apache Tomcat security hardening. Forgive me if my failed attempt
to find the answer to this question has brought me prematurely to
this list. I've been trying to figure out why the Apache Tomcat 6
Manager component defaults to using the MD5 hash algorithm for
session token creation. It has long been seen as a questionable
hash algorithm due to known collisions. Why not use SHA-1 by
default, instead? Has anybody looked at SecureRandom which uses
SHA-1? I assume eventually this should be SHA-2, as SHA-1 is coming
under increasing fire, as well.
From: http://tomcat.apache.org/tomcat-6.0-doc/config/manager.html
|algorithm|
Name of the /Message Digest/ algorithm used to calculate session
identifiers produced by this Manager. This value must be supported
by the |java.security.MessageDigest| class. If not specified, the
default value is "MD5".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
