[23] in Best-of-Security

home help back first fref pref prev next nref lref last post

BoS: Windows NT authentication weakness

daemon@ATHENA.MIT.EDU (Dominique Brezinski)
Sat Feb 8 02:33:51 1997

Reply-To: dominique.brezinski@CyberSafe.COM
Date: Thu, 06 Feb 1997 10:02:19 -0800
From: Dominique Brezinski <dominique.brezinski@CyberSafe.COM>
Errors-To: best-of-security-request@suburbia.net
To: best-of-security@suburbia.net
Resent-From: best-of-security@suburbia.net

The following is a reasonably technical paper describing one of the vario=
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, =
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 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 t=
list. Any discussions of fixes and ramifications are obviously quite fair
game for public consumption ;)

	A Weakness in CIFS Authentication

		by Dominique Brezinski

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 fo=
an unauthorized user to use the credentials of a valid user to gain acces=
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.  I=
we have the host and Alice, who is the valid user, the protocol proceeds =

(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 t=
key and sends it to the host
(4)  The host looks up the hash of Alice=92s password in the security
database and encrypts the random string it sent to Alice
(5)  If the host=92s 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=EFve:

(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 hos=
(5)  Alice encrypts the random string using the hash of her password as t=
key and sends it to the host
(6)  Mallory intercepts (or just copies it off the wire) Alice=92s respon=
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=92s password in the security
database and encrypts the random string sent to Mallory
(8)  If the host=92s encrypted string matches the encrypted string sent b=
Mallory, claiming to be Alice, to the host, Mallory is allowed into the
system under Alice=92s 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 wha=
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 it=

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! =20

For this attack to work, Mallory needs to have access to the communicatio=
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 th=
same local network segment as Alice and/or the host, or Mallory can resid=
on a segment which lies somewhere in the normal route between Alice and t=
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=92s 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 serve=
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 =
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=92s.  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=92s response (if the attacker is actually forwardin=
the packets back and forth, then this not an issue for the attacker).  Th=
real response from the host will be discarded as duplicate data. If this =
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 intercept=
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 field=
(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=92s username,  sends the message to the host=
and voila, Mallory has a connection to the host using Alice=92s credentia=

Simple?  This attack is easier than trust exploitation using TCP sequence
number prediction, which has been a very successful attacks for those tha=
use such things in the real world. =20

The benefits of this man-in-the-middle attack over session hijacking beco=
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, n=
just to the target host itself.  This gives the attacker a wider range of
user=92s 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=92s credentials are used to access the server.  On Windo=
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 g=
a privileged connection to a given target host.  The attacker also does n=
have to figure out what was happening in the connection prior to hijackin=
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 messag=
and send it to Alice to get her to encrypt the challenge with her passwor=
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 =
the sniffing version of the attack can be fixed by adding an extra field =
the SMB_COM_NEGOTIATE message and a few associated operations.

4  Conclusion

	The authentication protocol in the CIFS specification is not secure
against man-in-the-middle attacks, and therefore is not appropriate for u=
in an internet or secure intranet environment without transport level
security.  If an attacker can manipulate the communication channel at or
below the transport layer, the protocol fails.  The attack presented in
this paper is just one of the possibilities, but there surely are others,
such as protocol down-grading. This presents a difficult problem that may
not have an easy fix.


Dominique Brezinski
My opinions expressed here, and in any public forum,=20
are my own and do not represent those of my employer=20
or its clients.  I am an individual, and I will=20
retain those rights of free speech granted to me,=20
regardless of my employment status.=20

home help back first fref pref prev next nref lref last post