No information is available for this file.
c3b43ef16f1296dee5d3be994b8ae7abdab8bd9974318ac4edae140d0a1d0660 A L0phtCrack Technical Rant
Date: Thu, 24 Jul 1997 10:24:37 -0400
From: Who cares what the hell goes into a Gecos field anyway!
To: BUGTRAQ@NETSPACE.ORG
Subject: Windows NT rantings from the L0pht
I didn't ask to be cc'd into the rantings of the MS Borg Marketing Juggernaut but
since I'm here... I find this hillarious. The people at MS should know better. I haven't
been following this thread tremendously but I've seen bit's and pieces. Recently
there was an attrocious article in WindowsNT magazine, where they stated it would
take 5000 or so years to break the passwords; thus put policy in place to have users
change their passwords every 2500 years. HELLO? I think these people aren't
getting it. Let's shed some light on things shall we?
1. Thank you very little MS for dropping any reference to the l0pht, hobbit, or myself
in reference to your recent LM-Hash fix. If this is how you "correspond" with people
who point out problems to you it's no wonder that people prefer to release things to
the public instead of your "proper" channels.
2. MS agrees that the LM hash is a horrible implementation from a security
standpoint. They respond with: "well we didn't write the protocol that was IBM".
3. When MS had the chance to do things a different way (ie Network
challenge/response obfuscation on NT boxes) they implemented it based upon LM
techniques to break up components (see #2).
4. The LM-hash fix works great if you don't have anything but NT machines on your
network. If you want to continue being "productive" with your win95 machines it is
my understanding that you "do it insecurely" or you are S.O.L.5. Few places are
running "nothing but NT" (ie just about everyone has 95 or WfW boxes if MS has
already gotten their foot in the door).(see #4)
5. MS can't swallow their pride enough to say "oops", even in technical circles
where they don't have to worry about the general public mis-interpreting things.
6. For the LM hash you only have to break 7 characters, not 14!
7. MS keeps talking about the NT hash being so secure while refusing to talk about
how weak the LM hash is. Guess what, you probably won't be able to use the
"added security" of the NT hash on your network. Why keep talking about something
people can't use?
8. Even though the NT hash spec says you can have up to 128 charpasswords, I'd
really like someone to show me how they can type more than 14 characters into
UserManager before it starts Beep-Beep'ing at them.
9. We demonstrate up front with proof of concept code in L0phtcrack v1.0, and
L0phtcrack v1.5 that the following is indeed the case. For those that don't know,
L0phtcrack v1.5 will attack the challenge response done over the network. The
reason we came out with this was that the SYSKEY "fix" that MS came out with only
managed to emasculate the ADMINISTRATOR and not address the actuall problem.
Can we say "save face"? I knew we could. L0phtcrack v1.5 is available for FREE
from http://www.L0pht.com (that's a ZERO after the 'L', not an 'o') . It comes with
source so you can build it on just about any platform. It is proof-of concept code
and thus could be sped up tremendously.
L0phtCrack 2.0 is sped up and includes the network sniffer.
Now, let's rip apart why it is so trivial to go through the LM hash on the network.
And then talk about why the NT hash doesn't matter.
-------------------------- -----------------------------
| 16byte LM hash | | 16byte NT hash (md4) |
-------------------------- -----------------------------
We already know that you only have to go through 7 characters to retrieve
passwords (up to 14 chars in length) in the LM hash, and that since there is no
salting being done, constants show up all over the place giving away too much
information and speeding up attacks tremendously.
-------------------------------------------------
| 1st 8bytes of LMhash | second 8bytes of LMhash |
-------------------------------------------------
1st 8 bytes are derived from the first seven characters of the passwordand the
second 8 bytes are derived from the 8th through 14th characters of the password. If
the password is less than 7 characters then the second half will always be:
0xAAD3B435B51404EE.
Let's assume for this example that the users password has a LM hash of
0xC23413A8A1E7665fAAD3B435B51404EE (which I'll save everyone
thenanosecond it would have taken for them to plug this into L0phtcrack and have it
tell them the password is "WELCOME").
Here's what happens to this hash on the network:
-------- --------
| A | <______________| B |
| | | |
-------- --------
B sends an 8 byte challenge to A. (assume 0x0001020304050607) Machine A takes
the hash of 0xC23413A8A1E7665fAAD3B435B51404EE and adds 5 nulls to it, thus
becoming 0xC23413A8A1E7665fAAD3B435B51404EE0000000000.
The string 0xC23413A8A1E7665fAAD3B435B51404EE0000000000 is broken into
three groups of 7:C23413A8A1E766 5fAAD3B435B514 04EE0000000000 The 7 byte
strings are str_to_key'd (if you will) into 8 byte odd parity des keys.
Now we have :
| 8byteDeskey1 | | 8byteDeskey2 | | 8 byteDeskey3 |
8byteDeskey1 is used to encrypt the challenge 0x0001020304050607. Let's assume
the result is 0xAAAAAAAAAAAAAAAA. 8byteDeskey2 is used to encrypt the
challenge 0x0001020304050607. Let's assume the result is
0xBBBBBBBBBBBBBBBB. 8byteDeskey3 is used to encrypt the challenge
0x0001020304050607. Let's assume the result is 0xCCCCCCCCCCCCCCCC. The
three 8byte values are concatenated (!dumb!), and the 24 byte response of
0xAAAAAAAABBBBBBBBCCCCCCCC is returned to the server. The server does the
same thing to the hash on it's end and compares the result to the 24 byte response.
If they match, it was the correct original hash.
Why this is boneheaded: 7 char or less passwords.
-------------------- -------------------- --------------------
| C23413A8A1E766 || 5fAAD3B435B514 || 04EE0000000000 |
-------------------- -------------------- --------------------
The first thing we check is to see if the users password is less than 8 characters in
length. We do this by taking the 7 byte value of 0x04EE0000000000, turning it into
an 8 byte odd parity DES key, and encrypting it against the 8 byte challenge of
0x0001020304050607. If we get the result of 0xCCCCCCCCCCCCCCCC then we
are pretty sure it's < 8 chars in length. In order to be sure we can run through
0x??AAD3B435B514 (ie 256 possible combinations) to see that 5f shows us the
result is 0xBBBBBBBBBBBBBBBB, proving that the password is less than 7
characters and also giving us the last byte of the first half of the LM hash.
From this point, even assuming we're just joyriding and not worried about optimizing
the way this is done (believe me, there are much more effective ways to do this that
reduce the amount of time needed even further... this whole this is just showing that
even a simplistic attack works against this implementation), it's no different than how
a tool like L0phtcrack attacks the hashes in the registry. 8 char or greater
passwords.
-------------------- -------------------- --------------------
| C23413A8A1E766 || AC435F2DD90417 || CCD60000000000 |
-------------------- -------------------- --------------------
The first thing to check is whether the password is less than 8 characters in length.
Deriving the 8 byte odd parity des key from 0x04EE0000000000 and encrypting
against 0x0001020304050607 does not, in this case, give us
0xCCCCCCCCCCCCCCCC, so we know that the password is 8 characters
orgreater.
It takes us, in a worst case scenario, 65535 checks to figure out that the 2bytes that
are used in the last third are 0xCCD6. Even approaching this in a completely
brain-dead fashion (hey, turn-about is fair play), you can go through your 7 digit
combinations of characters for the first third the same way you would the LM hash
from the registry. This will yield not only the first third of the response, but also the
first byte of the second third. Keep in mind that you already have the last two bytes
that made up the third third.
You could approach the middle third in the same fashion. (note: this whole method
that MS is doing screams for a precompute table lookup attack - which given the
small enough potential values is not impossible by any means)
Thus, the challenge response is completely brute-forcable for the LM-hash. MS
made the "oversight" of still sending the LM-hash response along with the NT
response even when SP3 was installed. Thus it was a moot point as to how tough or
well done the NT hash might or might not be. Since installing the LM-fix precludes
continued use of windows 95 machines in regards to talking to NT machines, it is still
a moot point as to how tough or well done the NT hash might or might not be.
The LM hash is incredibly weak and your more secure NT hash is brought down to
the lowest common denominator. Thus, the challenge response is completely
brute-forcable for the LM-hash. MS made the "oversight" of still sending the
LM-hash response along with the NT response even when SP3 was installed. Thus
it was a moot point as to how tough or well done the NT hash might or might not be.
Since installing the LM-fix precludes continued use of windows 95 machines in
regards to talking to NT machines, it is still a moot point as to how tough or well
done the NT hash might or might not be.
The LM hash is incredibly weak and your more secure NT hash is brought down to
the lowest common denominator. It would have been nice if you could type a
password greater than 14chars into the UserManager app.
.mudge
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed