Re: [NTSEC] GOOD GRIEF! re:Hack' punches hole in Microsoft NT s (fwd)

[Ray Arachelian <sunder@brainlink.com>]

=====================================Kaos=Keraunos=Kybernetos==============
.+.^.+.|  Ray Arachelian    | "If  you're  gonna die,  die  with your|./|\.
..\|/..|sunder@sundernet.com|boots on;  If you're  gonna  try,  just |/\|/\
<--*-->| ------------------ |stick around; Gonna cry? Just move along|\/|\/
../|\..| "A toast to Odin,  |you're gonna die, you're gonna die!"    |.\|/.
.+.v.+.|God of screwdrivers"|  --Iron Maiden "Die With Your Boots on"|.....
======================== http://www.sundernet.com =========================
  For with those which eternal lie, with strange eons even death may die.


---------- Forwarded message ----------
Date: Thu, 10 Apr 1997 18:10:04 +0000
From: Alan C. Ramsbottom <acr@als.co.uk>
To: Jos Visser <josv@osp.nl>
Cc: ntsecurity@iss.net
Subject: Re: [NTSEC] GOOD GRIEF! re:Hack' punches hole in Microsoft NT s

> I am currently reviewing the write-up to include the newest 
> relevant information.I had considered the possibility that you could
> brute-force attack the password space. However, the possible number
> of passwords is quite bi. Let us assume that the average password
> contains about 40 bits of information, the entie plausible passowrd
> space then is 2^40 = 1099511627776 possible passwords. Suppose you
> could hash and store 1,000,000 passwords each secondthe brute-force
> approach takes more then 12 days to calculate and requires about
> 16 GB diskspace to store the results (uncompressed).
> 
> Could you please point me the errors in my calculations so I can fix
> the article asap?

Certainly..

Theoretically, for a "complete" brute-force attack on the DES hashes 
we need to consider a 56 bit ( 7 chars x 8 bits) password space. This 
space is the maximum we have to worry about because of the 14 char 
password to two independent 7 char DES keys split. The timing 
overheads of checking both the 8 char hashes during a brute-force 
attack are relatively trivial.

Now the crunch. Theory is fine, but in the real world there are 
constraints on the password space - in reality it gets much 
smaller e.g. 

  1) chars below 0x20 can't be entered in the password dialogue box 

  2) alphas are uppercased prior to being used as DES keys so you 
     can also ignore 0x61 to 0x7A. Correcting the case of any alphas 
     after finding a LanMan password is a quick and relatively 
     trivial task using MD4.

That much is guaranteed even if you (reasonably in 99.99% of cases) 
start throwing away characters that are difficult to quickly enter on 
a keyboard e.g. anything that needs an ALT-0-nnn sequence to enter 
(more or less everything above 0x80 subject to country).

Finally 3-4Gb disks are now relatively inexpensive so the amount of 
diskspace required for a precomputed attack is not much of an 
obstacle. It has been also been suggested that if you are short of 
diskspace you could always keep sequentially sorted sections of the 
precomputed file on a backup tape. Then, as you mention above there 
is compression. 

My main point is that you don't need an exceptionally fast machine or 
impossible amount of disk space. If I can write code to do this then 
you can guarantee that other people have, and that theirs is both 
cleverer and runs faster ;-)

"Greater password complexity" is a good idea for many reasons but 
not much help in this specific case. The LanMan hashes are simply 
far too easy to attack and you should concentrate your defences in 
preventing access to them. 

Finally, we need to put this in proper perspective - this attack and 
the associated IE 3.0 SMB and NTLM problems can EASILY BE AVOIDED 
with a few simple network administration policies.

--Alan--
acr@als.co.uk

PS. Haven't seen my original message turn up on NTSecurity yet so I 
    don't suppose this will.