Date: Mon, 9 Feb 1998 04:35:48 -0000 From: mnemonix To: BUGTRAQ@netspace.org 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 To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM 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 To: BUGTRAQ@netspace.org 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