Capturing credentials from ‘Encrypted RunAs’ software
UPDATED: 5/30/2013 to cover same flaw in EnSc.exe.
There is a reason that the RunAs program doesn’t accept credentials on the command line…because people would embed passwords. Microsoft developer Raymond Chen writes:
If this offends you and you want to be insecure and pass the password on the command line anyway (for everyone to see in the command window title bar), you can write your own program that calls the
CreateProcessWithLogonWfunction.
Enter the many products that offer a way to “securely” embed credentials in a shortcut or file in order to launch an executable as an administrator.
Wingnut Software offers their commercial ‘Encrypted RunAs‘ application as a way for administrators to created encrypted shortcut commands that will launch applications with Administrative credentials. The selling point is that these credentials (which an administrator would provide when creating the shortcut) are protected in an encrypted command.
So I thought I’d download it and take a look at how it protects against the username and password being monitored and captured by a user with only standard USER rights. Note that I am *not* testing how well ERunAs encrypts the command…it appears to encrypt the command and credentials as strongly as advertised. However, I’m looking to see what happens after ERunAs decrypts everything and has to pass data to the operating system (and if I can capture that).
Spoiler, as a standard user I could monitor the parameters passed by ERunAs to the CreateProcessWithLogonW API and see the administrator’s username and password that were encrypted in the shortcut:
Encrypted RunAs is a small utility that is designed to make the job of Administrators a little easier, it can be used to run applications or software installations with access rights a standard user does not have.
I created an encrypted shortcut to run “notepad.exe” as the local administrator named “ALincoln” with a password of “Fubard123”.
Using the free API Monitor application, I was able to run it as a standard user (see below, I’m demonstrating I’m a standard user and that API Monitor is not elevated, but running with limited user rights), and I set a filter within API Monitor on the CreateProcessWithLogonW API.
From there I called ERunAs.exe, supplying the “Notepad.eras” file as it’s parameter (just like the shortcut does that Encrypted RunAs creates):
And seconds after clicking OK, I can see that the CreateProcessWithLogonW API was called by ERunAs.exe and I can see the parameters passed in clear text:
This means that if a standard user can access ERunAs.exe and the command it uses, the user can capture the administrative credentials used.
Now, I’ve been picking on 1 product so far, but I’ve confirmed this same method works to capture credentials from JoeWare’s CPAU, and Quimeras’ TqcRunas. I would expect this to work with any application that passes credentials to the CreateProcessWithLogonW API.
UPDATE
Based on feedback from a commenter, I also looked at EnSc (Encrypted Shortcut Creator). I found that using the same method as above, I can still capture the administrator’s credentials at the time the process is called. This can be done by a user without administrative rights…meaning any user that runs an EnSc created shortcut or has access to the shortcut, and the “ensc.db” file created by the program on first run (when master password is set).
And what about EnSC (http://ensc.rsc.bg). As far as I think it will also work there…
I have updated the post with information that demonstrates that EnSc.exe is vulnerable to the same credential capturing.
Do you have an idea how this can be fixed then?
I am not aware of a way securely pass the username and password to the API. You could introduce some mitigations that would *reduce* the risk…such as searching to see if the CreateProcessWithLogon (Wide and ASCII) API is hooked, or if your program is being debugged, or if known monitoring programs are currently running.
While a determined attacker can always bypass these detections, it would certainly raise the bar and make your application more secure than the rest.
Actually, I do have a way that you could re-architect your solution. If the point is to give the user a program running as an admin, you can do this as long as the Terminal Services service is running. I created an open-source program called RunAsLOU that demonstrates how it would work.
Essentially, you’d have to change the way your program is architected, but this is how I would do it:
* Create a Windows Service called something like “RunElevatedProgramSvc”
* Create a user-mode EXE that allows you to create these shortcuts and will pass data to the service (no need to track credentials)
* Using named pipes, the user-mode program would pass the program to run as an admin to the service
* The service, running as SYSTEM, will grab the logged on user’s token, and merge it with the SYSTEM user’s token.
* The service will then create the requested process using that new token, which is a merge of the SYSTEM account and the logged on user
* The logic for the above statement is demonstrated in Delphi in RunAsLOU. You could convert it to C# via p/invoke calls
No need for encryption at all in the scenario I described. The benefit of this approach is that processes run *as* the logged on user, but with elevated rights attached to them.
Thank you! Searching for CreateProcessWithLogon or program being debuged is not an option. This can always be bypassed. Windows service is exact what I came to these days searching for a solution. You confirm that this is the best one. I hope I’ll have time soon to rearchitect the software and release a new version. Thank you, again!
I’m the creator of EnSC and I’m trying to find how ti fix this, because this is really bad :). Even the common user can’t do this, but it will be better not to have such a vulnerability.
Just to be clear, when you wrote “common user”, you were referring to a user with average computing skills, not the Windows standard “User” account privileges, correct? I only point it out because a a user logged in with standard “User” account privileges can capture this information.
To me, the big risk is if a corporation where to deploy an “encrypted shortcut” to many of their workstations. Then if an attacker could obtain access to the desktop (or just the shortcut in some cases), they can run and monitor the shortcut and retrieve an account with administrative credentials.
In some companies, this account is a domain joined administrator account, which would then give them the ability to launch elevated attacks remotely.
As “common user” I was refering the normal users that do not have the idea to monitor the APIs. I read carefully your post and I know that standard user in Windows can run the portable version of API Monitor and find the user and the password. You are absolutely right. Now I’m thinking about a way to fix this issue in the next version. If you have any idea how to do that, please write to me. Thank you!
As expected the same is true for “Runas SPC”. As said before, the only “secure” way seems to be the combination of a system service and a userspace tool connected by named pipes. Looks like the developers of Runas SPC agree with that, since they offer a new version called “Runas Rob”. Its free for private use and uses a service to start programs elevated.
I haven’t worked with it yet (only with Runas SPC wich is not an option anymore :-) ), but maybe it’s worth a try for those still searching for an alternativ.
Cheers
I hav eone problem with this. Api Monitor is unable to monitor a program that was launched elevated unless launched elevated itself. That poses no threat to me as I still leak nothing to a limited user on my machine when using said program. Am I missing something here?
Yes, respectfully, you are misunderstanding part of this. I am not using API Monitor to monitor an elevated program, I’m using it to monitor the program that is going to *attempt* to launch another program elevated.
CPAU, EnSc, ‘Encrypted RunAs’…all of them (once deployed to the user with ‘encrypted’ credentials) run in the same privilege context as the user. This means they are run with standard user rights, and simply try to pass credentials to the OS to be authorized to run another program elevated.
Therefore, once CPAU, EnSc, ‘Encrypted RunAs’, etc are launched by a non-elevated user, they attempt to call ‘CreateProcessWithLogon’ and pass the now decrypted administrative credentials.
Because these programs are not elevated themselves, I can catch the credentials they pass to the OS in their attempt to create an elevated process.
I hope that makes things more clear.
Mick,
How about Surun/SudoWin?
Thanks.
Was RunAsRob ever tested to see if it has the same problem? Are there any tools (including paid) that can be used to help address this securely?
Thanks!
Do you have a link to the software or installation package for RunAsBob?
http://www.robotronic.de/runasroben.html
n download file is the tool Adminpath which use a service instead of a embed credentials
RunAsRob provides a couple ways to run a program elevated. One way is to run as an administrator and provide credentials. Another is to have the RunAsRob service execute it using SYSTEM credentials.
Looking at ‘RunAsRob.exe’, I see it calls CreateProcessWithLogonW in 5 locations. All of those calls and credentials passed could be captured using the methods described in this blog post.
However, running a process with SYSTEM credentials (via a service) does not expose any credentials, but comes with other security challenges…namely that the process spawned and now running under SYSTEM has unrestricted access to the local system. Additionally, running a process as SYSTEM means it has no network rights, which may or may not matter depending on your use case.
Any solution for this case? I need alternative but don’t find trust software.
I’m wondering the exact same thing. What alternatives are safe against this?
Hello Micky,
I’m Test with powershell and api monitor not capture passwords.
One way to mitigate this vulnerability(not a perfect one), is to reset/ the lock the admin account once the runas command starts installing the desired program. This way at least this passwork wont be used for any further attack. This means that administrator has always to set a new password, when he created a new encr runas file, but since the usage is only in specific cases, it can be considered as safe way of useinf runas from whichever runas developer. Mick thanks for bringing this important thing up.