See below:
PS C:\Windows\system32\inetsrv> whoamiThe user in question was a local administrator (member of the local Administrators group) and the command was run from PowerShell with elevated permissions.
dev\crminstall
PS C:\Windows\system32\inetsrv> .\appcmd list apppool /"apppool.name:CRMApppool" -config
<add name="CRMAppPool" managedRuntimeVersion="v4.0" managedPipelineMode="Classic">
<processModel identityType="SpecificUser" userName="dev\crmapppool" password="MyPassword" idleTimeout="1.01:00:00" />
<recycling>
<periodicRestart time="1.05:00:00">
<schedule>
</schedule>
</periodicRestart>
</recycling>
<failure />
<cpu />
</add>
So you might need to be logged in as an administrator but you should under no circumstances be able to see another user's password. This is a pretty big security hole, IMHO.
I've only tried on Windows 2012 and 2012 R2, but the behaviour seems consistent.
Incidentally, this does not seem to be the first case where credentials are exposed like this, see this post. It's fair to mention that the issue on the link was eventually fixed.
Yes, you are correct; passwords should not be stored like this. But then again why would anyone set up an app pool to run with a personal account with admin privileges?
ReplyDeleteIf you're integrating with a another system granting the app pool user access to that system seemed a better alternative than having to store the credentials somehow, but clearly this was predicated on the assumption that the app pool user credentials were safely stored, which clearly, they're not.
DeleteUnfortunately this IIS 'feature' is there since years, for sure saw already in IIS 6 (probably in each version)...
ReplyDeletepoor understanding of practical security...
ReplyDelete1. of course the encrypted password is stored, it'd need to be for the service to start... and encryption algorithms are pretty standard, so really it doesn't make MUCH diff seeing it encrypted vs decrypted, since the former is simply a few lines of code away from being decrypted.
2. you said you were local admin, so of course you'd have ACCESS to the stored password. As Raymond Chen writes, "It rather involved being on the other side of the airtight hatchway" (see http://blogs.msdn.com/b/oldnewthing/archive/2006/05/08/592350.aspx and many others). Just as you have permission to CHANGE the account that it uses... or, since it's a local account, changing the password directly.
3. Most of the time, the passwords are stored using DPAPI, which encrypts the data using a key that's based either on the local machine, or on the account. Which key you use depends on how you are securing the data. In this case, I'd bet on the machine (since the service configuration is local to the machine). DPAPI is a standard API meant for exactly this type of thing.
4. Yes, you've ALWAYS been able to decrypt such passwords... windows service passwords, IIS app pool passwords... the list goes on...nothing new... want proof, just search for "password recovery".
The point I was trying to make is that the passwords are stored in clear text, which they should not be.
Delete