The following is a
reasonably technical paper describing one of the various
problems with the authentication protocol used by NT,
which is documented in the CIFS specification in the
section regarding the NT LM 0.12 dialect of the protocol.
There is a section of the CIFS specification that
outlines known attacks and weaknesses of the different
authentication mechanisms. One of the weaknesses
mentioned is that an attacker can get the client to
encrypt a given piece of plain text, therefore allowing
the attacker to get known plain text/cipher text pairs.
The following attack is a practical implementation of
this weakness (compared to cryptanalysis of DES or MD4). This paper has been reviewed by a handfull of very knowledgeable people, so if anyone has a question about the feasibility, correctness, etc. I would appreciate it if they ask me directly through private email first, before posting to the (firewalls) list. I ask this in an effort to reduce that amount of "I don't get it" or "that doesn't seem right" questions that get posted to the list. Any discussions of fixes and ramifications are obviously quite fair game for public consumption ;) A Weakness in CIFS Authentication 1 Introduction The Common Internet File System (CIFS) is designed to provide accountability and discretionary access control to resources on remote hosts when user level security is used. A weakness exists that allows for an unauthorized user to use the credentials of a valid user to gain access to the system remotely, which undermines the accountability of the system and access control. The authentication mechanism is vulnerable to a man-in-the-middle attack. 2 The Protocol The challenge-response mechanism implemented in the CIFS NT LM 0.12 and LANMAN 2.1 dialects is specified in draft-heizer-cifs-v1-spec-00.txt submitted to the IETF Network Working Group as an informational draft. If we have the host and Alice, who is the valid user, the protocol proceeds as follows: (1) Alice sends a connection request to the host 2) The host responds with a random string (3) Alice encrypts the random string using the hash of her password as the key and sends it to the host (4) The host looks up the hash of Alices password in the security database and encrypts the random string it sent to Alice (5) If the hosts encrypted string matches the encrypted string Alice sent, Alice is allowed into the system If Mallory, the active attacker, gets involved, we see why this protocol is indeed naïve: (1) Mallory sends a connection request to the host (2) The host responds with a random string (3) Mallory waits for Alice to send a connection request to the host (4) When Alice sends a connection request to the host, Mallory forges a response to Alice containing the random string sent to Mallory by the host (5) Alice encrypts the random string using the hash of her password as the key and sends it to the host (6) Mallory intercepts (or just copies it off the wire) Alices response and repackages it as a response to the connection request made in (1) and sends it to the host claiming to be Alice (7) The host looks up the hash of Alices password in the security database and encrypts the random string sent to Mallory (8) If the hosts encrypted string matches the encrypted string sent by Mallory, claiming to be Alice, to the host, Mallory is allowed into the system under Alices credentials There is an implicit trust in the underlying communications channel in this protocol. The trust lies in the fact that the client assumes the challenge was indeed issued by the host. It has been sufficiently proven that one can not rely on TCP/IP or IPX (or any other mainstream network protocol) for authentication of the sending host, and this is exactly what is being done. 3 The Attack The example demonstrated in the paper will assume the host, or target, is on a TCP/IP network. The attack is reliant on the underlying transport protocol being susceptible to spoofing, but it is not TCP/IP dependent itself. Mallory will play the person in the middle, the person so many would like to believe is not there, but always is. Mallory is patient. Mallory is persistent. Mallory reads a lot! For this attack to work, Mallory needs to have access to the communications channel between the host and Alice, in this case at the transport level. Fortunately for Mallory, IP traffic can often be re-routed to travel through just about any point in the network, or else Mallory can be on the same local network segment as Alice and/or the host, or Mallory can reside on a segment which lies somewhere in the normal route between Alice and the host. TCP and IP are quite susceptible to spoofing, so Mallory has the access to the communication channel that she needs. After placing herself between the host and Alice, Mallory makes a NetBIOS over TCP connection to the target host and sends a SMB_COM_NEGOTIATE message, specifying the NT LM 0.12 dialect. The NT LM 0.12 is the preferred SMB dialect for user level authentication, so the host will respond with a message that contains a challenge in the EncryptionKey field. Mallory holds on to the relevant data from the hosts response, paying particular attention to the challenge. Now Mallory waits (if the host times out the connection, then Mallory repeats this step as necessary). When Alice attempts to connect to the host (or any SMB server as long as the password is the same) by establishing a NetBIOS over TCP session and sending a SMB_COM_NEGOTIATE message, which supports the NT LM 0.12 dialect, Mallory creates a SMB_COM_NEGPROT message that appears to be from the host. The EncryptionKey field is set to the challenge Mallory received from the host initially, and then the SMB message is placed in a forged NetBIOS over TCP segment that has the source IP address spoofed to be that of the hosts. The TCP sequence numbers can be obtained by analyzing the TCP header of the SMB_COM_NEGOTIATE message sent from Alice to the host. All that has to happen is the forged response must reach Alice before the hosts response (if the attacker is actually forwarding the packets back and forth, then this not an issue for the attacker). The real response from the host will be discarded as duplicate data. If this is the case, Alice will encrypt the challenge, originally sent to Mallory, with the hash of her password and send it back to the host in a SMB_COM_SESSION_SETUP_ANDX message. Mallory is patiently monitoring the traffic for this SMB_COM_SESSION_SETUP_ANDX message, and either intercepts or copies it as it goes by. Mallory then formulates a valid SMB_COM_SESSION_SETUP_ANDX message for the connection she originally made to the host. The CaseSensitivePassword and CaseInsensitivePassword fields (and the corresponding length fields) are copied from the intercepted SMB_COM_SESSION_SETUP_ANDX message Alice sent. Mallory fills in the AccountName field with Alices username, sends the message to the host, and voila, Mallory has a connection to the host using Alices credentials. Simple? This attack is easier than trust exploitation using TCP sequence number prediction, which has been a very successful attacks for those that use such things in the real world. The benefits of this man-in-the-middle attack over session hijacking become clear when it is realized that Alice can be any valid user for the target host and that Alice can be attempting to authenticate to any resource on the network where her password is the same as it is on the target host, not just to the target host itself. This gives the attacker a wider range of users credentials and instances where a successful attack can be made against a given target host, and it allows the attacker to be more selective of whos credentials are used to access the server. On Windows NT, it is generally easy to obtain a list of the privileged users on a server. Therefore, there is a higher probability that the attacker can get a privileged connection to a given target host. The attacker also does not have to figure out what was happening in the connection prior to hijacking and can just connect to the resource that suites them most. If Mallory is actively forwarding the packets between Alice and the host, then Mallory does not have to partially set up a connection to the host prior to Alice, but instead just takes the SMB_COM_NEGOTIATE message and packages it in a valid NetBIOS over TCP session from Mallory to the host. The host will then respond directly to Mallory with the SMB_COM_NEGPROT message, and Mallory can turn around and re-package a copy of this message and send it to Alice to get her to encrypt the challenge with her password hash. Mallory will then intercept the SMB_COM_SESSION_SETUP_ANDX sent by Alice and again just send it to the host in the valid NetBIOS over TCP session. Mallory will now have a connection to the host as Alice. This method of the attack makes it truly difficult to fix the protocol, where as the sniffing version of the attack can be fixed by adding an extra field to the SMB_COM_NEGOTIATE message and a few associated operations.
|