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.