COMMAND

    IIS

SYSTEMS AFFECTED

    IIS 4, 5

PROBLEM

    Maceo found following.  During normal webserver operations IIS, by
    default, impersonates the account IUSR_COMPUTER.  This account has
    minimal  access  rights.    However,  because   of  the  way   IIS
    impersonates  accounts,  spawned  processes  inherit  the original
    security  context.   This  can   result  in  escalation  of   user
    privileges.

    Depending  on  the  setup  of  an  IIS server this escalation will
    result in  access to  the account  IWAM_COMPUTER or  SYSTEM.  With
    IIS  4.0  the  account  depends  upon  whether  or  not  the   web
    administrator  has  selected  the  "run  in separate memory space"
    option.  This  option is unselected  by default and  allows SYSTEM
    account escalation.  In IIS 5.0 the setting is called  Application
    Protection.   Application Protection  "Low" will  result in SYSTEM
    access and  Medium or  High with  result in  IWAM_COMPUTER access.
    The  default  setup  for  IIS   5.0,  "Medium",  will  result   in
    IWAM_COMPUTER  access.   Further,  an  IIS  4.0 webserver that was
    upgraded to IIS  5.0 with the  default settings will  allow SYSTEM
    account escalation.

    It should be noted that since the IWAM_COMPUTER account can change
    the settings of the webserver, escalation to SYSTEM account access
    is still possible.

    An interactive command prompt from an ASP file.  This script  uses
    the Microsoft  scripting object  WSCRIPT.SHELL to  spawn a cmd.exe
    process which will run with escalated privileges.

    The PipeUpSAM variation dumps the local SAM database to stdout  in
    the standard PwdDump.exe format.   The generated file may then  be
    used with any NT MD4 password cracker, such as L0phtCrack.

    The PipeUpAdmin  variation adds  the current  user account  to the
    local Administrators group.

    The binaries are available at:

        http://www.dogmile.com/files/

SOLUTION

    Microsoft has not released an official fix at this time.  To block
    this particular exploit, unregister the windows scripting object:

        C:\> regsvr32.exe /u C:\winnt\system32\wshom.ocx