---------------------------------------------------------------------------

Section 11

Mathematical/Theoretical

---------------------------------------------------------------------------

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 11-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.

---------------------------------------------------------------------------
