COMMAND

    Reverting the "IUSR-MACHINENAME" Account

SYSTEMS AFFECTED

    Win NT 3.5, 3.51, 4.0

PROBLEM

    This vulnerability was originally presented on:

        www.ntshop.com/security

    and ome part of this text is their credit.

    ISAPI scripts  run under  the IUSR_MACHINENAME  account under IIS,
    and  thus,  inherit  the  security  permissions  of  this account.
    However,  if  the  ISAPI  program  contains a simple call labelled
    RevertToSelf(), you  have a  big hole.  Once that  program line is
    executed,  the  ISAPI  program  reverts  it's  authority  to   the
    all-powerful SYSTEM  account, at  which point  the program  can do
    just  about  anything,  including  successfully  execute  system()
    calls.

    Laxmikant Gunda was kind enough  to report to 'rhino9' that  there
    is yet another way to perform this same exploit. Laxmikant  offers
    the following:

    "ISAPI DLL runs under the security context of the IUSR_MACHINENAME
    account under IIS,  and thus inherit  the security permissions  of
    that  account.  However,  if  the  ISAPI  DLL can create a process
    using a  call to  CreateProcess( ).  The process  created inherits
    the security  context of  the powerful  LocalSystem account rather
    than  IUSR_MACHINENAME,  thus  creating  a  hole. Thus, any system
    process can be fired by the ISAPI DLL using this technique.

    This can  be tried  using a  generic ISAPI  DLL inserting code for
    CreateProcess( ) with a process name present in the system.

    This behaviour  is documented  in MSDN  library on  Impersonation:
    "When  a  thread  is  impersonating  a  user,  most actions by the
    thread  are  done  in  the   security  context  of  the   thread's
    impersonation token rather than  the primary token of  the process
    that owns  the thread.   For example,  an individual  thread of  a
    server process can impersonate a client to verify that the  client
    is allowed  to access  a securable  object. However,  some actions
    are always  done using  the security  context of  the process. For
    example,  if  an  impersonating  thread  calls  the  CreateProcess
    function,  the  new  process  inherits  the  primary  token of the
    process  rather  than  the  impersonation  token  of  the  calling
    thread.  Similarly,  the system always  uses the primary  token of
    the  process  to  validate   actions  requiring  the   SE_TCB_NAME
    privilege."

SOLUTION

    Don't  run  ISAPI  scripts  you  don't  trust  --  be careful with
    shareware and freeware. Insist on examining the source code  where
    ever possible,  and compile  it yourself  before use.  And if  you
    can't, think long  and hard before  you decide to  run the program
    blindly.   Test  the  ISAPI  programs   as  best  you  can  on   a
    standalone,  isolated  system  before  implementing  them  on your
    production machines.