Section 11

Mathematical/Theoretical

11-1. Can sessions be hijacked?
11-2. Are "man in the middle" attacks possible?
11-3. What about TCP Sequence Number Prediction?

11-1. Can sessions be hijacked?

In theory, however no one has yet coded the exploit. It would involve a complex spoofing job where not only would the session have to be hijacked at the transport level (getting all of the ACK/NACK numbering correct), but the tree ID (TID) and user ID (UID) would have to be spoofed at the redirector and server level respectively. We are talking SMB at this point.

A more likely session to be hijacked would be a telnet session to an NT server, but this applies to any straight telnet session, NT or not, and is beyond the scope of this FAQ. For more information refer to http://www.nmrc.org/files/unix/ip-exploit.txt..

11-2. Are "man in the middle" attacks possible?

Ealry versions of LANMAN send the password in the clear -- which is definately sniffer-bait. But the challenge/response authentication used by LANMAN 2.1 and earlier is subject to possible attack -- namely a plaintext attack. Since the challenge is plaintext, an attacker can acquire known plaintext/ciphertext pairs. Offline, the attacker can then test a guess at a password by using it to generate a key, encrypting the plaintext, and comparing it to the corresponding ciphertext. If it matches, the password is compromised.

Since case doesn't matter, a brute force attack is theoretically possible against plaintext/ciphertext pair obtained via a known plaintext attack.

However, this is simply offline attacking. A true man-in-the-middle attack allows a third party to intercept and replace components of the challenge/response conversation with their own, acquiring the password or even taking over the session itself. However, the easier of the two is getting the password.

By catching the start of a conversation and forging the challenge, the client would response with the response to the server, and the attacker would know a part of the equation, shortening the time and effort needed to break the plaintext/ciphertext pair.

By "precompiling" a list of response/password pairs, the password could be determined even quicker.

NT LM 0.12 uses MD4 to generate keying material, and since upper and lower case are allowed, the full 56 bits allowed by DES can be used. This does not eliminate the problem -- it simply increases the difficulty of brute force against a plaintext/ciphertext pair.

However this does nothing towards a realtime attack. The best method would be as follows:

• Client starts a session.
• Attacker sees this session, and waits for the response from the server.
• Server sends the response and the Attacker grabs it.
• Attacker removes the SMB_COM_NEGPROT bit and sends it to the Client.
• Client receives the Attacker's packet, and now assumes a plaintext password should be used.
• Client receives the real packet from the server, but ignores it thinking it is a dupe.
• Client sends the password in plaintext.
• Attacker grabs the password and now logs into the Server directly.
• Client times out or gets an error, and figures a network error has occurred. Client tries to log in again.

It is also possible in theory to catch the session before the authentication process even starts. For example:

• Client starts a session, and sends a request to the DNS server to resolve a host name.
• Attacker sees this request, and forges a reply that the Attacker's IP address is the address for the host the Client is requesting.
• Attacker sends request to DNS server cancelling Client's request.
• Client starts to log into Attacker.
• Attacker tells Client to send the password as plaintext.
• Client complies, and Attacker proceeds to login to original host that the Client was asking the DNS server about.
• Attacker kills the session with the Client, and the Client thinks an error has occurred, and tries again.

This attack has been partially implemented with the c2myazz file, which forces a plaintext login.

11-3. What about TCP Sequence Number Prediction?

Refer to section 10-1. This is possible, but unlikely, on anything requiring the TID and UID as a part of the spoof. TCP Sequence Number Prediction involves guessing what the TCP numbering sequence is, and inserting packets to (typically) execute commands on the target host with the proper sequence number.