Windows: Elevation of Privilege in ahcache.sys/NtApphelpCacheControl

[GoogleCodeExporter]

Platform: Windows 8.1 Update 32/64 bit (No other OS tested)

On Windows 8.1 update the system call NtApphelpCacheControl (the code is 
actually in ahcache.sys) allows application compatibility data to be cached for 
quick reuse when new processes are created. A normal user can query the cache 
but cannot add new cached entries as the operation is restricted to 
administrators. This is checked in the function AhcVerifyAdminContext.

This function has a vulnerability where it doesn't correctly check the 
impersonation token of the caller to determine if the user is an administrator. 
It reads the caller's impersonation token using PsReferenceImpersonationToken 
and then does a comparison between the user SID in the token to LocalSystem's 
SID. It doesn't check the impersonation level of the token so it's possible to 
get an identify token on your thread from a local system process and bypass 
this check. For this purpose the PoC abuses the BITS service and COM to get the 
impersonation token but there are probably other ways. 

It is just then a case of finding a way to exploit the vulnerability. In the 
PoC a cache entry is made for an UAC auto-elevate executable (say 
ComputerDefaults.exe) and sets up the cache to point to the app compat entry 
for regsvr32 which forces a RedirectExe shim to reload regsvr32.exe. However 
any executable could be used, the trick would be finding a suitable 
pre-existing app compat configuration to abuse. 

It's unclear if Windows 7 is vulnerable as the code path for update has a TCB 
privilege check on it (although it looks like depending on the flags this might 
be bypassable). No effort has been made to verify it on Windows 7. NOTE: This 
is not a bug in UAC, it is just using UAC auto elevation for demonstration 
purposes. 

The PoC has been tested on Windows 8.1 update, both 32 bit and 64 bit versions. 
I'd recommend running on 32 bit just to be sure. To verify perform the 
following steps:

1) Put the AppCompatCache.exe and Testdll.dll on disk
2) Ensure that UAC is enabled, the current user is a split-token admin and the 
UAC setting is the default (no prompt for specific executables). 
3) Execute AppCompatCache from the command prompt with the command line 
"AppCompatCache.exe c:\windows\system32\ComputerDefaults.exe testdll.dll". 
4) If successful then the calculator should appear running as an administrator. 
If it doesn't work first time (and you get the ComputerDefaults program) re-run 
the exploit from 3, there seems to be a caching/timing issue sometimes on first 
run. 

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.

Original issue reported on code.google.com by fors...@google.com on 30 Sep 2014 at 2:17

Attachments:

• poc.zip

[GoogleCodeExporter]

Also, the way you assume your few dozen reports are the ONLY thing that 
Microsoft needs to handle at any given moment. Well, guess what, they have 
millions of other things to do as well (just like YOU), so no, 90 days may not 
necessarily be enough just because you decide it is, according to YOUR 
standards, YOUR processes and YOUR schedules.

Original comment by gradin...@outlook.com on 14 Jan 2015 at 9:51

[GoogleCodeExporter]

Well,it's is paying for support that is promised by MS,  and I expect them to 
fulfill their duties. I am happy about every exploit that is discovered in any 
software so the manufacturer can fix it in order that nobody will be able to 
use the exploit in secret. 
And for a crucial system component like an OS  I expect the manufacturer - that 
is Microsoft in here - to react to those exploits as fast as possible.  I pay 
for the system,  entire production facilities depend upon this OS,   so 
yes,IMHO I am in the position to demand from Microsoft to fix exploits with 
highest priority.   

Original comment by michael....@googlemail.com on 14 Jan 2015 at 10:32

[GoogleCodeExporter]

I believe what Google doing is right in long term:

1. 90 days is enough time to make a patch: MS argues Google should wait until 
MS release patch. What if it's not ready on the day? Google should wait another 
month? It's MS's responsibility to patch ASAP; They are not supposed to ask 
Google to hold the information disclosure. I would say Google can wait if it 
would not happen again, but this may bring up same situation again and again. 
At the end, customer would be the one who will take disadvantage using the 
vulnerable software.

2. I believe Google apply all rules to all company depends on vulnerability 
risk level. If it cause more issues to MS, that means MS has some issues on 
their end:
 a. MS might have more vulnerabilities on their software 
  OR 
 b. they don't have good enough system to fix vulnerabilities in time. If MS don't have good enough system to handle this situation, is MS good enough company to lead the computer industry? MS complains Google was pushing the risk to customer. But on the other hand, MS is taking customers as hostage to claim 'easy deadline' for MS. Is it really right thing?

Original comment by armiantc@gmail.com on 15 Jan 2015 at 4:33

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

And its gone. Tried it today Windows 8.1U1 no dice.

Original comment by pslov...@gmail.com on 24 Jan 2015 at 2:01

[GoogleCodeExporter]

Really awesome!

Original comment by hanyaan...@gmail.com on 25 Jan 2015 at 2:52

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Adding PoC for getting local system on 32 bit Windows 8.1 update.

Original comment by fors...@google.com on 9 Feb 2015 at 6:58

Attachments:

• PoC_AppCompatCache_LocalSystem.zip

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hello ,
 Two weeks ago I was able to locate some binary/executable in protected
 directory on windows 8.1 machine,i used a technique to span cmd shell
 instead of that binary, since the binary runs with NT Authority
 /Network service privilege and in service session I was unable to
 interact with it ,I changed my hack and used netcat in my plan and I
 was able to interact with the cmd shell in user session, now I get
 privilege escalation from user/guest does it count ?

Original comment by Mudasir...@gmail.com on 8 Mar 2015 at 5:44

[GoogleCodeExporter]

This is really fantastic it will create security awareness and Let us know what 
we have to do in order to mitigate these RCE besides it will give a massive 
boost to windows security researchers, Awesome ....Thanks

Original comment by Mudasir...@gmail.com on 8 Mar 2015 at 5:56