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.