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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:37:41 PDT