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.