Auto-elevating Applications on Windows 7

Security is pretty important on computers, we all know that!  If you are deploying computers in an enterprise environment then you should be using Group Policy as one of the tools to enforce security and to configure some of the Windows features such as User Account Control (UAC).  Trouble is, when you are working in a laboratory environment on your desktop builds and GPO configurations, these very things can often make life a bit frustrating…  It’s like when you build a brand new computer and start installing all your applications and get the settings just right; how many times are you obliged to enter your credentials into the UAC prompt?  Way too many!!!

For a test environment, the UAC is a pain but for a live environment it should be switched on and configured correctly.  The frustration occurs when you are in that area in-between where you need the security settings on for testing/proving purposes, but you aren’t yet working in a production environment so can be a little more relaxed about the security.

To minimise my frustrations in this scenario, I use a simple script that allows me to auto-elevate most processes and sidestep the UAC prompt meaning that I am not repeatedly typing the password in every time.  Now before everyone goes crazy saying that there is a loophole/flaw/bug in the UAC & Windows 7 I should point out that this auto-elevation is by design and I’ll explain why at the end of this post.

The script is a very simple VBS script that launches the console command “runas.exe” and at the password prompt the password is entered automatically using the “SendKeys” method in VBS – and the UAC prompt never appears.  The script will also read in the first (if any) arguments that are passed to it.  If you just run the script with no arguments, you’ll get an elevated CMD prompt.  If however, you specify an executable as an argument when running the script then this executable will run elevated if it is allowed to by Windows.

Option Explicit

Dim sCmd, WshShell, WshNetwork, strUser

If WScript.Arguments.Count = 1 Then

sCmd = WScript.Arguments.Item(0)

Else

sCmd =  “%comspec%”

End If

Set WshShell = WScript.CreateObject(“WScript.Shell”)
Set WshNetwork = WScript.CreateObject(“WScript.Network”)

strUser = “Administrator” ‘    -  PUT USERNAME HERE
WshShell.Run “runas /user:” & WshNetwork.ComputerName & “\” & strUser & “ ” & sCmd
WScript.Sleep 500 
WshShell.SendKeys “@@@@@@@@@” ‘    -  PUT PASSWORD HERE
WshShell.SendKeys “{ENTER}”
WScript.Sleep 1000 

Set wshshell = Nothing

To use, copy the above VBS code and save it into a text file giving the file a VBS extension.

Tip: save the script to your desktop so that you can easily drag an executable file on top of it for auto-elevation.

If you look at the code above then you’ll immediately spot something bad: you have to hardcode the password into the script file!  As I mentioned earlier this script is useful in a lab environment but you should never use it in a production environment for this very reason; hardcoding a password (especially that of an administrative account) into any script is a bad x10⁹⁹  thing to do and a serious security failure.

The nature of script files means that they are just plain text files and as such anybody could open the script file and read the password.  To mitigate I use the “Script Encoder” tool from Microsoft which will encode the text contents of the script file so that only a more serious hacker could gain access to the code that it contains, whilst still allowing the script to execute normally.

In summary, this is a great tool to use when working in a laboratory environment but it should never be used in a production environment as it invalidates any other security precautions you’ve taken elsewhere.  You should also never use it to provide a non-admin user with the ability to auto-elevate an application, especially if the reason for this is to solve any application compatibility issues.  Finally, because the “Script Encoder” tool only encodes the script to make it difficult to read rather than fully encrypt its contents, it is still possible (if you know how) to view the contents of an encoded script file and therefore reveal the hardcoded password it contains.

 

So why doesn’t the UAC prompt appear in this scenario as you would expect it to?  Simple: there is a GPO setting for the UAC called “User Account Control: Behaviour of the elevation prompt for administrators in Admin Approval Mode” and it’s default setting is “Elevate without prompting: Allows privileged accounts to perform an operation that requires elevation without requiring consent or credentials.”.  What this means is that any local administrative account will be allowed to elevate a process without having to provide their credentials or consent to the UAC dialog.  Therefore, because the script is providing the credentials for the local administrator account rather than a domain user account that has administrative rights locally on the computer, it does not have to go through the UAC for any elevation and automatically elevates the requested process.

About these ads