nt-part2_52
Analysis of the Security of Windows NT
1 March 1999
52
2. The CIFS server verifies the cached Domain Controller name
3. If the cached name is invalid, the CIFS server does a Domain Controller Discovery
4. The CIFS server sends a NEGOTIATE SMB to the Domain Controller
5. The NEGOTIATE response along with the challenge is saved by the CIFS server
6. The CIFS server sends a NEGOTIATE response (to client) using this saved chal-
lenge
7. The CIFS client computes the challenge response as detailed in the CIFS specifica-
tion, and then challenge response is sent as part of a SessionSetupAndX SMB
8. The CIFS server extracts the challenge response from above SMB
9. The CIFS server sends it’s own SessionSetupAndX SMB to the domain controller
using the extracted challenge response
10.The Domain Controller sends a SessionSetupAndX response to the CIFS server.
This response will be successful if the CIFS client had provided the correct
response.
11.The CIFS server tears down the session with the Domain Controller that was estab-
lished by means of a LogOffAndX SMB.
12.The CIFS sever sends a SessionSetupAndX response to the CIFS client. This
response is based upon the response from the Domain Controller.
Keep in mind that this is not a description of an attack it is the recommended behavior!
In an environment where the only means of identification is the TCP/IP address and a
computer name that can be changed at will.
7.4.2 Weaknesses in SMB Signing
The last weakness that we will describe is not really an attack. It is a general weakness
that could be used in a number of ways. It is described by Hobbit in [30] and by Mudge
(a member of the L0pht) in a posting to the bugtraq mailing list. It points out the weak-
nesses in the challenge/response encryption when the LAN Manager password is sent
as well as the NT hash, which is the default behavior in NT. In appendix A.5, we
describe how the response is calculated from the password hash and the challenge. The
problem here is the Lan Manager hash. When the password is less then 8 characters
then the last 8 bytes of the hash will always be 0xAAD3B435B51404EE. This means
that 2/3 of the key used in the challenge response is already known together with the
challenge and the response if they are snatched from the network. Keep in mind that
DES ECB mode is used with the 21-byte padded hash split in 3 pieces. Under the cir-
cumstances mentioned, the third key is already known, it is 0x05EE0000000000. The
second key needs to be found by brute force but since we know a large part of it, the
structure of it is 0x??AAD3B435B514, it will only take 256 iterations in the worst
case. To gain the first key a brute force approach on the whole keyspace is needed, this
could however bee speeded up by using table lookup. Under the circumstances
described above we now have the Lan Manager hash of the password. This password
could be used to authenticate to a server as the cracked user by normal challenge
response, or to fake signed SMB messages from that user, or feed it into a password
cracker, e.g. L0phtCrack, to find the plain-text password. In the signing case the