Continuous digging into WinSxS internals give me some surprising results, so I decided to share it, despite previous statements.
First I would like to recommend you old and seems abandoned blog -> https://blogs.msdn.microsoft.com/junfeng/
It is one of the Fusion (aka WinSxS or aka both) developers. I found answer why all this sxs stuff so dramatically remembers me dotnet framework. They share same dev teams, same ideas and same design. Well and same design failures.
SxS all based on various things like parsing manifests xml, manipulating Windows loader behavior and other mostly boring stuff. Introduced to fight against Dll Hell problem, and looking on WinSxS folder size on various computers, it is now Dll Hell problem itself.
Manifest, what do you know about it? Xml shit with dependencies your program will load (+plus sometimes MS put here undocumented backdoors to fix UAC but it is our secret), also here located specific program settings like support of HighDPI and other non-interesting stuff.
Probably all your experience with manifest was about enabling visual styles, using the below manifest from MSDN examples:
How does it will load? Obviously Loader/WinSxS will built path to dll, judging on manifest data and then do load library it, from WinSxS store you might think (that huge directory systemroot\winsxs).
Not so fast!
Before doing so, Windows will check if special feature called "DotLocal" can be used. DotLocal is a algorithm comming from old good days of Windows 2000, yeah so old. It is local dll redirection technique. It behavior was altered few times since Win2k, but it is still here, in modern fresh OS, in Windows 10 RS1. More information about it history -> https://blogs.msdn.microsoft.com/junfen ... direction/. Is it documented? Yes and no, documentation isn't complete and contradictory.
To put it simple.
If ApplicationName.exe.local exists as directory - Windows will try to find assembly components inside it. It they found - Windows will load it. Feeling some dotnet influence here?
How does it related to bypassing UAC and elevating to NtAuthority\System?
Windows autoelevated components such a sysprep (pity app, so much love from malware) has a GUI and they use comctl32.dll. What a surprise!
Lets profile it (you maybe surprised but this thing is something Microsoft unable to do last 7 years).
In red - Windows check if DotLocal redirection available. Nope.
In green - Windows access WinSXS store, because DotLocal unavailable.
So we:
1) Creating sysprep.exe.local directory.
2) Creating assembly component folder.
3) Copying payload as comctl32.dll into final component folder.
In the end we have something like this:
We have multiple autoelevated application with GUI. You know what to do.
Now next part, with all this stuff time to make some fun from UAC itself.
As you know this thing is running as service - NT AUTHORITY\SYSTEM. Can we hijack UAC itself, using above described method? Do you remember that annoying popups from this "not security boundary" feature which it bombards to users? It has GUI and it is inside consent.exe, located in the system32. You maybe don't know but appinfo.dll really loves consent.exe, doing so much hardcore checks (AipVerifyConsent), something like "Is it you consent.exe? I mean are you really from Microsoft?" Yes, shut the fuck up and load me. Btw, since latest RS1 builds UAC window now has new design. New UAC window design - it was really what was required to do with UAC.
We need to load into UAC service and keep it workable, consent.exe imports ONE function from comctl32.dll - TaskDialogIndirect with fixed ordinal, doesn't change since Windows 7. We can forward it to nowhere, (but not to system32\comctl32.dll because it doesn't have it) or try to load real comctl32 from winsxs and call it from here. This doesn't really matter.
Another consent.exe specific problem we need to solve. Since this trash spawns everytime elevation take place IFileOperation used as delivery interface can fail during creating sub directories/copying file. Why? Because Windows will look inside DotLocal directory during interface autoelevation and if nothing found here it will stop loading. And we are risking to face completely unworkable UAC, where you will be unable start anything with admin rights.
Solution is simple - enable DotLocal redirection only after all preparation is done. So you create some directory named consent.exe.shit, create sub directory for assembly component, copy here your file and only after this -> rename consent.exe.shit to consent.exe.local, this enabling DotLocal for application.
Have no idea if this can be done more easily with Wusa, Windows 10 banned it /extract option, so I don't even look on Wusa now.
So in the end consent.exe loads your payload because of DotLocal and executes it with NtAuthority\System rights. Your code is passing execution next, so consent.exe can normally show it dialog and UAC can elevate(or not elevate) user programs. Everytime when UAC will be triggered - your code will be triggered also. Very cool and easy.
Example: we are running eventvwr.exe because it will launch "mmc.exe evenvwr.msc" (mmc.exe is whitelisted for autoelevation with known snap-in - so no UAC dialogs even show), which trigger consent.exe and load our code. Windows 10 RS1, most secured version of Windows? Pfff.
Where it will work: everywhere since Windows 7 up to latest available RS1 build 14379.
What integrity level do we need: medium as on any default Windows setup.
What UAC level do we need for IFileOperation: default as on any default Windows setup.
Affected applications: every using WinSxS components.
This implemented in UACMe v2.5 as method 21 (sysprep) and method 22 (special for consent).
Update 08/07/16
Another post about DotLocal
http://www.hexacorn.com/blog/2015/01/09 ... y-part-23/
which points to the same blog as source I mentioned.
Update 10/07/16
Special update for twitter security experts, who are digging into demagogy.
Where it will work: everywhere since Windows 7 up to latest available RS1 build 14385.
What integrity level do we need: medium as on any default Windows setup.
What UAC level do we need for IFileOperation: default as on any default Windows setup.
Affected applications: every using WinSxS components.
User Account: admin as on any default Windows setup.
First I would like to recommend you old and seems abandoned blog -> https://blogs.msdn.microsoft.com/junfeng/
It is one of the Fusion (aka WinSxS or aka both) developers. I found answer why all this sxs stuff so dramatically remembers me dotnet framework. They share same dev teams, same ideas and same design. Well and same design failures.
SxS all based on various things like parsing manifests xml, manipulating Windows loader behavior and other mostly boring stuff. Introduced to fight against Dll Hell problem, and looking on WinSxS folder size on various computers, it is now Dll Hell problem itself.
Manifest, what do you know about it? Xml shit with dependencies your program will load (+plus sometimes MS put here undocumented backdoors to fix UAC but it is our secret), also here located specific program settings like support of HighDPI and other non-interesting stuff.
Probably all your experience with manifest was about enabling visual styles, using the below manifest from MSDN examples:
Code: Select all
the most interesting part here is dependency block. It tell Windows loader to select proper dll for the given component named "Microsoft.Windows.Common-Controls". This will force Windows load comctrl32.dll from WinSxS folder of given type, version and language, instead of file in system32, which is here for compatibility reasons.<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="*"
name="CompanyName.ProductName.YourApplication"
type="win32"
/>
<description>Your application description here.</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
processorArchitecture="*"
publicKeyToken="6595b64144ccf1df"
language="*"
/>
</dependentAssembly>
</dependency>
</assembly>
How does it will load? Obviously Loader/WinSxS will built path to dll, judging on manifest data and then do load library it, from WinSxS store you might think (that huge directory systemroot\winsxs).
Not so fast!
Before doing so, Windows will check if special feature called "DotLocal" can be used. DotLocal is a algorithm comming from old good days of Windows 2000, yeah so old. It is local dll redirection technique. It behavior was altered few times since Win2k, but it is still here, in modern fresh OS, in Windows 10 RS1. More information about it history -> https://blogs.msdn.microsoft.com/junfen ... direction/. Is it documented? Yes and no, documentation isn't complete and contradictory.
To put it simple.
If ApplicationName.exe.local exists as directory - Windows will try to find assembly components inside it. It they found - Windows will load it. Feeling some dotnet influence here?
How does it related to bypassing UAC and elevating to NtAuthority\System?
Windows autoelevated components such a sysprep (pity app, so much love from malware) has a GUI and they use comctl32.dll. What a surprise!
Lets profile it (you maybe surprised but this thing is something Microsoft unable to do last 7 years).
In red - Windows check if DotLocal redirection available. Nope.
In green - Windows access WinSXS store, because DotLocal unavailable.
So we:
1) Creating sysprep.exe.local directory.
2) Creating assembly component folder.
3) Copying payload as comctl32.dll into final component folder.
In the end we have something like this:
Code: Select all
Trigger sysprep.exe - our code loaded because we enabled DotLocal and we have High IL, because sysprep autoelevate=true and executionlevel=requireAdministrator.C:\windows\system32\sysprep\sysprep.exe.local\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.14379.0_none_2d155300bdac0920\comctl32.dllWe have multiple autoelevated application with GUI. You know what to do.
Now next part, with all this stuff time to make some fun from UAC itself.
As you know this thing is running as service - NT AUTHORITY\SYSTEM. Can we hijack UAC itself, using above described method? Do you remember that annoying popups from this "not security boundary" feature which it bombards to users? It has GUI and it is inside consent.exe, located in the system32. You maybe don't know but appinfo.dll really loves consent.exe, doing so much hardcore checks (AipVerifyConsent), something like "Is it you consent.exe? I mean are you really from Microsoft?" Yes, shut the fuck up and load me. Btw, since latest RS1 builds UAC window now has new design. New UAC window design - it was really what was required to do with UAC.
We need to load into UAC service and keep it workable, consent.exe imports ONE function from comctl32.dll - TaskDialogIndirect with fixed ordinal, doesn't change since Windows 7. We can forward it to nowhere, (but not to system32\comctl32.dll because it doesn't have it) or try to load real comctl32 from winsxs and call it from here. This doesn't really matter.
Another consent.exe specific problem we need to solve. Since this trash spawns everytime elevation take place IFileOperation used as delivery interface can fail during creating sub directories/copying file. Why? Because Windows will look inside DotLocal directory during interface autoelevation and if nothing found here it will stop loading. And we are risking to face completely unworkable UAC, where you will be unable start anything with admin rights.
Solution is simple - enable DotLocal redirection only after all preparation is done. So you create some directory named consent.exe.shit, create sub directory for assembly component, copy here your file and only after this -> rename consent.exe.shit to consent.exe.local, this enabling DotLocal for application.
Have no idea if this can be done more easily with Wusa, Windows 10 banned it /extract option, so I don't even look on Wusa now.
So in the end consent.exe loads your payload because of DotLocal and executes it with NtAuthority\System rights. Your code is passing execution next, so consent.exe can normally show it dialog and UAC can elevate(or not elevate) user programs. Everytime when UAC will be triggered - your code will be triggered also. Very cool and easy.
Example: we are running eventvwr.exe because it will launch "mmc.exe evenvwr.msc" (mmc.exe is whitelisted for autoelevation with known snap-in - so no UAC dialogs even show), which trigger consent.exe and load our code. Windows 10 RS1, most secured version of Windows? Pfff.
Where it will work: everywhere since Windows 7 up to latest available RS1 build 14379.
What integrity level do we need: medium as on any default Windows setup.
What UAC level do we need for IFileOperation: default as on any default Windows setup.
Affected applications: every using WinSxS components.
This implemented in UACMe v2.5 as method 21 (sysprep) and method 22 (special for consent).
Update 08/07/16
Another post about DotLocal
http://www.hexacorn.com/blog/2015/01/09 ... y-part-23/
which points to the same blog as source I mentioned.
Update 10/07/16
Special update for twitter security experts, who are digging into demagogy.
Where it will work: everywhere since Windows 7 up to latest available RS1 build 14385.
What integrity level do we need: medium as on any default Windows setup.
What UAC level do we need for IFileOperation: default as on any default Windows setup.
Affected applications: every using WinSxS components.
User Account: admin as on any default Windows setup.
Ring0 - the source of inspiration
(uacme #23)
