Welcome to MSFN

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.


fdv

Taking back the Registry from TrustedInstaller

75 posts in this topic

Not sure how it happened, but this thread ended up being

"How to open a CMD prompt with TrustedInstaller permissions"

Scroll to page 2, post 29, to see.

Here below is my original message about taking the registry "back" from TrustedInstaller (there is a batch file below to do that, too).

---------------------ORIG MSG---------------------

This is a question about SetACL syntax but since it applies to TrustedInstaller I thought that the Win 7 forum will get greater exposure.

It's also a mini-how to that will help a lot of you who loathe TrustedInstaller.

Below you will find three commands that when executed in order, will strip a given key of TrustedInstaller.

In order, number one makes Administrators the owner, number two assigns and propagates permissions for Administrators on the key and children, number three revokes TI permissions on the key.

Here's the problem I have: I want to be able to:

1. cascade ownership right down through the entire registry from the root HKCR, HKCU etc etc etc keys

2. strip TI permissions from everything in the entire registry from the root HKCR, HKCU etc etc etc right down to every endpoint key

I know there is a -rec yes option to recurse. Won't help scrub the entire registry though.



setaclx64.exe -on "HKCR\CLSID\{CLSID VALUE}" -ot reg -actn setowner -ownr "n:S-1-5-32-544;s:y"

setaclx64.exe -on "HKCR\CLSID\{CLSID VALUE}" -ot reg -actn ace -ace "n:S-1-5-32-544;p:full;s:y;i:so,sc;m:set;w:dacl"

setaclx64.exe -on "HKCR\CLSID\{CLSID VALUE}" -ot reg -actn ace -ace "n:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464;p:full;s:y;i:so,sc;m:revoke;w:dacl"

for {CLSID VALUE} put something like {a86ca2f1-af74-4a74-980b-e185d4ca01b0}

Any ideas?

Edit: I always edit my posts, and this one is no different.

You must do this with an elevated command prompt.

Also, FYI for everyone, the following files have the TI SID in them:

bcdboot.exe

bfsvc.exe

COMPONENTS

setupapi.dll

winlogon.exe

winsetup.dll

wpd_ci.dll

If you really wanted to render TI powerless you could load them up in a hex editor and change one digit of the SID or change it to admins(S-1-5-32-544) and pad out the rest of the string with 90 (noop). I haven't tried this yet.

Edited by dencorso
0

Share this post


Link to post
Share on other sites

Any ideas?

Just a random one. :ph34r:

Is there any reason why one can't make a small batch and let it go through all the Registry, "HKCR\CLSID\{CLSID VALUE}", "HKCU\CLSID\{CLSID VALUE}" etc.?

It will probably take some time but should be usable, or there is some catch that I am completely overlooking? :unsure:

Another random one, would Regacl:

http://www.gbordier.com/gbtools/index.htm

work and behave more like what you want to do?

REGACL v1.3, Copyright Guillaume Bordier 1999, guillaume.bordier@iname.com
Modify registry permissions (local and remote)
usage : regacl <Key> [/{G|R|S} {user|group}:{R|W|F}] [..]
[/RECURSIVE] [/REPLACE]
/G=Grant /S=Set /R=Revoke
R=Read W=Write F=Full Control
Key =[\\ComputerName\]<Hive>\<RegKey>
Hive: remote : HKEY_LOCAL_MACHINE (HKLM) or HKEY_USERS (HKU)
local : remote + HKEY_CLASSES_ROOT (HKCR) or HKEY_CURRENT_USER (HKCU)
Warning : Grant is additive, Set is not (better use /S).
/RECURSIVE apply permissions to subkeys
/REPLACE replace existing permissions
/INHERIT make the setting inheritable to future sub-keys

jaclaz

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

Hey, man!

In answer to the first question, it'd be totally possible to export the registry's CLSID list, open it in notepad++, clean it up, and make a small batch file to go through every value. We want to find a way to not have to do that though.

As for the second program, I'm not too sure it's any different but will look

0

Share this post


Link to post
Share on other sites

to export the registry's CLSID list, open it in notepad++, clean it up, and make a small batch file to go through every value. We want to find a way to not have to do that though.

What I don't understand is the "export the registry's CLSID list" and "clean it up".

As an example, but I need more details to understand if something more is needed, if you run:

reg query HKCR\CLSID\

You already have a list of the CLSID's in HKCR\CLSID\, is not that enough? :unsure:

A (absolutely "fake") code example:

@ECHO OFF
SETLOCAL ENABLEEXTENSIONS
FOR /F "tokens=1,2,3 delims=\" %%A IN ('REG.EXE query HKCR\CLSID\') DO (
ECHO setaclx64.exe -on "%%A\%%B\%%C" -ot reg -actn setowner -ownr "n:S-1-5-32-544;s:y"
ECHO setaclx64.exe -on "%%A\%%B\%%C" -ot reg -actn ace -ace "n:S-1-5-32-544;p:full;s:y;i:so,sc;m:set;w:dacl"
ECHO setaclx64.exe -on "%%A\%%B\%%C" -ot reg -actn ace -ace "n:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464;p:full;s:y;i:so,sc;m:revoke;w:dacl"
)

jaclaz

0

Share this post


Link to post
Share on other sites

Oh! Sure, that will work too. I was thinking of piping it to a txt file but your bit here works better and is pretty creative!

In truth I didn't spend much time on the idea though, because I really want to cover items 1 and 2 in my post, essentially "fix" the child objects.

What I think I would have to do is use the 'reset children' command and then re-assign, with inheritance, permissions for System, Admin, and User. That's the problem with the reset children command, it seems to erase other non-owner permissions which is obviously a bit of a problem. Hoping for a better way.

0

Share this post


Link to post
Share on other sites

What I think I would have to do is use the 'reset children' command and then re-assign, with inheritance, permissions for System, Admin, and User. That's the problem with the reset children command, it seems to erase other non-owner permissions which is obviously a bit of a problem. Hoping for a better way.

I still cannot understand fully what you need/want to do.

Generally speaking, since you are talking of Windows 7, Powershell has seemingly a few powerful methods to deal with ACL, but my knowledge on them ends right here.

http://waynestorey.com/blog/2012/01/31/change-permissions-on-registry-hive-recursively/

This may be something like it:

http://blogs.technet.com/b/ashleymcglone/archive/2011/08/29/powershell-sid-walker-texas-ranger-part-1.aspx

http://blogs.technet.com/b/ashleymcglone/archive/2011/09/16/powershell-sid-walker-texas-ranger-part-2.aspx

jaclaz

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

I wouldn't strip Trusted Installer of any rights, instead I'd search for a way to grant myself (and my group) full rights. I've seen strange things happen when TI is dethroned, from bsod on boot to unprovoked re-registering of all the useless default filetypes and clsids (partially), to unability to install Windows Updates. It's linked to MSI service and/or Windows resource protection in a "dirty", undocumented way, from what I've seen.

But partial dethroning is OK (I've succeded with Classes and everything works).

*Edit: and propagation rarely works not because they've set a new system of ACL (what I thought in the Vista era), but because of the way default permissions are set during install. I strongly suspect this is the reason for invention of WIM.

*Edit2: And the default liberal permissions for Creator/Owner (wildly exploited now) are not a "courtesy" of Microsoft, but a failsafe to prevent disasters.

GL

Edited by GrofLuigi
0

Share this post


Link to post
Share on other sites

I wouldn't strip Trusted Installer of any rights, instead I'd search for a way to grant myself (and my group) full rights. I've seen strange things happen when TI is dethroned, from bsod on boot to unprovoked re-registering of all the useless default filetypes and clsids (partially), to unability to install Windows Updates. It's linked to MSI service and/or Windows resource protection in a "dirty", undocumented way, from what I've seen.

Yes :), but you also must remember how you CANNOT have an XP without Internet Explorer ;)

:lol:

jaclaz

0

Share this post


Link to post
Share on other sites

I wouldn't strip Trusted Installer of any rights, instead I'd search for a way to grant myself (and my group) full rights. I've seen strange things happen when TI is dethroned, from bsod on boot to unprovoked re-registering of all the useless default filetypes and clsids (partially), to unability to install Windows Updates. It's linked to MSI service and/or Windows resource protection in a "dirty", undocumented way, from what I've seen.

Yes :), but you also must remember how you CANNOT have an XP without Internet Explorer ;)

:lol:

jaclaz

Sorry, but I don't understand what you're aiming at. And I like to consider myself as having some sense of humor. :angel

GL

0

Share this post


Link to post
Share on other sites

He means that people used to think it was "impossible" to run Windows 98 without IE, then someone did it. Then it was "impossible " to run Windows 20o0 without IE, and someone did it. Then it was "impossible " to run Windows XP without IE, and someone did it.

In other words, there is some exception to any rule -- if you say TI should not be stripped of any rights, he is saying that it might be possible to rig a system having done exactly that.

What really troubles me is that no one has tried.

I mean, just loading a hex editor and replacing the TI SID with the admin SID S-1-5-32-544 and padding out the extra characters should have been tried at some point, and yet no one has done it! TI honestly does not look like an "octopus," it only has a certain number of connections to and within the OS. It isn't really "everywhere." And yes, it's in the MSI. But it remains to be seen what happens if another SID is substituted.

Edit, as usual. To explain further and give thoughts... The TI is actually a service, not a user. S-1-5-80 starts all service SIDs. As long as the service is running, will Windows be happy? If we replace it in terms of object ownership? Rip it out from every ACL? As long as the stupid exe runs as a service, maybe windows won't "know" and can be tricked. That's the nitty gritty of where jaclaz and I are going with this thought process.

Edited by fdv
0

Share this post


Link to post
Share on other sites
What really troubles me is that no one has tried.

We don't really know that. Younger people prefer blogs (which then disappear in the night) and IM over forums, and don't really love documenting what they did to get the job done. So, it may have been done already but never documented anywhere. :wacko:

But I think GrofLuigi has a point, too: but my take is it may not be necessary to dethrone TI, provided everybody in the Admin group has equally full rights... democratizing TI's rights surely is the kind of subversion that fits my tastes. :D

Then again, blowing WRP to smithereens can maybe be simpler to accomplish...

0

Share this post


Link to post
Share on other sites

@Grofluigi

Though your advice seems sound and most probably valid :thumbup , I think that you cannot really say until you have tried doing it, and possibly tried doing it again and again with some different settings.

As fdv pointed out, we were told for a few years how (examples):

  • you cannot strip IE from a Windows OS
  • you cannot boot a NT based OS from USB
  • you cannot boot a NT OS from an image
  • you cannot make a "portable" XP

but every time someone took the time to try doing it, if he/she insisted enough, and with the cooperation/ideas/support of a bunch of other peeps, the "said to be impossible" chore resulted after all possible.

This does not mean of course that everythng said to be impossible is possible, only that before confirming such impossibility, some "serious" attempts to do it should be made. :)

In these regards fdv has proven in the past to possess the abilities and patience (and ingenuity, and a lot of other qualities) that made possible to strip IE from 2K and XP:

http://www.vorck.com/windows/

so he is - as I see it - particularly "qualified" to do "strange, perverted and potentially dangerous things" on a "poor (almost) innocent little Windows OS" ;).

jaclaz

0

Share this post


Link to post
Share on other sites

The problem isn't that TI has too much rights, but that we (Administrators) don't have enough. My thinking is, if Microsoft built it that way, and it isn't standing in my way, i'd rather leave it alone.

I have killed several windows installations, but sadly I didn't document my steps. Every time I was "nearly there" and it was like Windows was toying with me, knew what I was doing, let me approach the finish line and than dropped the hammer.

About WRP: I've disabled WRP with instructions from here and Windows ended nearly unusable - couldn't install updates or (maybe, I forgot) regular programs, and there were many other problems (some control panel items won't start). To add insult to injury, I couldn't add the files back to WinSXS, even from other OS. I wouldn't recommend this route yet.

What I think are promising courses of action:

- Adding TI "token" to yourself or Admin group. I don't know if that's even possible, but it would be way better than for example, running yourself as TI (as Den mentioned somewhere).

- Giving ourselves and TI full permissions to (almost) entire registry and filesystem tree. It would save us (at least me) tons of headaches and time when thinking about is it safe to "process" the desired item (take ownership etc.) . Some may say it's defetism, but I really have nothing against the guy. TI can be ADDED from GUI like this.

- I am wary of hex editing and would leave it to the king here. :yes:

GL

0

Share this post


Link to post
Share on other sites

You rock, GrofLuigi! :thumbup

I had utterly forgotten all about natsumerio's work (of course I'm growing old, but it seems my memory is failing me, too, sometimes :blink: ). While I'm not even near jaclaz's class, in what regards remembering things and locating related info, I'm usually not that absent-minded. I see I must do some mnemonic gymnastics right away, to shake off the rust from my brain!!! :D

Of course natsumerio's approach is with a war-axe, not a scalpel, so things are bound to get nasty. But, then again, it sure is yet another starting point to consider, and interesting info in itself.

0

Share this post


Link to post
Share on other sites

FYI: I tried my Session0Cmd on a 64-bit Windows 7 SP1, and was able to execute commands with privileges of TI like this;

Start the TrustedInstaller service and obtain the PID of the process. Then run with syntax like this:


session0cmd_x64 2004 "cmd /c echo HelloWorld > C:\Windows\winsxs\hardtodelete.txt"

That's a PoC, and the number 2004 equals the PID of TrustedInstaller.exe. Ie, the above command is run with the same privileges as what the PID it is injected into, have. At worst trustedinstaller process crash, for which you can restart the service. The tool requires admin privileges. Not sure if it's of any use though.

Download; http://reboot.pro/files/file/171-payload-execution-tools/ or my mediafire account

Edited by joakim
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

Great idea! :thumbup

0

Share this post


Link to post
Share on other sites

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:

rwMrY.png

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

0

Share this post


Link to post
Share on other sites

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

0

Share this post


Link to post
Share on other sites

psexec works for sure.

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

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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

Edited by joakim
0

Share this post


Link to post
Share on other sites

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

You talkin' to me? :unsure:

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

;)

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

:whistle:

jaclaz

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.