COMMAND

    IIS

SYSTEMS AFFECTED

    Win NT 4.x with IIS 4.0

PROBLEM

    mnemonix found following.  Internet Information Server 4.0 has  an
    interesting feature  that can  allow a  remote attacker  to attack
    user accounts local  to the Web  Server as well  as other machines
    across the Internet.  Added to this if your Web Server is behind a
    firewall performing network  address translation, machines  on the
    clean side of the  firewall can be attacked,  too.  If during  the
    install  Web  Administration  was  selected,  Internet Information
    Server 4 creates a virtual directory "/IISADMPWD".  This directory
    contains  a  number  of  .htr  files.  Anonymous users are allowed
    access to  this files,  they are  not restricted  to the  loopback
    address (127.0.0.1).   The following is  a list of  files found in
    the   /IISADMPWD    directory,    which   physically    maps    to
    c:\winnt\system32\inetsrv\iisadmpwd.

        achg.htr
        aexp.htr
        aexp2.htr
        aexp2b.htr
        aexp3.htr
        aexp4.htr
        aexp4b.htr
        anot.htr
        anot3.htr

    The files, save for  a few, are pretty  much variants of the  same
    file and allow a user to change their password via the Web.   This
    can be used  in such scenarios  as mentioned in  the Introduction.
    Not only this but,  like the vrfy command  in the SMTP service  it
    can be used  to enumerate valid  accounts through guess  work.  If
    the user account does not exist a message will be returned saying,
    "invalid domain". If the account exists, but the password is wrong
    then the  message will  say so.  If an  IP address  followed by  a
    backslash  precedes  the  account  name  then  the IIS server will
    contact the  remote machine,  over the  NetBIOS session  port, and
    attempt to change the user's password.  (IPADDRESS\ACNAME)

    What's the mechanics?  Consider aexp3.htr.  This produces an  HTML
    form requesting the UserID, old password, new password and confirm
    new password.  The form's  action is  a POST  to  /_AuthChangeUrl?
    /_AuthChangeUrl? is a "virtual file" in memory that actually  maps
    to  achg.htr.   W3SVC.dll  maintains  this  in  memory  and  has a
    function, AuthChangeUrl( ), which links this to the achg.htr file.
    (To  see  this  function  make  a  copy of w3svc.dll, rename it to
    w3svc.txt and  open it  in notepad.  If you  can't see it straight
    away use Find from Edit on  the Menubar).  .htr files are  handled
    by ISM.DLL and so control is passed across from W3SVC.DLL. ISM.DLL
    then uses  the NetUserGetInfo  ( )  and NetUserChangePassword  ( )
    functions. (Again,  open up  ism.dll in  notepad and  you can  see
    references to these  functions.)  The  password is changed  if the
    entered information was correct.   If, however, the request is  to
    change a password on a  remote machine, the SYSTEM then  logs onto
    the  remote  machine  through  a  null  session then establishes a
    secure  session  over  which  to  trade  the  account and password
    information.

SOLUTION

    If  you  don't  require  this  service, then remove the /IISADMPWD
    virtual directory.   This will  prevent attackers  from  "proxing"
    password attacks.  If you do require the service and only need  to
    change passwords on  accounts local to  the server, disabling  the
    Workstation  service  should  prevent  this.   If you require this
    service  and  want  to  be  able  to  change  passwords  on remote
    machines, do your best to  limit where NetBIOS based traffic  over
    TCP port 139 can get to.

    The reason its vulnerable by default is because Microsoft did  not
    implement  what  they  documented  (surprise!).  The documentation
    states  that  the  Metabase  property  "PasswordChangeFlags" has a
    default value  of 0.   This value  would prevent  password changes
    over any channel other than an  SSL channel.  Fact is the  default
    value is 1.  This value allows password changes over any  channel.
    (note:  value can only be  seen through MetaEdit or a script).  No
    SSL, no ability  to do password  changes (or the  enumeration Nemo
    describes)

    Chances of  success are  still very  limited (you  don't know  the
    UserID you're trying  to change a  password for, so  you've got to
    find a valid userID, then  try and discover through brute  force a
    valid password  for it)  and primarily  based on  no knowledge  of
    security (weak/blank passwords on well-known account IDs). In  the
    case  of  his  bounce  suggestion  of  going to an internal remote
    machine  there's  the  added  complication  of  figuring out an IP
    address if behind FW or NAT.   He says the IP address is  reported
    in a HEAD request, but that's not by default.

    Workarounds (assuming you need to use this feature);

        1. Use  NTLM  authentication.   That  forces  a  logon  before
           permission to change passwords.
        2. Read your logs.
        3. Enable Account Expiry and Lockout. Use Metabase  properties
           "PasswordExpirePrenotifyDays"  and  "PasswordCacheTTL"   to
           notify users  who log  on that  their password  is going to
           expire.
        4. Strong passwords, rename the Administrator account...
        5. Edit ACHG.HTR and remove  the error handling sections.   It
           tries to be "friendly" (read: insecurely verbose), but  you
           can take out the error definitions and just let it  respond
           "Nope!" to  anything that  didn't work.  No feedback  means
           enumerating is, well, less meaningfully done automatically.