Eric Maino

Well the password *has* to be available in clear text somewhere, otherwise IIS will not be able to log on this user. And if IIS can get the clear text password, then anybody with enough privileges can do it as well. There's nothing that can be done about it.

If it makes you feel better, the situation is exactly the same with NT services or COM+ applications that are configured to run under a user-defined account. There are tools (like lsadump) to dump clear text passwords for them as well. Of course, they require administrator access.

If you don't want to store the password, use a built-in account (NetworkService, LocalService or System).

I understand that there needs to be a way for IIS to log on as that user, but one might think there could be a better way of doing it. I guess I would just much rather see the password stored encrypted and authentication done via a key that is generated with the username and encrypted password.

Also the NetworkServer, LocalService, and System all have passwords as well or they wouldn't be able to login. If you look at any of these users you can get their password as well :-(.

"Well the password *has* to be available in clear text somewhere, otherwise IIS will not be able to log on this user."

Ahahahahahahahahaha! That's the funniest thing I've ever heard. You should _never_ store clear text passwords. You encrypt them before storing, and then when the user enters his password you encrpyt it and come part to the encrypted version. Then no one can see his password.

This is how most programs that aren't retarted do it.

Eric M: It's true that System, LocalService and NetworkService have passwords as well. But these passwords are not be stored in the IIS metabase, so if you don't like the way IIS handles passwords it's definitely an option you should consider.

Another advantage of using NetworkService vs. a domain user is that you don't have to worry about password expiration/synchronization.

Eric L: IIS needs to be able to create a logon session for the user. To do this it needs to call an API like LogonUser which requires clear text credentials.

So even if IIS stores the passwords encrypted/obfuscated (I think it does, actually) at some point it *has* to decrypt them and get a clear text version to be able to call LogonUser. And if IIS can do that then you could write a tool to do that as well. This is why exposing clear text passwords through methods like WAMUserPass is not a vulnerability. If there was no documented API for this, you could easily reverse engineer what IIS does and write your own password extractor.

It looks like both of you are thinking about something like storing a hash of the password. This wouldn't work because there's nobody to type the actual password when IIS starts.

Think about it this way: to logon a user, you need to know the user's "secret", whatever that is. If you know it, you can become this user.

When the user logs on interactively, he types his password, and the domain controller (or local LSA) compares it with the stored hash. DC doesn't need to store the secret, only the hash of it - because the actual secret is stored in the user's head.

This doesn't work for services, COM+, IIS etc because they can't ask somebody to come and type in the password. They *have* to store the secret on the local machine, and even if it's encrypted, they *have* to be able to extract it in clear text form.

This is *not* retarded. The programs that only store the hash of the password can only prove to *themselves* that the password is correct. But they will not be able to access any resources (like a database) on behalf of the user. If you need to do that, you must have the user's secret.

I do agree that they best and most secure way to run IIS is to use System, Local Service, or the Network Service user.

I do not agree that if the password was stored as a hash that user could still not be authenticated. The authentication process could be re-written to authenticate based on a key which could be the encryption or hash of the username and hashed password. In this case only the hashed password would be stored and many would feel much better :-).

If the hashed password was enough to authenticate to any service, remote or local, then it would be just as sensitive as the password itself. Why would an attacker want a clear text password when he can dig into IIS metabase and extract a hash that allows him to do anything the user can do?

This is why in my previous post I used the term "secret" rather than "password". It doesn't matter what that secret is as long as you can use it to log on as the user.

I also wanted to mention an alternative to storing the password or running as a built in service account that's available in W2K3. It's called constrained delegation and it basically allows a domain admin to configure things such that a service (like IIS) can obtain kerberos tickets for another service (like a backend SQL database) on behalf of a domain user. This way IIS can avoid storing the password and still talk to SQL using a specific domain account rather than NetworkService or LocalSystem.

Pavel I do understand where you stand on the "secret" issue, though I think there is still a better alternative.

The biggest reason I don't want the password stored in clear text is not for "security" reasons but for reasons of the wandering eye. I personally don't like to know other's passwords and I don't like others to know mine. In this case any intersted admin can just dump all of the passwords in the metabase and I just don't feel that should be allowed.

Ideally I would like to see authentication work in this way:
1. User enters username and password.
2. Password is hashed based on an algorithm based on time so you will never get the same hash for the same password in a relatively close period of time.
3. This hashed password would then be encrypted or hashed with the username to generate a key.
4. This key would then be stored in the metabase or somewhere else accessible by the application.
5. Then for authentication the hashed password would then be encrypted or hashed with the username and compared to the stored key. If these match authentication would be granted.

This is just a rough idea of how I would like to see security work, and I know it's still vulnerable but the *secret* is no longer stored in clear text. Also if each application ran their own hashing algorithm then this would alleviate some issues, though could introduce others.

I think both Erics do not realize that that password is not to authenticate users but rather a password IIS has to use to authenticate itself (Eric L is probably one of those retards he's talking about since he would force you to enter a password every time you start IIS). IIS is the user who's entering the password. If you necrypt it IIS will still have to be able to decrypt it so all the attacker would have to do is to get the key used to encrypt the password. It will not be anymore secure.

But if you setup your permissions right the threat is not that big. IIS' user account will only be allowed to log in as a service, not locally, not remotely and it will not be able to access the computer over the network (so you won't be able to use it to read NetBIOS shares).

So you're problem is actually not with IIS but with protocols like NTLM and Kerberos. As I said before, IIS has to supply clear text credentials to LogonUser because that's how existing authentication providers work. And I think that's how it should work. Today, if I see in my audit logs that somebody connected to my SQL server as UserA then I know that whoever did it probably knows UserA's password.

I think it would actually decrease security if you could use a password OR a hash because you would now have to worry about protecting both. And it might not be obvious to everyone that the hash is just as sensitive as the password, so people would be more likely to leave hashes unprotected in registry, config files etc.

The alternative approach that you describe wouldn't quite work, but some pieces of it (like salting the hashes) do have equivalents in the real world :)

If the hash allows you to do every single thing that you could do if you knew the password (including authentication to remote machines, accessing user's private keys etc), then I still don't see how it's better to store the hash instead of the password.

Actually, you might have a point here - normal user passwords are typically not random, and if you look at one of them it might be easier to guess another one. But this argument doesn't apply to service account passwords which should be truly random, computer generated strings.

Jerry: I do realized that the password IIS has is used in order to authenticate itself. It needs to do this in the case of the application pool to "ran as" the user specificed. I also understand the best practices in setting up IIS in the most secure fashion, but what I am trying to get at is not how to setup IIS in the best and most secure fashion, but an alternative way to store the passwords in the IIS metabase.

Pavel: I will agree that my problem isn't with the IIS directly, but most likely with NTLM and Kerberos.

I do agree that if you could use a password or hash to login that this would decrease security as well, but I think that alternative methods could be developed in order to limit the decrease in security.

As stated about the hash would not allow you to do everything as that user it would only allow you to authenticate through the specific program.

BOTTOM LINE: All I would like to see is that passwords stored in the IIS metabase are not stored in clear text. I could care less if they were stored with some very weak encryption algorithm, becuase even if it was very weak you would still have to make an attempt to decrypt the string in order to find the clear text password. Right now all I have to do is look at the metabase and there ya go.

I do think there could be inprovements on Kerberos and NTLM or at least another layer of authentication in windows before it gets to Kerberos or NTLM.

> As stated about the hash would not allow you to do everything as that user it would only allow you to authenticate through the specific program.

And how would you enforce this? If IIS can use the hash to authenticate as the user, and I have full access to the machine where IIS runs, then I can certainly write a program that will do the same.

Also, if having the hash does not give me the *exact* same rights as knowing the password, then this will break a lot of existing IIS apps. What if my app needs to use client certs to talk to another web service? Will your hash allow me to access the user's certificate store and private keys? What about EFS encrypted files?

> All I would like to see is that passwords stored in the IIS metabase are not stored in clear text.

I just checked my W2K3 box - the passwords are *not* stored in clear text, just as I expected. If you look into metabase.xml, the passwords seem to be encrypted, most likely with CryptProtectData() (of course, as we have seen, this is encryption *has* to be reversible).

There are a couple of reasons for protecting the passwords in this way. First, if you use non-random passwords for your app pools (bad practice) then there's the risk that someone could look over your shoulder while you edit the metabase and memorize them. Storing encrypted blobs mitigates this.

Second, if the metabase.xml file is stolen or accidentally copied to an unprotected location, it's impossible to extract the passowrds because they are encrypted with a key that's tied to the local machine.

> As stated about the hash would not allow you to do everything as that user it would only allow you to authenticate through the specific program.

I meant that they hash would only grant that user access through that program. It would only be valid on that machine, for that user, through that application. I could elborate more but won't.

>All I would like to see is that passwords stored in the IIS metabase are not stored in clear text.

Somehow we got off track here. I know that the passwords are encrypted in the metabase.xml file, but if this file were to be read though ADSI the passwords are not encrypted and shown in clear text. I would be much happier if they just showed the same password that is shown in the metabase.xml. If this were the case then I would sufficiently happy.

>if this file were to be read though ADSI the passwords are not encrypted and shown in clear text. I would be much happier if they just showed the same password that is shown in the metabase.xml

I think I addressed all your points except this one.

If MS did what you suggest then somebody would reverse engineer what IIS does to decrypt the passwords and post a tool to bugtraq, claiming that "M$ still doesn't get it" and relies on security through obscurity.

And in my opinion, they would be right.

Hiding passwords like this makes life harder for administrators and other people who might have a legitimate reason to see the passwords. But it's just a small speed bump for a determined attacker.

In fact, no matter how hard you try to obfuscate the passwords, it would take less than a minute for somebody with admin access to get them in clear text form, even without understanding the obfuscation algorithm or using any special-built tools. Here's how I would do that (on W2K3/IIS6):

1. Use Image File Execution Options reg key to launch svchost under built-in debugger (ntsd.exe -server npipe:pipe=hack_iis)

2. iisreset

3. Connect to the svchost debug session (ntsd -remote npipe:server=%computername%,pipe=hack_iis)

4. Set a breakpoint on LogonUserExW that dumps the password (3rd parameter) and continues:

0:000> bp advapi32!LogonUserExW "du poi(esp+c);g"

5. Continue the process and watch it dump clear text passwords for all application pools.

hello

Good article, woke me up when I saw the application pool's passwords in plain text, then again you're right about services accounts they are doddle to decrypt with local admin rights and PWDumpX but there's no way for MS to get around this. The security issue comes in when Services / Scheduled Tasks / IIS App Pools are configured with more priviledge than the local administrator should have - (s)he can then get to resources he otherwise wouldn't. Down to whoever sets up these services/scheduled tasks/App pools to ensure that only cleared staff have local administrator access to these servers.

The other issue is that Admins could get hold of common Service credentials and masquerade as that account to avoid auditing.

Thats my 5 pence anyway

Dave