2/16/2009

PsExec and Windows Security Problem

A few days ago, I encountered a strange problem - a process, which can access local disk files (such as d:\dir\file.ext), but can't access remote NTFS files (such as \\file_server_name\dir\file.ext), even if this process's owner is the administrator of the target machine.

After some investigation I found that this process(P1) is spawned by a another process(P2), which is started (on machine M1) remotely by PsExec (runs on machine M2). The process P2 runs in session 0 with non-interactive window station. If I start P2 manually (through terminal service session), all things OK.

You can reproduce this problem easily(we assume your current account is admin on all related machines):
1. On a remote machine M1, setup a shared folder which contains a text file(\\M1\Dir\test.txt) and write some simple text into this file(for example: hello world!).
2. On your local machine M2, run the following commands:
PsExec \\M3 CMD "/c type \\M1\Dir\test.txt"
PsExec \\M3 -u yourName -p yourPassWD CMD "/c type \\M1\Dir\test.txt"

3. You will see the second succeed while the first fail due to "access is denied"

In fact, this behavior is a "by design" feature of PsExec. The home page of this tool says that "If you omit a username the remote process runs in the same account from which you execute PsExec, but because the remote process is impersonating it will not have access to network resources on the remote system. When you specify a username the remote process executes in the account specified, and will have access to any network resources the account has access to."

But what happens behind the scene?

first, Let's run the following commands:
PsExec \\M3 CMD 1
PsExec \\M3 -u yourName -p yourPassWD CMD 2


then, log on to Machine M3, open Process Explorer, show up the property dialogs for the two CMD processes:


you will now see that the only difference is that "CMD 2" belongs to a security group called "Logon SID".

So, we can guess that:
1. If user name is given to the PsExec command, the PsExeSvc windows service will call LogonUser to first log on to the target machine using given cridentials and get some access token. It then use this token to creat the target command. So the created process functions normally.
2. But if no user name is given, PsExeSvc will impersonate the target command process using the access token from PsExec.exe itself.

If a process is impersonating as an account's SID, which is not logged on locally, it can't access network resources. This causes the problem we described in the beginning.

[Reference]
1. PsExec, User Account Control and Security Boundaries
2. interactive windows service
3. Windows Privilege

== Session, Windows Station and Desktop ==
4. http://blogs.technet.com/askperf/archive/2007/07/24/sessions-desktops-and-windows-stations.aspx
5. http://www.alex-ionescu.com/?p=59
6. http://www.alex-ionescu.com/?p=60

== Vista Winsta0 Isolation ==
7. http://bartdesmet.net/blogs/bart/archive/2007/03/05/windows-vista-winsta0-isolation-explained.aspx
8. http://blogs.technet.com/voy/archive/2007/02/23/services-isolation-in-session-0-of-windows-vista-and-longhorn-server.aspx

No comments: