COMMAND
CIFS (Common Internet File System)
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.
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. Anyway, work is in progress so
check:
ftp://ftp.microsoft.com/developr/drg/cifs/sec.htm