Date: Mon, 9 Feb 1998 04:35:48 -0000
From: mnemonix <mnemonix@GLOBALNET.CO.UK>
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 <Russ.Cooper@RC.ON.CA>
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 <Russ.Cooper@RC.ON.CA>
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