Taking back the Registry from TrustedInstaller

[joakim]

I was thinking a little more about this TI stuff, and believe it is possible to make a workaround. Since we can easily duplicate the token of the TI process, all we need to do is start a process with this token and make it interact with us. But by design this is not easily possible, but I think it still is possible. I was thinking of having a "server" part running in session0 with this token, and communicate out by some means to current user in sessionX through IPC/named pipes and read the commands. ImpersonateLoggedOnUser will help us reach our user session. The ipc could be tricky to get going though. Not sure.

[dencorso]

Great idea!

[CoffeeFiend]

I was wondering why is this even necessary in the first place (running as TrustedInstaller). Wouldn't starting a process or service as NT AUTHORITY\SYSTEM be unlocked enough? I mean, that shouldn't be blocked from doing anything really and it's really simple to do:

Edit: unless you want to *disallow* TrustedInstaller from doing something, which could easily cause loads of problems.

[dencorso]

Do the same methods that worked on XP succeed in making you the System user (= NT AUTHORITY\SYSTEM)?

[CoffeeFiend]

psexec works for sure.

Then again, just like the "other thread" I have *no* idea what we're really after

[dencorso]

That's the best way of doing it. The oldest one is: at xx:xx /interactive %sysdir%\cmd.exe, where xx:xx is, say, one minute hence. This I bet doesn't work on Win 7, especially the x64 version, but I may be wrong.

We're after getting total control of the system, for the rare occasions on which that's handy, IMHO.

[joakim]

The "NT AUTHORITY\SYSTEM" account is by itself not enough to modify stuff inside the WRP protected areas. For instance the winsxs folder (and sub folders) are blocked, and if you run cmd.exe as just "NT AUTHORITY\SYSTEM", then you get access denied. You need more, ie similar to what the token of the trustedinstaller has. That's why I showed the command with session0cmd and how it can give you the right privileges. For some unknown reason, it seems not possible to just switch into an interactive session with anything running with trustedinstaller privs (something you easily can if just "NT AUTHORITY\SYSTEM" is granted and nothing more). But despite not being totally inetractive with session0cmd, at least we can issue commands/start other programs from there.. But still, it would be interesting to create something inetractive as can possibly be done with ipc accross sessions.

[jaclaz]

@dencorso

JFYI, and on XP (and NOT - I think - on newer NT systems):

http://www.grubletrang.com/SoftwareList.aspx

http://www.grubletrang.com/Software.aspx?app=PowerPrompt

jaclaz

[joakim]

Are you sure this tool is able to replicate the privs of the trustedinstaller? Can someone verify in Windows 7?

Edited March 20, 2012 by joakim

[jaclaz]

Are you sure this tool is able to replicate the privs of the trustedinstaller? Can someone verify in Windows 7?

You talkin' to me?

http://en.wikipedia.org/wiki/You_talkin'_to_me%3F

JFYI, and on XP (and NOT - I think - on newer NT systems):

jaclaz

[joakim]

Never mind. I am fairly sure the right way to go is by duplicating the token of the TrustedInstaller and expand on that as already described.

For instance spot the difference in output from cacls;

c:\windows\winsxs

NT SERVICE\TrustedInstaller:(OI)(CI)F
BUILTIN\Administrators:(OI)(CI)R
NT AUTHORITY\SYSTEM:(OI)(CI)R
BUILTIN\Users:(OI)(CI)R

c:\windows\system32\config

NT SERVICE\TrustedInstaller:(CI)F
NT AUTHORITY\SYSTEM:(OI)(CI)F
BUILTIN\Administrators:(OI)(CI)F
CREATOR OWNER:(OI)(CI)(IO)F

[joakim]

I quickly compiled a lame server communicating over tcp/ip and accepting commands over port 6666. All good and well as the commands sent by the client was in fact executed if valid. Ie, the server was started by having Session0Cmd injecting it into the TrustedInstaller.exe process. But it was probably the lamest server/client application created this century..

I then realized what the best solution actually is. Grab a copy of good old netcat and inject it with Session0Cmd. Then use netcat and connect it to your localhost. And guess what. A running and interactive cmd.exe in sessionX that has all the privileges you could ever dream of. You don't get more privs than that! So the commands I used;

Session0Cmd 2003 "nc -l -p 6789 -d -e cmd"

Now netcat is running as a daemon and serving cmd.exe for you on port 6789. To connect to it and obtain the actual TI-privileged cmd, open a cmd window and use this command;

nc localhost 6789

Good luck hacking your system Hope you know what you're doing.

[dencorso]

Awesome, joakim!

A strike of genius!

You do rock!

[fdv]

Okay. For those of you just tuning in, Joakim has actually managed to do what several folks including myself had said was not possible -- open a CMD prompt with TrustedInstaller permissions.

Life happens fast, and so did this thread. Here's how to do it in one post. Thanks to all of you who contributed your wisdom. Like CoffeeFiend I'm also kind of lost as to how we managed to get here

------------

How to open a CMD prompt with TrustedInstaller permissions

Install PSList - http://technet.microsoft.com/en-us/sysinternals/bb896682

or

Install Procexp - http://technet.microsoft.com/en-us/sysinternals/bb896653

Install Session0Injectors from Payload Execution Tools v.2 - http://reboot.pro/files/file/171-payload-execution-tools/

Install netcat - http://www.securityfocus.com/tools/139

You must do the next part fairly quickly, because once you start the TrustedInstaller service, it's not going to run all day... it stays running for a short while and stops.

Run services.msc

Scroll to Windows Modules Installer

Right click, select 'start'

Open a command prompt and type pslist trustedinstaller and get the PID or launch ProcExp and get the PID

Let's call that number '4321' (of course it will be different on your system)

Let's also pick a port to run netcat on -- say '6789'

"Now run netcat as a daemon serving cmd.exe for you on port 6789 by typing the following"

Session0Cmd 4321 "nc -l -p 6789 -d -e cmd"

(By the way, that -l is the letter l not the digit one. If your system is 64 bit Windows, you'll use Session0Cmd_x64 here))

If you got an error about an invalid PID, it means that the TrustedInstaller service stopped again. Go restart it. (When you do it will have yet another PID).

"Now netcat is running as a daemon and serving cmd.exe for you on port 6789. To connect to it and obtain the actual TI-privileged cmd, open a cmd window and use this command"

nc localhost 6789

Thanks again to Joakim for this bit of cleverness!

(I'm sure you'll all let me know if I need to make edits...)

Edited March 21, 2012 by fdv

[joakim]

I forgot to explain properly that the reason why session separation is not blocking our shell, is because the process itself (the cmd window that we type the commands in) is not running inside session0. It is the other part of the network connection that is session0, and obviously is "invisible". We therefore communicate of TCP/IP into our session0 TI-privileged server. For that reson no GUI can be launched during such a session, and we are limited to command line utilities (but who cares..).

It would thus not surprise me if MS added some memory protection to the TrustedInstaller service at some time in the future.