tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Minoo Hamilton <mi...@forkbolt.net>
Subject Re: Why are manager session tokens generated with MD5 by default?
Date Tue, 06 Jan 2009 02:00:13 GMT
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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>>
>>>>
>>>>         
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>>>       
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>     
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>   


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message