[EP_X0FF]

Builds 14361, 14366, 14367 - zero uac related changes. I assume nothing will be fixed in near months because of 10 RS1 release.
UACME v 2.3 will be released soon with method 19 that works from Windows 7 up to 14367 Windows 10 RS1 build.

[EP_X0FF]

Windows 10 RS1 14316 UAC bypass is still possible and working even without involving InetMgr (which is also can be used to bypass UAC in 14316 so count methods as two).

InetMgr bypass is back and fully working in UACMe v 2.3 from Windows 7 up to Windows 10 RS1 14367 build. Until this -> http://www.kernelmode.info/forum/viewto ... 995#p25995 <- won't be implemented there is a place for "releases" for years or until I get bored too much.

[EP_X0FF]

Windows 14371 unexpectedly bring another fixes to UAC.

sysprep manifest extended to include unbcl.dll - this fixes uacme 17 method, see below



appinfo.dll now has new function AipIsValidAutoApprovalEXE. This routine called inside infamous AiIsEXESafeToAutoApprove which is handling g_lpAutoApproveEXEList list. New routine now perform signature validation via wintrust!WTGetSignatureInfo for file before it auto-elevation. This mean now you cannot use your executables named as files in g_lpAutoApproveEXEList and autoeleavate them bypassing UAC. This actually fixes bunch of methods, and uacme 18 as side effect.

As I already said on twiiter, despite all my criticism of UAC I must admit that Microsoft did really good job fixing UAC for Windows 10. And I hope they will continue.

[rinn]

Hi.
I would also suggest:

a) deny write access to %systemroot%\system32\inetsrv folder for anyone except TrustedInstaller or harden InetMgr.exe to load all of it dependencies from system32. This will disable UACMe #19 method and disallow InetMgr.exe dll hijacking.

b) detect multiple elevation attempts from the same thread/process and give user ability to cancel them all (for example by letting user terminate process-requestor). This will solve script kiddies style UAC bypass when they throw elevation UAC messages in loop until user not press OK.

Best Regards,
-rinn

[EP_X0FF]

b) detect multiple elevation attempts from the same thread/process and give user ability to cancel them all (for example by letting user terminate process-requestor). This will solve script kiddies style UAC bypass when they throw elevation UAC messages in loop until user not press OK.

I'm afraid this won't solve problem. Malware simple will spam with processes requesting elevation :)

[EP_X0FF]

Microsoft failed to fix InetMgr.exe autoelevation exploit. Looking on the fix they implemented it seems they do not understand the root of the problem.

InetMgr.exe from 14372 build.


Location: InetMgr.exe from system32\inetsrv folder.
General explanation: http://www.kernelmode.info/forum/viewto ... 167#p27167

Core problem:
The folder system32\inetsrv\ is EMPTY by default. But InetMgr whitelisted and it full path hardcoded inside APPINFO in g_lpExemptedAutoApproveExes array

Code: Select all

"System32\\Sysprep\\sysprep.exe"
"System32\\inetsrv\\InetMgr.exe"

and used in AipInitializeSecureWindowsDirectories.

InetMgr is part of IIS (nobody from target audience is using). This file and rest of IIS installed only by user request as additional Windows component. So most of the time this folder is EMPTY.

As you see above on screenshot, MS hardcoded loading of one dll, so InetMgr will always load it from the given path. From EMPTY directory. Why?

InetMgr.exe component is compressed in DCS (Win10, DCN for win8/8.1) container format (see https://github.com/hfiref0x/SXSEXP winsxs files expander) and stored in WinSxS folder. Nothing is preventing attacker from extracting it from there (or using copy) and moving it to the inetsrv directory (which will be empty by default). Next attacker will place there malicious dlls and do usual dll hijacking, and even use dll from that "fix". This is exactly what method 19 of uacme is doing.

There should be no simple way to write to this folder or InetMgr should not be auto-elevated.

Update:
as rinn suggested this fix is cumulative with sysprep fix of uacme #17, when MS expected similar technique to be used with InetMgr as target.

[EP_X0FF]

Some tweaking in 14376 build seems fixed dll search order for InetMgr.exe when it was possible to load your own mscoree.dll from inetsrv directory. Now InetMgr.exe executed via ShellExecute(Ex) API lookups dlls in the system32 folder. So to make it load malicious dll it is now required launch it from already admin process, which makes it nonsense. Nice work. Why this wasn't here since beginning?

[EP_X0FF]

Another UAC bypass method (or it is some kind of renew of previously added) pending to be integrated to UACMe (well actually nothing new here since beginning), it works well from Windows 7 up Windows 10 RS1 14379 build and based on multiple dll hijacking "vulnerabilities" or hmm, well it's a feature. Release date - TBA.

[EP_X0FF]

UACMe v2.4 released with method 20, working from Windows 7 up to Windows 10 RS1 14379 build. It uses another Microsoft Management Console dll loading vulnerability in snap-in control file rsop.msc.

There are exist another easy to exploit set(!) of vulnerabilities related to MMC. However I will wait until this method 20 will be fixed (if they ever fix it) before releasing anything else. Also after that version I will probably take a rest from UACMe, because it starting to be really boring. Neverending fixes of the same "features", this is boring. And I think at the end I will probably give a small guide how to find UAC bypass methods just in a few minutes. I'm really surprised that for 1.5 years of UACMe existence Microsoft didn't even tried their own tools, which by the way can successfully identify all this published crap. Their usage must be too complicated?

[EP_X0FF]

2.4 reuploaded with bugfix related to old sysprep methods (I fucked up with executable path construction).

Additionally new method discovered, it works as usual from Windows 7 up to 14379 and I'm very curios how Microsoft will fix it, even official/known docs are contradict each other.

So now we have completely vulnerable MMC console and this fun "feature".