Windows 10 Redstone 1/2 UAC changes
^Image courtesy of @buildfeed.
11 April 2017 is set to Redstone 2 release date. Among with other "improvements" and "innovations" it will bring updated UAC with fix of some currently widely malware abused exploits. I decided to refresh some data about UAC and here we go. Lets take a journey in Redstone UAC changes, including implemented in RS1 9 month ago.
First of all, personally I think Windows 10 is worst operation system MS released since Windows 8. Fucking bugged as hell (you can't replace qualified beta testers with horde of monkeys - so called "windows insiders" without consequences) with UI created by autistic designers and new generation of system programmers rised from dotnet/hackforums. So for me it is sort of Mass Effect Andromeda, if you know what I mean. But it still have some research potential that's why you see this and it bring a lot of fun, all this bugs, they even cute and very funny sometime.
For the adepts of "not security boundary" read this thread I already mentioned why I don't give a fuck about this demagogy, but tl;dr - since malware don't care about this, why should I care about it, just because of failed MS marketing? It is really nice excuse when you have some ransomware running as NT AUTHORITY/SYSTEM just because it wasn't "boundary". Well ok. As Vault7 show CIA think the just like me and all of the "russian hackers" too (but it is secret I didn't tell you this).
Despite known demagogy from so-called "experts" about security this or not (while even windows sources shows uac in security category) since Windows 10 MS actively deploying UAC fixes. Number of them in TH1 and even more in TH2/RS1 and now in RS2.
Lets take a closer look on what was fixed in RS1 and then what was fixed in RS2.
UAC Fixes & Improvements
1) Metasploit
A well-known Metasploit framework implemented UAC bypass using non existing dll in system32 called ntwdblib.dll. As trigger there was cliconfg.exe - it was autoelevated and requestedExecutionLevel was requireAdministrator. During it startup it was loading this non existent dll without any kind of additional checks inside code. So by dropping malicious dll in system32 and starting cliconfg.exe malware code was jumping to high IL. This method was known for a long time and abused by ITW malware. It was fixed only starting from Windows 10 RS1 preview builds. What was preventing MS to fix this ridiculous method before RS1 while it was publically available even before TH1 release? Well malware also need some space in Windows eco system, especially new versions, that's the only rational explanation why.
The fix implemented by MS was also ridiculously simple. They blocked cliconfg.exe from autoelevation in manifest. So now it will give user UAC prompt every time even on default UAC settings. We can discuss why it was that hard to check digital signature of ntwdblib.dll with WTGetSignatureInfo before loading it and leave cliconfg.exe autoelevated, well MS decided it doesn't require autoelevation now. Was required since Windows 7, required in Windows 10 TH2 and now magically NOT required. Well ok.
2) IIS
As it was discovered before in Windows 10 TH2 Microsoft reworked some code in Appinfo restricting autoelevation to be only from several hardcoded places, such as system32/syswow64 and two special executables hardcoded with their full path - sysprep and inetmgr. Before this was a problem - GIGANTIC hole in UAC logic when it allows execution of copied autoelevated binaries from number of existing directories or NEWLY created directories inside Windows. With this UAC innovation our little friends from Win32/Cerber, H1N1 and a lot of other malware groups will be forced to use something different to bypass UAC in modern Windows version. It was cool innovation but problem was that InetMgr wasn't installed by default. So you basically can locate it in WinSXS store, expand if needed, drop to hardcoded directory \system32\inetsrv and exploit classical dll hijack. InetMgr.exe is not only autoelevated and requireAdministrator it is also listed in ais!g_lpAutoApproveEXEList.
I'm very happy that MS read some tweets and visits github so they were aware of this method.
Exploited in the wild? Unlikely, at least not known till the moment.
MS took this really seriously and fixed this step by step in a few Windows 10 RS1 insider builds.
First of all they implemented manifest dll redirection
Code: Select all<!--
Specifically load DLLs from the specified path as defence-in-depth
protection against known UAC bypasss exploit
-->
<file
loadFrom="%systemroot%\system32\inetsrv\iisutil.dll"
name="iisutil.dll"
/>
This wasn't enough. Then in next RS1 build they used Process Mitigation Policy for InetMgr.exe. When you install IIS the new entry will be created in IFEO key for InetMgr.exe and MitigationPolicy value will be set to newly added in RS1 "ProcessImageLoadPolicy". From msdn ->
https://msdn.microsoft.com/en-us/librar ... s.85).aspx
The policy regarding image loading for the process, which determines the types of executable images that are allowed to be mapped into the process. When turned on, images cannot be loaded from some locations, such a remote devices or files that have the low mandatory label.
They used PreferSystem32Images for InetMgr.exe which described as
https://msdn.microsoft.com/en-us/librar ... s.85).aspx
Set (0x1) to search for images to load in the System32 subfolder of the folder in which Windows is installed first, then in the application directory in the standard DLL search order; otherwise leave unset (0x0).
Very nice. Why this wasn't implemented together with AppInfo changes?
Even without this key InetMgr attempt to load all it dependencies from system32 folder as default unless directly started as admin. So we have there real defence-in-depth approach.
3) External manifests
Before RS1 it was possible to hijack dll loading for MS applications without manifest -> described here
http://www.kernelmode.info/forum/viewto ... 579#p28579. Since RS1 earlier preview builds from observation external manifest redirection dlls simple ignored. Why it wasn't here since beginning?
4) Abuse of g_lpAutoApproveEXEList
This array of whitelist executable names is sort of Microsoft comedy section. Besides fixes targeting it I will you tell why most of it now simple dead trash. This list is well described before in this thread. This list is mix of compatibility reasons and invability to redesign some applications. Here is official mention by MS about this list ->
https://technet.microsoft.com/en-us/lib ... 7.uac.aspx. This article was mostly bullshit even in moment of publication in 2009, just a long excuse to backdoor MS added in Windows 7. Last time Microsoft changed this list was response to Sandworm malware which abused InfDefaultInstall.exe whitelisted in this array. So they just removed it from this list as part of security update (remember "boundary" bullshit)
The comedy section part of this list was: most of the whitelisted executables does not exist in Windows installation. But they whitelisted for autoelevation. So looks like you can name your malware with name of phantom executable from this list, drop it to Windows and it gets autoelevated. Or you can copy existing autoelevated executable with new name from and exploit dll hijack in different location.
Simple example, implemented in UACMe.
Copy system32\sysprep\sysprep.exe to system32 as "oobe.exe" and hijack it unbcl.dll dependency with our dll with forwarded import to real unbcl.dll. Excellent security model, Ais developers.
So it was obviously in todo fix list. And they finally did it!
It was 14371 build and AppInfo.dll was upgraded with new functions inside.
Starting from this build UAC will perform 2 additional checks around executable with name from
g_lpAutoApproveEXEList. If any of it fails UAC will hardblock executable from execution with red faced UAC dialog.
New code implemented in
AipIsValidAutoApprovalEXE and called from infamous
AiIsEXESafeToAutoApprove.
Check 1.
Call
WTGetSignatureInfo over the file. You can take prototype and all required definitions from MS Powershell project on github. Why not on MSDN? Because it is "officially" "publically" "visible" undocumented,
.
Here is the simple code illustrating AIS work.
Code: Select allmemset(sigData, 0, sizeof(sigData));
sigData.cbSize = sizeof(sigData);
WTGetSignatureInfo(lpFileName, hFile,
SIF_BASE_VERIFICATION | SIF_CHECK_OS_BINARY | SIF_CATALOG_SIGNED,
&sigData,
NULL, NULL);
Our executable will be verified to be signed via catalog (SIF_CATALOG_SIGNED) and be a part of operation system release (SIF_CHECK_OS_BINARY).
If
WTGetSignatureInfo fails or any of above requirements failed - app will be hardblocked. This blocks random executables whitelisting.
Check 2.
Our executable is genuine Microsoft binary. Then Ais call
AipMatchesOriginalFileName to ensure executable file name is the same as original file name set in VERSION_INFO resource. If this check failed - app will be hardblocked. This blocks renamed executables whitelisting.
This effectively block described above scenario with sysprep and other of this kind. So it took MS 8 years to implement this ~50 lines of code to close another gigantic hole in UAC. As in fact this was a biggest update to UAC in RS1.
Now look on the list in RS2
Code: Select allAutoApproveEXE: cttunesvr.exe <-phantom
AutoApproveEXE: inetmgr.exe
AutoApproveEXE: migsetup.exe <-phantom
AutoApproveEXE: mmc.exe
AutoApproveEXE: oobe.exe <-phantom
AutoApproveEXE: pkgmgr.exe
AutoApproveEXE: provisionshare.exe <-phantom
AutoApproveEXE: provisionstorage.exe <-phantom
AutoApproveEXE: spinstall.exe <-phantom
AutoApproveEXE: winsat.exe
With the above changes NONE of the phanton executables will be able to start. They all will be hardblocked even if they have valid digital certificate embeded. Simple because they are NOT the part of operation system release and not inside secure directories. Good job MS in supporting list of ancient shit just to block it in attempt to allow, ROFL.
5) Race condition while using CleanMgr.exe/DismHost.exe
Described by Enigma0x3
https://enigma0x3.net/2016/07/22/bypass ... k-cleanup/
Main advantage of this method was bypassing AlwaysNofity UAC setting. Main disadvantage (that's probably why it wasn't used by malware ITW) was method complexity and hard binding to Windows 10. Root of the problem was file security permissions allowing non elevated process to overwrite files in target directory. In 15031 Microsoft fixed this by setting required file permissions disallowing write access for non elevated code. Why MS genious didn't do this from the beginning? Nobody knows, probably they don't know that they should.
6) ShellExecute and Mscfile
Described by
https://enigma0x3.net/2016/08/15/filele ... hijacking/. For now it is most popular method used by ITW malware, most popular maybe since sysprep times. It key features: simplicity and availability. Works from Windows 7 up to Windows 10, all you need - one modification in registry key which non elevated applications can control. An epic gift to malware. MS aware about it and produced fix in RS2 preview build 15007. They redesigned EventVwr.exe to replace
with
Code: Select allCreateProcess "mmc.exe" eventvwr.msc
They targetted exactly Enigma0x3 described execution flow. In fact they ignored publically available information about another executable with the same behavior -> ExpLife,
http://www.freebuf.com/sectool/114592.html. So yes, they do not understand method and do not want to do any complex fixes in UAC. Why ExpLife managed to check all possible applications to be vulnerable to this method and MS didn't? Rhetorical question. You just replace EventVwr.exe with CompMgmtLauncher.exe and method works again in 15007.
Note that even with RS2 release all old OS versions will be vulnerable to this method, so it will be for long in malware.
In 15031 they finally discovered CompMgmtLauncher.exe and produced fix. But lets take a look on another method fixed together with this in 15031. It uses the same trigger application but in completely different way. Meet Comet.
7) Comet
Published by BreakingMalware,
https://breakingmalware.com/vulnerabili ... -revisited, successfully working from Windows 7 up to Windows 10.
The most irony part of this method is CompMgmtLauncher.exe itself, just think about it, system application set to be autoelevated/requireAdministrator which purpose is to execute LNK file from "don't give a fuck" location. Wow, just wow.
MS fixed this method along with Enigma0x3 in RS2 starting from 15031 build. They blocked autoelevation for CompMgmtLauncher.exe and set it requestedExecutionLevel to "asInvoker". Was this autoelevation/executionlevel even required for CompMgmtLauncher.exe since beginning in case of default user account? Unlikely. Simple because mmc.exe which it launch with command compmgmt.msc through LNK file will be autoelevated because it is in
g_lpAutoApproveEXEList and valid Microsoft snapin specified as parameter. Also don't forget mmc.exe has highestAvailable executionLevel. This is not the first time when MS gives their executable more power than they actually need.
This downgrade of CompMgmtLauncher.exe also affected Enigma0x3 method, and ExpLife addition successfully fixed.
IFileOperation redesign
This documented interface is a key delivery mechanism used by all methods with dll hijacking. In upcoming Windows 10 RS2 Microsoft tried to change it, resulted in breaking all available code (simple because it is copy-paste from
http://www.pretentiousname.com/misc/win ... list2.html). As in fact MS reviewed IFileOperation flags and their combinations. They even managed to broke some Explorer.exe functionality in earlier RS2 builds (fixed now). This change will not affect interface functionality and only break like 99% of the "super-puper private zeroday bypasses" available on malware market as part of malware or standalone (yeah in 2017 year they still selling uac bypass).
Unfixed methods in upcoming Windows 10 RS2 release
Lot of them.
1) First of all MS completely ignored WbemComn.dll phantom dll loading ->
http://www.kernelmode.info/forum/viewto ... 872#p28872. Widely blogged and implemented with various applications as triggers, e.g.
https://github.com/Cn33liz/TpmInitUACBypass,
http://www.fuzzysecurity.com/tutorials/27.html
2) They ignored everything related to DotLocal SXS, well ok, let your WinSXS hack-o-rama work for many many years, until another "russian/chinese/<put random country US govt don't like> hackers" story with UAC exploit as part of "APT". Well as in fact IFileOperation change broke it and it took me few minutes to get it back to work.
3) PkgMgr.exe and Dism, unfixed till now and I heard some rumours of it being used by "russian hackers" of course in some kind of "APT".
4) IARPUninstallStringLauncher, it is another undocumented COM interface which can be used to bypass UAC, found and described by ExpLife. Advantages: very simple, not require additional files on disk, all changes take place in registry. Implemented in UACMe as 27.
5) Wow64 Logger, mentioned before here, ignored by MS. Ok, implemented in UACMe as 30. Advantage - works everywhere since Windows 7 and with every autoelevated wow64 app.
6) Recently published by Enigma0x3 ShellExecute "runas" plague, when you control runas key in registry and can alter ShellExecute behavior.
Enigma0x3 mentioned sdclt.exe with /kickoffelev param, there also other application which can be used for this method:
rstrui.exe with /runonce param
SystemSettingsAdminFlows.exe with PushButtonReset param (this one uses "runas" from full admin application, fucking facepalm MS).
Some other executables also have potential.
Advantages of this method: simplicity. So I think malware will switch to this method for Windows 10 RS2 along with continuing exploiting "mscfile" for everything below.
7) Recently published by Enighma0x3 App Path method.
sdclt.exe uses ShellExecute("contol", "open") which gives us ability to alter ShellExecute behavior because we can control App Paths registry key. Why this code even exist in this form in sdclt? Too many questions without answers.
p.s.
As above shows - even AlwaysNofity setting not "always" help against UAC bypass methods. UAC in Windows leaves too many questions behind, no surprise all is the result of redesign to complete shit in Windows 7 and absense of any kind of strong internal MS rules regarding giving "autoelevated" ability to applications <- so every idiot can mark his/her application as autoelevated even if it purpose is to ShellExecute fucking LNK file.
