UACMe - Defeating Windows User Account Control

Forum for announcements and questions about tools and software.
User avatar
EP_X0FF
Global Moderator
Posts: 4812
Joined: Sun Mar 07, 2010 5:35 am
Location: Russian Federation
Contact:

Re: UACMe - Defeating Windows User Account Control

Post by EP_X0FF » Fri Jun 17, 2016 5:56 am

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.
Ring0 - the source of inspiration

User avatar
EP_X0FF
Global Moderator
Posts: 4812
Joined: Sun Mar 07, 2010 5:35 am
Location: Russian Federation
Contact:

Re: UACMe - Defeating Windows User Account Control

Post by EP_X0FF » Sun Jun 19, 2016 9:05 am

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.
Ring0 - the source of inspiration

User avatar
EP_X0FF
Global Moderator
Posts: 4812
Joined: Sun Mar 07, 2010 5:35 am
Location: Russian Federation
Contact:

Re: UACMe - Defeating Windows User Account Control

Post by EP_X0FF » Wed Jun 22, 2016 8:16 pm

Windows 14371 unexpectedly bring another fixes to UAC.

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

Image

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.
Ring0 - the source of inspiration

rinn
Posts: 91
Joined: Thu Nov 15, 2012 6:14 am
Location: Japan

Re: UACMe - Defeating Windows User Account Control

Post by rinn » Thu Jun 23, 2016 4:11 am

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

User avatar
EP_X0FF
Global Moderator
Posts: 4812
Joined: Sun Mar 07, 2010 5:35 am
Location: Russian Federation
Contact:

Re: UACMe - Defeating Windows User Account Control

Post by EP_X0FF » Thu Jun 23, 2016 1:04 pm

rinn wrote: 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 :)
Ring0 - the source of inspiration

User avatar
EP_X0FF
Global Moderator
Posts: 4812
Joined: Sun Mar 07, 2010 5:35 am
Location: Russian Federation
Contact:

Re: UACMe - Defeating Windows User Account Control

Post by EP_X0FF » Fri Jun 24, 2016 5:32 am

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.
Image

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.
Ring0 - the source of inspiration

User avatar
EP_X0FF
Global Moderator
Posts: 4812
Joined: Sun Mar 07, 2010 5:35 am
Location: Russian Federation
Contact:

Re: UACMe - Defeating Windows User Account Control

Post by EP_X0FF » Wed Jun 29, 2016 6:08 am

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?
Ring0 - the source of inspiration

User avatar
EP_X0FF
Global Moderator
Posts: 4812
Joined: Sun Mar 07, 2010 5:35 am
Location: Russian Federation
Contact:

Re: UACMe - Defeating Windows User Account Control

Post by EP_X0FF » Sun Jul 03, 2016 6:16 pm

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.
Ring0 - the source of inspiration

User avatar
EP_X0FF
Global Moderator
Posts: 4812
Joined: Sun Mar 07, 2010 5:35 am
Location: Russian Federation
Contact:

Re: UACMe - Defeating Windows User Account Control

Post by EP_X0FF » Tue Jul 05, 2016 8:40 am

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?
Ring0 - the source of inspiration

User avatar
EP_X0FF
Global Moderator
Posts: 4812
Joined: Sun Mar 07, 2010 5:35 am
Location: Russian Federation
Contact:

Re: UACMe - Defeating Windows User Account Control

Post by EP_X0FF » Wed Jul 06, 2016 5:28 pm

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".
Ring0 - the source of inspiration

Post Reply