iis4.proxy.passwd.txt

`Date: Mon, 9 Feb 1998 04:35:48 -0000  
From: mnemonix <[email protected]>  
To: [email protected]  
Subject: ALERT: IIS4 allows proxied password attacks over NetBIOS  
  
Introduction  
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.  
  
Details  
By default every install of 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)  
  
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.  
  
Cheers,  
David Litchfield  
http://www.infowar.co.uk/mnemonix/  
  
------------------------------------------------------------------------------  
  
Date: Thu, 25 Feb 1999 22:25:00 -0500  
From: Russ <[email protected]>  
To: [email protected]  
Subject: Re: IIS4 allows proxied password attacks over NetBIOS  
  
One of the beautiful things about being a (mostly) respected moderator  
of a technical list is that you get to be technically incompetent while  
making some social commentary...can you say Doh?...Doh!!  
  
Mnemonix is right and I was wrong...with qualifications.  
  
1. Mnemonix is right, you can access the /IISADMPWD virtual directory  
anonymously and execute the .htr's found there. No restrictions other  
than having to know the right syntax (which Nemo withheld, IMO,  
correctly). Result could be very slow enumeration of user accounts  
(read: guess a valid account name, then try brute forcing password  
changes).  
  
2. I was wrong because I was looking at a completely different aspect of  
IIS, its Administration utility, not the virtual directory Nemo referred  
to allowing password change (read: I'm stubborn, single-minded, and too  
often "glimpse-read")  
  
Qualifications;  
  
1. 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)  
  
Had they implemented what they documented, the risk to a default install  
would be "reduced", obviously Nemo's attack would still work if the  
server had an SSL cert installed. The SSL wouldn't do anything to  
prevent it (other than to slow it down further).  
  
2. 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 *and*, for the very first time I can think of,  
finally a *good* reason to 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.  
  
Cheers,  
Russ - NTBugtraq moderator  
  
------------------------------------------------------------------------------  
  
Date: Thu, 25 Feb 1999 19:26:08 -0500  
From: Russ <[email protected]>  
To: [email protected]  
Subject: Re: IIS4 allows proxied password attacks over NetBIOS  
  
I've always appreciated the fervor with which Mnemonix appears to  
approach the issues he works on...BUT...  
  
In an effort to confirm or refute Mnemonix's latest information, I did  
the following using current production releases;  
  
1. Installed NT 4.0 Server (no domain)  
2. Installed NT 4.0 SP4 128-bit (including IE 4.01)  
3. Installed NT 4.0 Option Kit using the "Typical" installation option  
(thereby accepting all defaults)  
  
NT 4.0 is the original release version.  
NTOK is from the BackOffice April '98 release set.  
  
Observations;  
  
1. IIS HTML Administration was installed, but it was configured to run  
on port 5661.  
2. Through the HTML Administration tool included, I looked at the  
Administration Site's security configuration;  
  
a) Anonymous access is disabled by default.  
b) NTLM authentication is enabled by default (which means you'd have to  
successfully log on to access it)  
c) IP Address restrictions are enabled by default and only 127.0.0.1 is  
granted access.  
d) The only site "Operaters" defined is the NTLM Administrators group  
for the box.  
e) Logging is enabled.  
  
The same configuration was applied by default installation to the  
/IISADMIN virtual site under the Administration site.  
  
So while the directory permissions on the  
\%systemroot%\system32\inetsrv\iisadmpwd are lax, "Everyone: Change",  
this does not pose an immediate threat due to the web site configuration  
parameters that limit access to it.  
  
Its certainly possible that Mnemonix has seen a machine with the  
permissions/configuration he's described, but it is definitely not a  
current released version default or typical installation.  
  
Unfortunately he has not disclosed precisely what versions of what he  
was looking at.  
  
So while permission tightening is certainly recommended in any IIS  
installation, the threats described by Mnemonix do not exist in the  
versions that have been released and available for over a year from MS.  
The fact that SP4 was used in this installation means nothing wrt the  
way IIS was installed from the older NTOK (note that SP4 was installed  
prior to NTOK, and not re-applied after the NTOK installation, meaning  
it could not have affected the NTOK installation).  
  
I had a lengthy discussion with Mnemonix off-list about this particular  
message, and have had such discussions with him in the past about other  
"discoveries" he's made.  
  
His observations about what might be possible if access to the IISADMPWD  
directory *were possible* are of value to anyone trying to ensure the  
integrity and security of their IIS installation. However, his  
description of using this "vulnerability" to do user enumeration behind  
a Firewall or NAT box are, well, farcical.  
  
Given the pre-requisite vulnerabilities he states as fact don't exist  
(anonymous access to the Administration site, unrestricted IP access,  
and no NTLM authentication), the other extrapolated threats end up as  
simply "oh, really?".  
  
Certainly there is potential to take the Web Administration facility and  
modify its default configuration into an extremely insecure facility  
where the possibility of, very slowly, enumerating user accounts would  
be possible (assuming nobody looks at the logs, account lockout is not  
enabled, auditing is not enabled, and in general, the machine is left to  
the dogs).  
  
In my opinion all of this speculation, mistaken assumption, farcical  
hyperbole and arm waving takes away from the valid observations of the  
interaction between files and service which Mnemonix has told us.  
  
As the moderator of NTBugtraq I, at first, strongly refused to send  
Mnemonix's message through to NTBugtraq. I felt it was more FUD than  
valuable fact, and did more of a disservice than if he modified and  
reduced it to the raw, provable, facts. Unfortunately, despite numerous  
exchanges, Mnemonix insisted he'd rather have his original message sent.  
  
I'd appreciate your feedback on whether or not you feel you were served  
better by having his message sent to NTBugtraq (Bugtraq readers, feel  
free to tell me what you think of his message too!).  
  
Meanwhile, maybe Mnemonix can tell us what versions were used to produce  
the results he observed. If people are going to be warned, they should  
be warned about the right version (this assumes that he did the  
installation himself of course).  
  
Cheers,  
Russ - NTBugtraq moderator  
  
`