COMMAND

    IIS

SYSTEMS AFFECTED

    IIS 4.0

PROBLEM

    Following   is   based   on   ISS   Security   Advisory.    If   a
    non-administrative user can place executable code into a web  site
    directory which allows file execution, the user may be able to run
    applications which could compromise the web server.

    The following directories are  marked executable by default  on an
    install of IIS 4.0:

        /W3SVC/1/ROOT/msadc
        /W3SVC/1/ROOT/News
        /W3SVC/1/ROOT/Mail
        /W3SVC/1/ROOT/cgi-bin
        /W3SVC/1/ROOT/SCRIPTS
        /W3SVC/1/ROOT/IISADMPWD
        /W3SVC/1/ROOT/_vti_bin
        /W3SVC/1/ROOT/_vti_bin/_vti_adm
        /W3SVC/1/ROOT/_vti_bin/_vti_aut

    In a default install, the physical drive mappings will be:

        msadc           c:\program files\common\system\msadc
        News            c:\InetPub\News
        Mail            c:\InetPub\Mail
        cgi-bin         c:\InetPub\wwwroot\cgi-bin
        SCRIPTS         c:\InetPub\scripts
        IISADMPWD       C:\WINNT\System32\inetsrv\iisadmpwd
        _vti_bin        Not present by default - installed with FrontPage extensions

    Access to the physical  directories can be obtained  through drive
    sharing, remote command  shells (e.g., rcmd,  telnet, remote.exe),
    HTTP  PUT  commands,  or  FrontPage.   None  of  these methods are
    available  in  a   default  install,  but   are  often  added   by
    administrators.    The  default   NTFS  permissions   are   overly
    permissive, and allow change control (RWXD) to the Everyone  group
    by default, with the exception  of msadc which is full  control to
    Everyone.

    Administrators should closely examine all pathways to access   the
    filesystem, and be  aware of all  web directories that  allow file
    execution.  In addition, if a user is allowed to administer  their
    own  site,  they  may  have  permission  to  set  a  directory  to
    executable.   A system  administrator should  permit only  allowed
    file types to be copied onto a production web site.

SOLUTION

    Administrators  should  verify  access  permissions on all virtual
    HTTP server  directories that  are marked  executable.   See below
    for recommended  permissions.   All security  patches that protect
    against local  attacks should  be applied  to HTTP  servers due to
    the possibility of the server executing code locally. See:

        http://www.microsoft.com/security

    for details.  Due to the sensitive nature of these directories, it
    is recommended that NTFS access permissions should be:

        Administrators, LocalSystem: Full Control
        Everyone: Special Access(X)

    See pp. 355-356  of the Internet  Information Server Resource  Kit
    for recommended file  system permissions.   The KB article  refers
    to the permissions  needed by the  server to run  at all, not  the
    web  site  itself.   Directories  marked  executable by the server
    should only contain executable  files (i.e., foo.exe), and  should
    have only X permission.   You shouldn't have .asp pages  stored in
    these directories, but  if you have  a need to  mix asp pages  and
    executables, then the  permissions should be  broadened to RX,  as
    the ASP pages require  read access (but not  X).  Either way,  the
    important thing  is to  tightly restrict  who has  _write_ access.
    Whether or not to give  permission to everyone, or just  the IUSR_
    account, depends  on how  the web  site is  used.   If the site is
    going to allow only  anonymous access, permissions for  just IUSR_
    is reasonable.  If  you're going to allow  access via NT auth  (or
    basic auth), then  the user context  will be some  authorized user
    other than IUSR_, and everyone  access is much more viable.   Also
    consider that if  an app is  contained in an  executable directory
    and IUSR_  has X  permission in  that directory,  then anyone  can
    execute that  app simply  by typing  in the  URL, so dropping from
    everyone to IUSR_ isn't going to buy you anything.