Saturday, December 25, 2004 2:02 AM bart

PSP Episode 1 - Please run as

Secondary logon, runas.exe, "Run as..." or CreateProcessWithLogonW - you should know at least one of these

It doesn't matter what you're doing on your machine, always run under the context of a low privileged account. Thus, the user "Administrator" and the group "Administrators" are evil things for day-to-day usage, just as "Power Users" are. Instead, run as a simple user (member of the Users group). That sounds great, but what about development-related things that need elevated privileges (see a further episode about "Debugging is a privilege") or installation-related tasks? The answer is the "Secondary logon service". An overview...

What is it?

The Secondary Logon service (seclogon) is a service on Windows NT based systems (XP, 2003 especially) that allows users to run a certain application in the context of another account. Or, as the service description in the SCM MMC (services.msc) tells us: "Enables starting processes under alternate credentials.". This is useful in quite some scenarios. To elevate your privileges by running a process under a higher privileged identity, or to strip down your rights and privileges to test whether an app runs under lower credentials or to check ACLs on system objects under the context of that particular user. I use it in both situations. Also, to test for installation compliance, you can use this service (a good installer should run with "Power User" - these guys have write access to the Program Files folder - rights or less).

Where is it?

In the MMC of the Service Control Manager (SCM) which is available through Administrative Tools, Services or by running services.msc, locate the Secondary Logon service. It should be enabled by default and has the name "seclogon". Thus, to start/stop/query it you can use things such as net start seclogon, net stop seclogon, sc seclogon. Although the service runs as SYSTEM, it's capable of creating processes with another security context and make these available on the user's session (WinSta0 or a Terminal Services session).

How to use it?

  1. Windows Explorer
    Locate an executable or a shortcut or an .msc file, right click it, and choose "Run as". The displayed dialog allows you to specify another user (second option) to be used when running the process. If authentication succeeds, you'll start the executable in a process "living in a sandbox" under the specified credentials (that is, with the token of that user). When creating a shortcut you can specify to use runas as well (Advanced..., Run with different credentials).
  2. Command-line
    My favorite one. Go to the command prompt and use the runas.exe command to do the same as mentioned above. I'll give an overview of runas further in this post.
  3. Programmatically
    Usable for testing or in a real application to launch a trusted subprocess or a lower privileged subprocess. The Win32 API function is called CreateProcessWithLogonW and more info can be found on MSDN (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/createprocesswithlogonw.asp). An alternative is CreateProcessAsUser but this one requires the user of LogonUser (therefore loading the user's profile) first to authenticate the user. Another reason not to use this in production is the need to store the password somewhere, which can be a hard task to keep it secure (DPAPI needs to be used in order to keep it as secure as possible). Of course, the better alternative is to ask the user to specify the password and not to store it.

About runas.exe

The basic usage is straightforward. To run application "app.exe" under user "someuser", use this command:

runas /user:someuser app.exe

The system will prompt for the user's password (you can pipe in the password using a tool called Sanur) and if authentication succeeds, the process will be started with the specified user's rights and privileges. Simple hey? However, there's a lot more under the hood of runas.exe. An overview:

  • /noprofile: By default, the system will load the user's profile (which is residing in the "Documents And Settings\SomeUser" folder), which means that the HKCU registry hive will be mounted to the user's registry hive living in the ntuser.dat file. This can take some time. To run an application that doesn't make use of the profile (i.e. doesn't use the user's profile folders such as Favorites, Application Data, etc directly; doesn't use the HKCU registry hive; doesn't use "Isolated Storage") you can use this switch to disable the profile loading when performing the secondary logon. Applications like winword.exe that use the user's profile will likely fail when using this switch.
  • /profile: The opposite of /noprofile. No, tell me it isn't true? Yes, it is :-)
  • /env: The current environment is used when launching the application with different credentials.
  • /netonly: Use this one to use the specified credentials not to run the process but to access network resources with. The command will run under the context of the current user instead. This is useful when developing and checking ACLs etc.
  • /savedcreds: First of all, the /? help and the Windows Help are inconsistent for what the syntax is concerned. It seems to be the case that /savedcred, /savedcreds, /savecred and /savecreds all work (as well as /s, /sa, etc). Now, why did I strikethrough this parameter? Well, don't use it. It's insecure. What is does it pretty simple: it allows to save the entered credentials so that you don't have to type them again later on. The worst point is that these credentials are cached for the entire lifespan of the user's session, so any application that can run a process can run the runas.exe command with the parameter /savedcreds. If the password was entered earlier using runas with this switch, the new process can do all it wants without asking the user for the password (e.g. an ActiveX control, any downloaded - trusted - application, etc). The moral of the story: don't use this parameter.
  • /smartcard: Credentials are read from the smartcard instead of asking the user's password.
  • For more info, refer to http://www.microsoft.com/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/standard/proddocs/en-us/runas.asp.

Note that the runas command help (runas /?) is incomplete (there are two other switches called /showtrustlevels and /trustlevel that can be used to query and specify the trustlevel to run the app with) and that the Windows Help (checked on Windows Server 2003) for runas is inconsistent with the real use (e.g. /savedcred versus /savecred switch, which are both valid).

Using Windows Explorer

In Windows Explorer, the use of the secondary logon service is really simple. It's available through the context menu when selecting a file (.msc, .exe, .lnk). In the dialog displayed there are two options:

  • Current user (DOMAIN\User): This option does exactly the same as simply starting the app. So, why does it make sense? That's because of the second checkbox option: "Run this program with restricted access" (W2K3 SP1 RC1) or "Protect my computer and data from unauthorized program activity" (XP). Hmm, weird. Two different texts on W2K3 versus XP. Also the explanation is different:
    • XP: This option can prevent computer viruses from harming your computer or personal data, but selecting it might cause the program to function improperly.
    • W2K3: This option helps prevent programs from using administrator privileges to harm your computer. If you select this option, and the program relies on these privileges, it might behave improperly.
    • So, what's up?
      • The W2K3 description is more technical, so that makes much more sense than the "house, garden and kitchen XP user" message. Runing as administrator (so you need to log off now and log on as an administrator to see the effect - I assume you're not running as Administrator now), create a shortcut to cmd.exe. Run it with "Run as..." and enable the checkbox. In the command-prompt, take a look at whoami /priv which shows the privileges of the user. You'll see that only the SeChangeNotifyPrivilege (which is known as "Bypass Traverse Checking", what's in a name? :-)) is present (which btw is normal since this is used multiple times when performing file I/O for example, and is really meant to be enabled). Runas the shortcut again, but now uncheck the checkbox and you should have about 22 (in my case, since I'm running on a domain and the privilege "Add a user to the domain" aka SeEnableDelegationPrivilege is there as well, I have 22 privileges; the number on your machine might be different).
      • Do the same (runas with resp without checking the checkbox) and take a look at the output of whoami /groups. At first sight, you should see no difference (there's quite a lot of output). However, with the checkbox disabled there should be this:

        BUILTIN\Administrators                     Alias            S-1-5-32-544                        Mandatory group, Enabled by default, Enabled group, Group owner

        whileas with the checkbox enabled you should see

        BUILTIN\Administrators                     Alias            S-1-5-32-544                        Mandatory group, Group owner, Group used for deny only

        Thus, the token of the caller is duplicated but the BUILTIN\Administrators group is locked down for the user and is only used by the system for deny purposes which results in higher security. In the restricted command prompt, try to navigate to %HOMEPATH% (cd %HOMEPATH%) and you should see a nice and cute "Access is denied." message. That's great!
      • To wrap up this discussion, the checkbox is all about locking down the usage of the current account when running another process (notice that for example the SeImpersonatePrivilige is also disabled, therefore causing the failure of apps which use impersonation). Use it to test your application when locked down without Administrator rights and privileges. However, when running under a low privileged account as a best practice this charmy option should be of little value to you when doing this kind of tests. Nevertheless, some day it can become useful to you so you better know how it works and what it does. To summarize: the option allows to demote yourself to a normal user while you're still running with the same profile.
  • The following user: Exactly what you want to use, as described earlier in the runas.exe exploration. It's exactly the same as the runas.exe command with no extra switches.

More tricks

There are also other tips and tricks to run with elevated privileges when needed:

  • Connect to your own machine (or another machine on which you can perform the tasks) using Terminal Services (mstsc) and log in with another account with higher privileges. This only works only on Windows 2000 Server or Windows Server 2003 since XP does not allow multiple users to be logged on interactively on the same machine at a time. It's a possibility but it has some drawbacks: memory requirement (secondary profile loaded with the default shell), difficult switching between the remote session and the local one (I'm avoiding the use of a mouse as much as possible, so try to ALT-TAB in a TS session and to break out the TS session to ALT-TAB to a local session's window, you'll find that this is a difficult riddle) and last but not least, it's easy to forget that you're running remotely with higher privileges (especially when running full screen).
  • Use the scheduling command at.exe to plan the command prompt (cmd.exe) at some time in the future (e.g. 1 minute later). Since the Task Scheduler is running as SYSTEM, you'll get a child process of the svchost process with the security token/context of SYSTEM, the highest privileged user on the system. Also a possibility but I don't like it much too. There should be a reason why this service is disabled by default on my W2K3 SP1 RC1 box (guess what?). If you want to use it (please don't) you should enable the Task Scheduler service (service name "Scheduler") before you can use at.exe. Note that there is a much more safe variant of at.exe, which is called schtasks and available from Windows XP on and allows you to specify the user account to use to run the task (using impersonation kind of techniques behind the scenes when creating the child process). When enabling the "Scheduler" service, put it on Manual instead of Automatically.
  • If you have others, I'd like to hear them from you.

Happy Christmas and "runassing"...

Del.icio.us | Digg It | Technorati | Blinklist | Furl | reddit | DotNetKicks

Filed under:

Comments

# Bart's PSP (Personal Security Push)

Monday, December 27, 2004 6:34 AM by TrackBack

# Bart's PSP (Personal Security Push)

Monday, December 27, 2004 6:35 AM by TrackBack

# Why preparing security demos can hurt ... I killed lsass.exe by mistake :o

Thursday, August 18, 2005 5:17 AM by TrackBack

# Why preparing security demos can hurt ... I killed lsass.exe by mistake :o

Wednesday, September 28, 2005 8:24 PM by TrackBack