Impersonate SYSTEM (or equivalent) from Ad

2020-03-05 06:31发布

问题:

This question is a follow up and continuation of this question about a Privilege problem I'm dealing with currently.



Problem Summary:
I'm running a program under a Domain Administrator account that does not have Debug programs (SeDebugPrivilege) privilege, but I need it on the local machine.


Klugey Solution:
The program can install itself as a service on the local machine, and start the service. Said service now runs under the SYSTEM account, which enables us to use our SeTCBPrivilege privilege to create a new access token which does have SeDebugPrivilege. We can then use the newly created token to re-launch the initial program with the elevated rights.


I personally do not like this solution. I feel it should be possible to acquire the necessary privileges as an Administrator without having to make system modifications such as installing a service (even if it is only temporary).

I am hoping that there is a solution that minimizes system modifications and can preferably be done on the fly (ie: Not require restarting itself). I have unsuccessfully tried to LogonUser as SYSTEM and tried to OpenProcessToken on a known SYSTEM process (such as csrss.exe) (which fails, because you cannot OpenProcess with PROCESS_QUERY_INFORMATION to get a handle to the process without the privileges I'm trying to acquire).

I'm just at my wit's end trying to come up with an alternative solution to this problem. I was hoping there was an easy way to grab a privileged token on the host machine and impersonate it for this program, but I haven't found a way.



If anyone knows of a way around this, or even has suggestions on things that might work, please let me know. I really appreciate the help, thanks!

回答1:

By design, no process is allowed to achieve NT AUTHORITY\SYSTEM rights, unless it is started by another process with NT AUTHORITY\SYSTEM rights. The service is a workaround because the Service Control Manager itself is started by the Kernel at system start.

Unfortunately, the operating system is designed to prevent exactly what you're trying to do. If you want to be able to remove your service afterwards, simply grant the user in question SeDebugPrivilege for the local machine and then have the service uninstall itself.

Better yet, have the program whose memory is to be modified change DACLs to allow your administrator access to it's memory without SeDebugPrivilege. Then you don't need to take privilege at all.

EDIT2: And even better yet, just use shared memory in the first place. That's what it's for.