Obscure Problems and Gotchas

What?

That’s what I said too when I first discovered the exploit. I didn’t think it was so easily possible to extract usernames and passwords from IIS, but it is. I contacted Microsoft about this in order to make them aware of the problem and according to them it isn’t a problem! Yay!??

Therefore since it isn’t a problem; I am going to take a page out of the creator’s of http://heartbleed.com/ play book and explain the exploit and how to use it in a useful way. On an aside there were multiple player’s involved in Heart Bleed’s exposure.

What did you tell Microsoft?

Here are excerpts of the email exchange, I am omitting identifying information on purpose.

Email 1

To whom it may concern,

I am following the instructions found on this page: https://technet.microsoft.com/en-us/security/ff852094.aspx

Summary: I believe I have found an exploit or vulnerability inside of the Microsoft.Web.Administration.dll which allows me to pull usernames and passwords from IIS.

• Type of issue (buffer overflow, SQL injection, cross-site scripting, etc.)
  • Software vulnerability
• Product and version that contains the bug
  • Microsoft.Web.Administration.dll – version 10.0.14393.0
• Any special configuration required to reproduce the issue
  • N/A
• Step-by-step instructions to reproduce the issue on a fresh install
  • I have code to support this claim. Tell me how to share this code with you and I will give you a unit test to run. Putting step by step instructions here isn’t going to really work for me.
    1. On a fresh install of Windows 10 Professional (for the sake of argument)
    2. Have IIS installed with everything you would usually have in order to run a new MVC WebApplication for example using .Net 4.5
    3. Setup 3 application pools
    4. Make sure to set the Application Pool Identity to a specific user (AD User if possible to really drive the point home)
    5. Use 3 distinct sets of credentials that are not known to each of the three users:
       1. CONTOSO\Bob – mySecureSecretePassword1
       2. CONTOSO\Mary – mySecureSecretePassword2
       3. CONTOSO\Trent – mySecureSecretePassword3
    6. Running as Administrator of the machine, run the code I will provide you that uses the Microsoft.Web.Administration.dll and it will show you each ApplicationPool’s UserName and Password combinations
• Proof-of-concept or exploit code
  • If there are application pools with a ProcessModelIdentityType that is SpecificUser, then going into the ApplicationPool’s ProcessModel reveals the UserName and Password properties in plain text
• Impact of the issue, including how an attacker could exploit the issue
  • If the attacker is an internal user and employee – with administrative access to different machines, they could get other users’ passwords without their knowledge or even tripping any alarms
  • I understand that this comes down to trust, but I still don’t think plain text passwords are okay, this was too easy for me to do and I can run my application easily and undetected

Please let me know how you would like to proceed. I can upload my code somewhere in a zip file or something. I have been avoiding putting it on Git or CodePlex to avoid others seeing this problem. I really wanted to write about it on my blog, but I felt that I should at least try to contact Microsoft before doing so.

Email 2

Hello,

Thank you for contacting the Microsoft Security Response Center (MSRC). Upon investigation we have determined that this does not meet the bar for security servicing as the indicated items are not encryption keys. Additionally, they still require admin privileges to view.

For an in-depth discussion of what constitutes a product vulnerability please see the following:
“Definition of a Security Vulnerability”
https://technet.microsoft.com/library/cc751383.aspx
Again, we appreciate your report.

Not a product vulnerability

There are more exchanges, but at this point it doesn’t matter because the narrative doesn’t change past this point.

So since it’s not a problem here is how you use the exploit!

Here is the fully functioning code if you are interested: https://github.com/dyslexicanaboko/iis-site-manager

If you want to run the exploit for yourself just compile this project and run it from command line: https://github.com/dyslexicanaboko/iis-site-manager/tree/master/IisSiteManager.AppPoolExploit

How to list application pool credentials

1. Compile the “IisSiteManager.AppPoolExploit”
2. Open up a command line window as administrator.
   1. Short cut: Windows Key + X and select “Command prompt (Admin)”
3. Navigate to the location of the executable which will be found in the bin folder and whichever build profile folder you have built this for. Let’s say Debug for arguments sake.
4. Type in “IisSiteManager.AppPoolExploit.exe -s”
5. You will get a print out like this one below:

Why did you create this program?

Originally I didn’t think this was possible. I run IIS locally (because IIS Express sucks) and I was looking for an easy way to update all of my application pool passwords whenever I was forced to change my password at work. I gave it a shot and I was happy to find an easy way to change my application pool credentials, but I wasn’t expecting to be able to display any of the information in plain text.

In other situations I know for a fact that other dot net modules will prevent you from seeing the password such as in certain cases of looking at connection string information after your connection string has been instantiated.

Therefore why the double standard?

Well I warned them – oh well…

How to update all application pool credentials

These instructions are identical to the ones above except for the command line arguments.

1. Use the same instructions as above
2. Type in “IisSiteManager.AppPoolExploit.exe -c username password”

The effects of this are that you will update ALL application pools with the same username and password. Remember this was built for my personal use case so this may not be good for you and probably not something you want to do in production.

Ethics

I feel compelled to mention that you should not use this for illicit purposes. You should use it for these purposes only and carefully:

1. Debugging application pool problems. As in “Did we use the right password?” or “Did the password change and we forgot to update it?”
2. Updating a swath of application pool credentials in one shot.

If you have users who have production access that shouldn’t, you should revoke their access. Don’t be lax about this for reasons exactly like this one.