Date: Sat, 16 Feb 2008 19:10:03 +0300
From: 3APA3A <3APA3A@...URITY.NNOV.RU>
To: Peter Watkins <peterw@....net>
Cc: bugtraq@...urityfocus.com
Subject: Re[2]: Apache web server 2.2: htpasswd predictable salt weakness

Dear Peter Watkins,

PW> I don't know how small the salt universe would need to be before
PW> precomputing dictionaries would be worthwhile (vs. having a botnet only work
PW> on crypted passwords already captured), but certainly the obviously weak
PW> srand(time(NULL)) code only helps the black hats. And with modern OSes
PW> providing reasonably good entropy sources, there's little reason not to
PW> "do it right". It's not the worst mistake I've seen, by far not the most
PW> dangerous. But it's sloppy of the Apache Group to have ignored it for half
PW> a decade.

It's  quite  easy.  Precomputing  rainbow table for MD5 crypt with known
salt  is somehow equivalent to MD5 crypt bruteforcing, if you don't mind
about required amount of storage. So, predictable salt and narrowed salt
space  will  have  some impact if salt changes in a time comparable with
time required for bruteforcing. Salt changing once in a second is really
good one, because bruteforcing takes much longer.

The  only  situation I can imagine predictability is significant, is you
can  predict with precision of few seconds a time of password generation
in  a password file you will steal next week/month. In this case you can
start to build rainbow table :)



--Saturday, February 16, 2008, 12:07:10 AM, you wrote to 3APA3A@...URITY.NNOV.RU:

PW> On Fri, Feb 15, 2008 at 08:44:08PM +0300, 3APA3A wrote:

>> PW> As a result:
>> PW>  - Salts created by htpasswd are very predictable. 
>> PW>  - The universe of salts for htpasswd is far less than the MD5 algorithm
>> PW>    provides for -- 29 bits vs. 48, or 0.000191 percent of the range that
>> PW>    should be used for MD5.
>> 
>> As  far  as I understand, salt predictability gives nothing to you. Salt
>> protects  against  rainbow  tables  attacks in case stored passwords are
>> stolen. Salt is stored with password, that is salt is known to attacker.
>> All you need for salt is to be different for different passwords and for
>> different  systems.  That is 175, 176, 177 etc are pretty good salts for
>> sequentially generated passwords in case 175 is apriory unknown.
>> 
>> Salt universe is more important, but 29 bits against 48 is not something
>> scaring.
>> 
>> May be I am missing something?

PW> A naive attacker might look at the Apache APR1 MD5 spec and decide not to
PW> bother precomputing tables for 2^48 salts. But with the htpasswd weakness,
PW> fewer than 2^25 salts are used in an entire year; fewer than 2^21 in a given
PW> month. I can't imagine anybody wasting a botnet's computing resources now on
PW> building 2^48 attack tables, but the more that number drops, the more sense
PW> it would make for someone controlling thousands of machines to work on an
PW> attack table. Got ten thousand machines? If each one builds tables for
PW> about 3400 salts, that's a full year covered. Sure is easier than having each
PW> host work on 28 billion salts. 

PW> I don't know how small the salt universe would need to be before 
PW> precomputing dictionaries would be worthwhile (vs. having a botnet only work
PW> on crypted passwords already captured), but certainly the obviously weak
PW> srand(time(NULL)) code only helps the black hats. And with modern OSes
PW> providing reasonably good entropy sources, there's little reason not to
PW> "do it right". It's not the worst mistake I've seen, by far not the most
PW> dangerous. But it's sloppy of the Apache Group to have ignored it for half
PW> a decade.

PW> One thing that bothers me about this issue is that many developers learn
PW> from reading others' code, and since the Apache Group is held in such high
PW> esteem by so many, the bad srand() code in htpasswd.c is likely to lead some
PW> programmers astray. 

PW> This reminds me of the incident last year with Simson Garfinkel getting all
PW> defensive about an insecure function in some of his source code. Simson didn't
PW> need to fix the code -- as he pointed out, it wasn't actually used in the
PW> final app -- but he didn't bother removing it, either (it's still there
PW> today). Both Simson's behavior then (which I found terribly distasteful --
PW> the demand for a retraction, the smug mocking of the individual who raised the
PW> issue[0]) and the Apache Group's inaction now should serve as reminders that
PW>  1) everybody makes mistakes 
PW> and 
PW>  2) even those with the best reputations sometimes handle mistakes poorly

PW> -Peter

PW> [0]
PW> http://www.securityfocus.com/archive/1/archive/1/467181/100/0/threaded


-- 
~/ZARAZA http://securityvulns.com/
В расчетах была ошибка.  (Лем)

Powered by blists - more mailing lists