DATE: COMMAND SOURCE: AUTHOR: CIFS SYSTEMS AFFECTED Win NT PROBLEM This description of vulnerability is completly based on Dominique Brezinski <dominique.brezinski@CyberSafe.COM> paper. 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. 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 Alice's password in the security database and encrypts the random string it sent to Alice (5) If the host's 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 naive: (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) Alice's 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 Alice's password in the security database and encrypts the random string sent to Mallory (8) If the host's encrypted string matches the encrypted string sent by Mallory, claiming to be Alice, to the host, Mallory is allowed into the system under Alice's 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. 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 hostís 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 host's. 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 hostís 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 Aliceís username, sends the message to the host, and voila, Mallory has a connection to the host using Aliceís 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 user's 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 whoís 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. EXPLOIT SOLUTION 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.