Vulnerability

    IIS

Affected

    IIS 4, 5, 6beta

Description

    Marc  Maiffret  found  following.   There  exists  a remote buffer
    overflow  vulnerability  in  all  versions  of  Microsoft Internet
    Information Services (IIS) Web server software.

    The vulnerability lies within the code that allows a Web server to
    interact  with  Microsoft  Indexing  Service  functionality.   The
    vulnerable Indexing Service ISAPI  filter is installed by  default
    on all versions  of IIS.   The problem lies  in the fact  that the
    .ida  (Indexing  Service)  ISAPI  filter  does  not perform proper
    "bounds  checking"  on  user  inputted  buffers  and  therefore is
    susceptible to a buffer overflow attack.

    Attackers  that  leverage  the  vulnerability  can,  from a remote
    location, gain  full SYSTEM  level access  to any  server that  is
    running a default  installation of Windows  NT 4.0, Windows  2000,
    or  Windows  XP  and  using  Microsoft’s  IIS Web server software.
    With  system-level  access,  an  attacker  can perform any desired
    action, including  installing and  running programs,  manipulating
    Web server databases, adding,  changing or deleting files  and Web
    pages, and more.

    Riley Hassell was at it  again one day working to  further advance
    eEye's CHAM  (Common Hacking  Attack Methods)  technology so  that
    Retina  could  better  search   for  unknown  vulnerabilities   in
    software and so that  SecureIIS could better protect  from unknown
    IIS vulnerabilities.   After a  few hours  of running  some custom
    CHAM auditing code  one of our  Web servers in  our lab eventually
    came to a halt as the IIS Web server process had suddenly died.

    eEye investigated  the vulnerability  further and  found that  the
    .ida ISAPI  filter was  susceptible to  a typical  buffer overflow
    attack.  Example:

        GET /NULL.ida?[buffer]=X HTTP/1.1
        Host: werd

    Where [buffer] is aprox. 240 bytes.

    The Exploit,  as taught  by Ryan  "Overflow Ninja"  Permeh:   This
    buffer  overflows  in  a  wide character transformation operation.
    It takes the  ASCII (1 byte  per char) input  buffer and turns  it
    into a wide  char/unicode string (2  bytes per char)  byte string.
    For  instance,   a  string   like  AAAA   gets  transformed   into
    \0A\0A\0A\0A.   In  this  transformation,  buffer  lengths are not
    checked and this can be used to cause EIP to be overwritten.

    This sounds like any normal overflow to date, however there are  a
    few sticking points  in doing anything  useful with this.   First,
    you transform  2 bytes  into 4,  2 of  which you  have no  control
    over.   This  would  be  a  bad  situation,  but not impossible to
    exploit.  However, the 2 bytes  that you do not have control  over
    happen to be nulls.  Basically, we need to take this 2 byte string
    and somehow get it  to point to our  code.  Traditionally, we  use
    our overwritten EIP  to jump to  a call esp,  or jmp esp,  jumping
    back to code we have positioned on the stack to implement whatever
    it is  our shellcode  would like  to do.   In this  case, however,
    there is a problem.

        GET /a.ida?[Ax240]=x HTTP/1.0

    The  above  example  overwrites   EIP  with  0x00410041.    Again,
    traditionally,  we  insert  our  shellcode  in  the same buffer we
    overflow,  however  we  run  into  the  problem that then our code
    would also face the same expansion that our EIP bytes face.   This
    makes writing shellcode  a horrible pain.   There are two  methods
    of doing this:
    1. custom shellcode: It might be possible to write shellcode  that
       works fine with NULL byes every other byte.  It would  probably
       have to be very simple, but this could be possible.
    2. encode: You could probably write a decoder that takes a  string
       of 0x0041 and rewrites it on the stack into actual single  byte
       code.   This  would  have  to  be  written completely in 0x00bb
       opcodes,  most  likely  a  challenge  in itself (similar to the
       above custom  shellcode, but  only a  decoder would  need to be
       written).

    This would, of course  only be possible if  we could find a  point
    in memory that we could  reach using only 0x00aa00bb.   This gives
    us  only  about  65k  spots  in  memory  to look for jump bytes, a
    pretty dismal situation.

    eEye got lucky using this method.  They were basically limited  to
    a very very  small range of  memory in which  to find jump  bytes.
    They thought they  were losing the  battle until we  realized that
    IIS/ISAPI uses 0x00aabbcc as its memory range for allocated  heap.
    They developed  a spray  technique in  an attempt  to push  enough
    data into  the heap  so that  the bytes  we require  will be there
    when we need to jump to them.

    For instance, in  Windows 2000 Service  Pack 1, eEye  noticed that
    they had request  bytes at around  0x0042deaa.  Since  the closest
    they could get  to this was  0x00430001 (by overflowing  with C%01
    at the  end of  our overflow  string.   This offered an intriguing
    possibility -- perhaps  we could push  more stuff into  a request,
    causing more heap  memory to be  used, pushing our  request closer
    to where we want to be.

        GET /a.ida?[Cx240]=x HTTP/1.1
        Host: the.victim.com
        eEye: [Cx10,000][shellcode]

    Now,  we  overflow  the  EIP  with  0x00430043.  With our new much
    larger  request,  0x00430043  happens  to  be  inside  the large C
    buffer we  setup.   This acts  as a  slide in  our code, executing
    down to our shellcode.

    With  this  technique  of  forceful  heap violation, everything is
    relative to what  is there to  begin with.   eEye noticed that  in
    any situation, we  found 4-5 different  copies of our  requests in
    the 0x00aabbcc memory range.  This means that perhaps 0x430043  is
    not the best  spot in memory,  however it is  the one we  chose in
    our forthcoming sample exploit  (the exploit we will  provide only
    executes file writing; eEye provided Microsoft with  shell-binding
    code but will not publicly release this code). The other potential
    problem  with  this  attack  is  that  different  systems may have
    different  heap  usages.   In  internal  tests,  eEye noticed that
    heap  usage  differed  depending  on  which  ISAPI extensions were
    enabled at any time.  Also, requests that cause faults handled  by
    exception handlers that do not free their heaps may cause  certain
    parts of the heap to  become unusable, causing those spots  to not
    be reused.  This is not  a problem for Windows 2000 because  it is
    nice enough  to restart  itself (giving  us a  nice clean  heap to
    work with).  Windows XP  appears to act similarly, however  we did
    not  focus  our  research  with  this  beta OS.  This is, however,
    potentially a  problem with  NT 4,  which will  crash if exploited
    incorrectly.  Again, like all other IIS overflows, this attack  is
    not logged, causing only a fault in IIS and crashing it.

    All of the technical talk  aside, we do have working  exploits for
    Windows NT 4.0, Windows 2000 and Windows XP systems.

    As  stated  earlier,  all  versions  of Microsoft's IIS Web server
    software are vulnerable  to this flaw.   This includes Windows  XP
    beta,  Microsoft's  next-generation   Operating  System  and   the
    version of IIS that is included with it.  Microsoft is taking  the
    necessary  steps  to  patch  Windows  XP  before the final version
    ships to customers.

    Discovery  credit  goes  to  Riley  Hassell  and  Ryan  Permeh for
    exploit.

Solution

    Check out Microsoft Security Bulletin:

        http://www.microsoft.com/technet/security/bulletin/MS01-033.asp