Since Windows 7 UAC is one of the biggest malware targets. I do remember when Vista released, back in 2006, malware authors publicly and privately sadly commented that this "feature" makes their lives complicated. I was then doubt UAC can stand as it was for a long. And yeah, Windows 7 (thanks to MS marketers and bunch of idiots) turned it into ridiculous piece of shit.
Despite the fact it was one of the malware attack targets for years Microsoft did nothing to fix it bugs until release of Windows 8.1 and started actively fix it from Windows 10 early builds up to current date. Results of this marketing failure -> multiple malware abusing Middle -> High IL elevation in the default system configuration which probably most of people use.
UAC itself is user mode wrapper implemented as service where most of core logic/code located inside APPINFO.DLL (located in system32 folder). How it works described already in a few blogposts and presentations (for example https://www.syscan360.org/slides/2013_Z ... truder.pdf
). This UAC code is one of the most funniest things in Windows (along with SCM). When you look for new UAC bypass methods this appinfo.dll must be the first place for checking. When Windows 7 released it introduced several backdoors and hacks which were intended to fix UAC behaviour and make it less annoying for users. Unfortunately ALL of them are UAC bypass methods. It was only a matter of time (and the will) when they all will be discovered and used by malware. So Microsoft developed and integrated most of the currently working UAC exploits because of laziness and marketing failures of Vista. Is the any other ways for them at this moment? Probably yes, but they all aren't that simple and fast. So what they did (list can be incomplete):
1) key documented (https://msdn.microsoft.com/en-us/librar ... s.85).aspx
) autoElevate backdoor, allowing Microsoft applications silently autoelevate with default UAC settings;
2) documented and undocumented autoelevating COM inferfaces, for example IFileOperation (https://msdn.microsoft.com/en-us/librar ... s.85).aspx
) and undocumented COM interface ISecurityEditor allowing silent autoelevated file / objects security operations with default UAC level;
3) whitelist of applications that are "safe to auto approve" (I suppose it was created mostly to handle mmc.exe). It purpose - allow silent autoelevation of whitelisted applications with default UAC settings.
Security through obscurity is the result. How long it take to figure all this out? Maybe few days I don't know, most people just put windows under debugger since betas and figured out new "features" even before Windows 7 release.
Just some wondeful fact you probably don't know. Microsoft ISecurityEditor backdoor interface has been exclusively used by WinNT/Simda malware since early 2010 until 2015 year WITHOUT any reaction from Microsoft. They broke this interface only after public posts about it and only in Windows 10 builds. Despite the fact their MMPC team have samples of this malware FOR YEARS and even analyzed them. WTF is this? This is unprofessional and incompetent or in russian if you like "pohuizm".
So what reaction of so-called security experts (eqv. to incompetent random twitter/blogger posters). "UAC is not a security feature", "UAC is not a security boundary", "UAC is not <put your smart term here>". Guys, malware actually don't give a fuck. So from where all this stuff initially started?
Here is the source -> incompetent bullshit blogpost motivated by Microsoft marketing division -> https://blogs.msdn.microsoft.com/e7/200 ... te-on-uac/
Here you see "explanation" and "excuse" for future revealed backdoors and exploits. Nice job Microsoft.
Another blogpost which "experts" usually like to link -> https://technet.microsoft.com/en-us/mag ... 7.uac.aspx
, it reveals common "failures" of upcomming UAC in Windows 7 and makes long story to excuse them.
So, tl;dr paraphrase
The most basic element and direct benefit of UAC's technology is simply making Windows more standard-user friendly.
The most basic element and direct benefit of UAC's technology is simply making Windows more malware friendly.
Windows 8.1 was the version that implemented first UAC fix. Yes, ~5 years after "improved" UAC release. Microsoft "fixed" dll-hijack of sysprep.exe (systemroot\system32\sysprep). Interesting that they used SxS undocumented feature (or call it backdoor) to do this. Well they actually failed to fix anything in sysprep and it still used to bypass UAC up to current 14352 build, but this is not a point of story. This fix revealed new wonderful and easy to use backdoor we will discuss later.
Windows Side-by-side Assembly (SxS) implemented in sxs.dll, if you have enough interest and time look inside of it, it is interesting to explore (despite it is written in a trash C++). An application that employs SxS must have a manifest, a special XML written block of configuration data. Manifest can be internal embedded inside PE file or external. Built-in manifest has a priority over external. More documentation and explanations can be found on MSDN, see link above.
So lets take a look on sysprep failed "fix" from Windows 8.1 (in red).
<?xml version='1.0' encoding='utf-8' standalone='yes'?>
<!-- Copyright (c) Microsoft Corporation -->
<description>System Preparation Tool</description>
Specifically load these DLLs from the specified path. This
is done as a defence-in-depth approach to closing a known UAC
exploit related to Sysprep.exe being auto-elevated. The list
need not contain KnownDlls since those are always loaded
by the loader from the system directory.
Microsoft was so cute so they even provided explanation comment, thanks! So these lines force Windows loader load selected dlls from specified location, ignoring DLL search path. Hmm does "file" element has "loadFrom" attribute documented? https://msdn.microsoft.com/en-us/librar ... s.85).aspx
, no. Nice new undocumented backdoor. Does older version of Windows support it? Yes, you can find loadFrom references inside sxs.dll in Windows 7 and it works. And we can tell Windows autoElevate our application, but it is documented, already exploited in "windows script host vulnerability" and not interesting at all. Additionally Windows 10 seems completely ignore this element in external manifest (wow).
So we can do direct dll redirection using manifest file. Does it looks like UAC bypass? Oh yes. We need to locate proper target:
1) Microsoft known/approved application;
2) dll dependencies that can be exploited;
3) no internal manifest.
Quick scanning over Windows directory revealed multiple possible targets. Windows behaviour between different version sometimes reminds me good old korean random. This is the same case. For bypass UAC in Windows 7 we will use one way, for 8+ different.
We use documented IFileOperation of course as Microsoft killed wusa /extract on Windows 10. But we will use it with small remark -> http://www.kernelmode.info/forum/viewto ... 249#p28249
Surprise, surprise - it is popular CRYPTBASE.DLL, it is loaded and executed everywhere and for unknown reasons Microsoft geniuses still not put it into KnownDlls (but did this for KnownDlls32 rofl), even in Windows 10 RS1.
Target dll location.
Oh lets use sysprep folder. For years it was abused by malware, why not continue good old tradition.
Simple with only few elements.
Code: Select all
<?xml version='1.0' encoding='utf-8' standalone='yes'?>
Your "defence-in-depth approach" is actually yet another
undocumented backdoor. I sincerely hope you will never
do anything more complex than coding Tetris.
taskhost.exe for Windows 7 and tzsync.exe for Windows 8+. Why them? Just the first things from huge list of possible targets. Plus they are really small and cute.
Target application location.
Windows directory for taskhost and system32 directory for tzsync.exe
Before we go to Target application name
lets post more funny things about UAC.
Lets take a look on Microsoft developed "crutch" hidden inside UAC dll. Yeah I mean that wonderful whitelist called g_lpAutoApproveEXEList
(yeah I known g_ stands for global, but it looks like really "govno" instead).
It is array of strings representing filenames of Microsoft executables which is used inside AiIsEXESafeToAutoApprove
Here is it from Windows 7
Code: Select all
Who are these executables at all? Mostly Microsoft backdoors is the right answer. Notice infdefaultinstall.exe used by malware, thanks to CVE-2014-4114 it was later removed from this list. Here is the list from Windows 10 RS1 build 14352 (its the same as on patched Windows 8.1 and on Windows 10 TH1/TH2).
Code: Select all
The intrigue part - most of these executables does not exist
in default Windows install (inetmgr.exe is a different story of successful UAC bypass). And they are "EXESafeToAutoApprove". Microsoft security as is. Lets pickup some names from this wonderful backdoor whitelist.
Target application name.
taskhost.exe for Windows 7 and migwiz.exe for everything else.
Final bypass scheme:
1) copy target application to %temp% under final name (taskhost.exe->%temp%\taskhost.exe, tzsync.exe->%temp%\migwiz.exe);
2) copy proxy dll with payload to systemroot\system32\sysprep as cryptbase.dll (add exports if needed);
3) copy target application from %temp% to target directory (windows for win7 and windows\system32 for everything else);
4) copy custom manifest as %targetapplication%.exe.manifest to target directory (windows for win7 and windows\system32 for everything else);
5) run target application.
It is just a simple demostration how badly this trash known as "UAC" was designed and how many possible ways to it bypass exist. To protect from the above - do not use admin account, force UAC at maximum level and filter every
window it will show with great caution because malware will use Microsoft binaries and this stupid/non informative UAC dialog will tell you these actions are legit and from Microsoft.
We are talking about x64 version of Windows, 32 bit variant is not interesting at all.
Method implemented as #18 in UACMe, https://github.com/hfiref0x/UACME