Re: IIS4 allows proxied password attacks over NetBIOS

[Russ.Cooper () RC ON CA (Russ)]

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