Logon sessions have never gotten much coverage in Windows documentation, but understanding them can help you get a better feel for how Windows works under the hood. A logon session is a data structure maintained by the kernel that represents an instance of a principal on a machine. It’s where network credentials like your cached Kerberos tickets and the associated keys are stored (WhatIsKerberos). Each token points to a single logon session, so ultimately each process is associated with a single logon session via its token, as shown here:

A new logon session is produced each time a successful authentication occurs on the machine, so when you log on interactively the system creates a new logon session. When you connect to a machine remotely and authenticate, say via a file share or a Web server that requires Windows authentication, a new logon session is created for you on the target machine and the server receives a token that refers to it. Logon sessions are destroyed when all tokens that refer to them are closed (their lifetime is controlled by a reference count of outstanding tokens). When you log off interactively via explorer.exe or call the Win32 function ExitWindowsEx, the operating system enumerates all processes tied to your logon session and asks them to close. Thus, logon sessions often help determine the lifetime of processes.

There are three built-in logon sessions that the operating system starts implicitly at boot time, and they have hardcoded logon session identifiers (there are constants defined for these numbers in the Win32 header file winnt.h).

• 999 (0x3e7) = SYSTEM
• 997 (0x3e5) = Local Service
• 996 (0x3e4) = Network Service

Given the hardcoded nature of these logon session identifiers, it's pretty clear that there's only one of each on a given machine at a time. If you've ever wondered what the password is for any of them, it should be clear that this a moot question! It doesn't take a password to log these guys on — the operating system ensures that they're always present. This doesn't mean that just anyone can get a token for Network Service and start programs running under these credentials. The operating system must do this on your behalf. An administrator can configure a service, IIS worker process, COM+ server, and so forth, to run as Network Service, and the operating system will construct a token for logon session 996 and launch the server process with it. These logon sessions are always present and are typically used to host daemons (WhatIsADaemon). You'll never need to worry about Network Service logging off, for example, unless the machine is being rebooted. See HowToChooseAnIdentityForADaemon for more on these built-in logons.

There’s also a special type of logon session for anonymous users called the null session, and I've dedicated WhatIsANullSession to explaining how it's used.

Bear in mind that any code that’s already running in a particular logon session can create new processes that will naturally go into that logon session. So another way to get a process running as Network Service (or in any of these built-in logon sessions, for that matter) is to have some code that’s already there start the process for you. In a footnote in WhatIsASecurityPrincipal, I described an old parlor trick for starting a command prompt in the SYSTEM logon session by asking the task scheduler (which runs in the SYSTEM logon session) to launch it for you.

This should give you pause: if you are building a server application that needs to start another process, ensure that you are under complete control of the path to the executable file that you want to launch (specify the full path). In addition, ensure that the arguments you pass are treated as arguments and not interpreted by a command shell. For example, consider the following ill gotten attempt to run a search using an external program:

 string cmdToExecute = “search.exe “ + userInput;

Normal users would pass benign strings like “butterfly”, while a malicious user could pass a string that would cause you to launch another program, "| net user hacker @@InterWiki("ssw0rd", "P", "P")@@ /add". Note the pipe symbol at the beginning of the malicious input. Of course net.exe will run in the same logon session your are running in, and if it happens to be a privileged session, the attack will succeed and you’ll have a new user account on your server!

The most natural way to avoid this problem is to launch new processes using the System.Diagnostics.Process class, where you’re forced to separate the name of the file you want to launch from the arguments that should be passed to the process:

 Process p = new Process();
 p.StartInfo.FileName = @"c:\legacy\search.exe";
 p.StartInfo.Arguments = filteredUserInput;
 p.Start();

Note that even when taking this precaution, you should still relentlessly filter any user input that you pass to the external program, because that program may itself be vulnerable to malicious input (it may never have been designed to accept input from remote, untrusted users, for example).

PortedBy CraigAndera