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]

To the people who are missing the point of what the vulnerability is, read the 
description more carefully: "NOTE: This is not a bug in UAC, it is just using 
UAC auto elevation for demonstration purposes."

It's a local privilege escalation bug and it does not depend on the user 
already having admin rights, even though the proof-of-concept may have 
limitations in that respect.

The 90-day automatic disclosure is entirely reasonable. It absolutely should be 
automatic, in order to give engineers for the vulnerable product a predictable 
deadline and to eliminate politics.

BTW, Windows is chock-full of local privilege escalation bugs. It always has 
been and always will be; the architecture makes them inevitable.

Original comment by davidsar...@googlemail.com on 2 Jan 2015 at 9:23

[GoogleCodeExporter]

These comments are generally terrible.

Original comment by jason.st...@gmail.com on 2 Jan 2015 at 11:22

[GoogleCodeExporter]

90 days is more than enough time for a company, especially one the size of 
Microsoft, to issue a patch to fix this. Yes, this makes current operating 
systems vulnerable, however it also makes Microsoft take ownership. I bet next 
time there is an issue like this Microsoft will think twice before letting the 
90-day window expire.

Original comment by mjhouse...@gmail.com on 2 Jan 2015 at 11:42

[GoogleCodeExporter]

Let's say that Google didn't release the bug until MSFT patched it (and, 
according to the logic of many people here, the patch is deployed to all 
machines).

In that time millions (or billions (?)) of computers are taken over by a hacker 
or a botnet or the NSA. Huge scandal, lots of news stories, etc. At some point 
a GOOG security researcher mentions, "oh? that? yeah... we knew about that for 
a year but we didn't feel comfortable releasing it."

That scenario seems infinitely worse and more irresponsible.

Original comment by jamesc...@gmail.com on 3 Jan 2015 at 12:44

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I was testing this vulnerability and while I was not able to replicate either 
chaos, mayhem, riots or discord, it does appear that my dog and cat are now 
living together for what it's worth.

Honestly now public vulnerability disclosure is not a new thing and it was done 
appropriately in this case people don't make me put my hands on my hips or sigh 
derisively.

Original comment by bra...@gmail.com on 3 Jan 2015 at 1:03

[GoogleCodeExporter]

Fixed on Windows 10.

Original comment by office.m...@googlemail.com on 3 Jan 2015 at 1:31

[GoogleCodeExporter]

Also fixed on Windows 11!
How does that help anyone?

Original comment by davian...@gmail.com on 3 Jan 2015 at 2:19

[GoogleCodeExporter]

Are the people who are confidently saying this has been fixed in Windows 10, 
basing that on any more evidence than that the PoC doesn't work for them? 
Because the PoC is somewhat fragile and there are many reasons why it might not 
work on a particular system, regardless of whether the underlying vuln is fixed.

I assume Google is in communication with Microsoft and will close this bug if 
and when it is actually patched.

Original comment by davidsar...@googlemail.com on 3 Jan 2015 at 2:59

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

this bug is more like meh! this is not even a great or critical bug. its a 
normal classic bug anyone could've find. you can't blame Google or Microsoft. 
As I am sure, there are more critical bugs Microsoft is trying to fix that are 
silent. I am sure Microsoft didn't lie on a bed for 90 days. that obviously 
tell us they are addressing more critical issues than this one. the fact this 
gained media attention might seem like this is a very bad issue but given the 
prerequisites this needs to succeed, this is no more than a very low issue. and 
Kudos for Google for sticking for their policy.

Thanks!

Original comment by habte.yi...@gmail.com on 3 Jan 2015 at 6:17

[GoogleCodeExporter]

I have found that the included Binary does the exploit reliably on Windows 8.1 
x64. However - if I recompile it I no longer get the desired effect. This just 
makes the PoC unreliable.

It doesn't surprise me that newer versions that aren't released won't work - 
the way this runs (from reading  the code) means that any changes in certain 
Windows Internals render it mute - but that doesn't mean it can't be quickly 
changed.

Privilege escalation bugs are serious things. Let's hope they sort it out.

Original comment by lpack...@gmail.com on 3 Jan 2015 at 7:22

[GoogleCodeExporter]

What is the motive to publicise any vulnerability in public and even with all 
the steps to break in? MSFT must have few patches to consolidate and then 
planning to release in one go, considering the size and versions (32 and 64 bit 
both). Since we clearly do not know what communication that happened with 
Google and MSFT on this, but if "grace period" was sought and given, then it 
should not go "automatically" visible after 90 days got over. Lets just hope 
for the best with Windows 10

Original comment by chandraj...@indianic.com on 3 Jan 2015 at 7:35

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I study this a little more and yes, this is not only UAC bypass.

However, I'm quite sceptical there is any other use for this vulnerability than 
UAC bypass. (With this cache poisoning, you can’t just do direct shim)

Also, I'm not saying UAC bypass is not serious.

Original comment by mei...@gmail.com on 3 Jan 2015 at 10:27

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Modifying one word in the source file of the DLL made me open command line in 
elevated privileges. Nothing more to say!

Original comment by amkora...@gmail.com on 3 Jan 2015 at 2:57

[GoogleCodeExporter]

"Don't be evil"

Original comment by ipella...@gmail.com on 3 Jan 2015 at 3:33

[GoogleCodeExporter]

I fully agree with google's disclosure policy, 90 days is enough to address the 
issue actually the time ought to be smaller than that. 

Original comment by emem...@gmail.com on 3 Jan 2015 at 3:58

[GoogleCodeExporter]

Hm it appears not to be working on windows 10 x64 (tech preview) in vmware and 
windows 7 x64.
both give me "Error adding cache entry: C000000D"

Original comment by ehhth...@gmail.com on 3 Jan 2015 at 5:04

[GoogleCodeExporter]

Virus Scan (virus total)
https://www.virustotal.com/en/file/4c3a29a77d663d99039eac3046a3e11e0e73a6043e269
517d91cf6b3a2a06998/analysis/1420305224/

Original comment by ehhth...@gmail.com on 3 Jan 2015 at 5:15

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi All,
   I wanted to test this one out. In order to do so I recompiled the TestDll.dll to execute cmd.exe (calc gives no flexibility!) and then tried the following command: AppCompatCache.exe c:\windows\system32\ComputerDefaults.exe testdll.dll

Tried this on a standard command prompt and it doesn't appear to give a system 
shell.  My version of Windows is: Windows 8.1 (Version 6.3.9600).

I've verified that items 1-3 above have been satisfied but no success.  Has 
anyone else been able to verify this exploit?

Also, as an aside, requirement number three above (by OP) indicates the user 
has to have "split token" admin privileges. Having access to a user with this 
level of privileges is essentially game over from a hacker's point of view.  
What I am wondering is how is this exploit any better than performing (as a 
split-token admin):

1. Find cmd.exe
2. Right-click and select run as admin
3. From the administrative prompt run psexec like this (psexec -i -d -s 
cmd.exe) 
4. Execute 'whoami' from the new cmd prompt. 

The above will provide a system shell to *any* split-token admin.

So am I missing anything?  Or is this a real non event? Why would you bother 
having to trigger an exploit when you have all the access required anyway?  It 
might explain why MS haven't done anything as from what I can tell this exploit 
doesn't give you anything you don't already have as a split-token admin.

If I am incorrect please help steer me back on the right path, I'm always 
trying to learn more in this area.

Thanks,
Patrick

Original comment by misterfi...@gmail.com on 3 Jan 2015 at 8:36

[GoogleCodeExporter]

@ #73, I tried the cmd thing myself and it worked.. Windows 8.1 x64, You might 
want to try multiple times though. Your points regarding being a split-token 
admin are valid though, I hardly think a standard user on a domain would be 
able to use it for instance.

Original comment by amkora...@gmail.com on 3 Jan 2015 at 11:11

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

its best google published it ... than in the hands of underground russian 
hackers thats if they aint using it yet... because i find it amazing microsoft 
dont do alot in making sure there os is not exploitable ... every now and then 
cases on exploits from microsoft products... thanks Google..

Original comment by ebebeja...@gmail.com on 4 Jan 2015 at 7:14

[GoogleCodeExporter]

You Google suck-ups keep saying 90 days is enough time, but why is 90 days the 
APPROPRIATE amount of time? Why not 100 days? Why not 120 days? Who cares? The 
fact that Google mindlessly disclosed it like an automaton without using any 
discretion and consideration of the realities of life is what is disturbing. 
The fact that you Google fanbois commend this behavior is even more so.

Original comment by freddyt5...@gmail.com on 4 Jan 2015 at 5:55

[GoogleCodeExporter]

doesn't seem to work on windows 10 technical previews.Error adding cache entry,

Original comment by frazzled...@gmail.com on 4 Jan 2015 at 6:41

[GoogleCodeExporter]

I agree with freddy (#77). Google want to troll Microsoft than want to help

Original comment by AnimeCra...@gmail.com on 4 Jan 2015 at 8:37

[GoogleCodeExporter]

Anybody read #51? It says, the POC is not the real thing, it has limitations.
If it were the real thing, this would be only a UAC bypass. Lately I learned in 
an MS forum how UAC bypasses are treated: they are not even called security 
vulnerabilities by Microsoft... Read for yourself: 
http://technet.microsoft.com/library/cc751383.aspx says "A weakness that would 
allow to bypass the “Consent Prompt” is not considered a security 
vulnerability, since that is not considered a security boundary". Now as funny 
as this may sound, this together with the fact that MS is concerned about this, 
should mean it is not "only" a UAC bypass... or MS has changed its mind :)

No, I have not tried the POC myself as comments suggest it's not the real thing.

Original comment by Bernd.Sc...@googlemail.com on 4 Jan 2015 at 11:09

[GoogleCodeExporter]

This looks like a simple privilege escalation weakness and not a vulnerability. 
If you report something like this to Microsoft you will get an email thanking 
you for reporting the "bug", they will also tell you that the issue will be 
fixed in the future and that Microsoft does not think this weakness should be 
fixed through the release of a separate patch. 

Original comment by rouzbeh....@gmail.com on 5 Jan 2015 at 6:14

[GoogleCodeExporter]

Microsoft does not consider "UAC Bypass" as a security vulnerability.
so its totally fine to disclose this.

Original comment by dilorenz...@gmail.com on 5 Jan 2015 at 1:43

[GoogleCodeExporter]

This is in follow up to my questions posted in @73.  Post @51 points out that 
UAC was simply used to demonstrate the issue but there are other ways a user 
without split admin rights can trigger the vulnerability. @80 says the same 
thing.

From what I can tell this POC uses an auto-elevate function to create a cache 
entry which the exploit can leverage to gain higher privileges.  In the real 
world there may be existing cache entries, from previous admin access, to use 
or there may be other vectors to trigger this issue.

The OP says "the trick would be finding a suitable pre-existing app compat 
configuration to abuse."  So I guess this is the pre-condition a limited user 
would need in place for successful exploitation. This POC contrives this 
situation with the requirement to run ComputerDefaults.exe as a split-admin to 
populate the cache and then attempt to trigger the exploit.

Original comment by misterfi...@gmail.com on 5 Jan 2015 at 1:52

[GoogleCodeExporter]

Heartbleed was fixed in 1 day as long as I can remember. If you have big 
security hole and nearly unlimited resources as Microsoft, then they can fix it 
in few hours. 90 days is way too long. 3-5 days is normal for fix. The rest 85 
days are for users to update.

Original comment by xpuc...@pleven-dage.net on 5 Jan 2015 at 2:27

[GoogleCodeExporter]

Note that Microsoft has often advertised UAC (or at least, vaguely specified 
"new security features" that could only in context have meant UAC) as having 
security benefits to end-users. To security researchers, in contrast, they 
consistently claim that any attack on it is not a security vulnerability in 
order to avoid having to fix its --deep, structural, and probably unfixable at 
this point-- design flaws.

Although it probably wasn't the original plan (see below), this has had the 
effect of allowing them to benefit from marketing it as a security feature 
without the engineering effort of actually having to make it secure. 
(Considerable effort was still needed to stop UAC from breaking too many 
existing apps, which required a bunch of complex virtualization.) Yay!

In case it isn't obvious, a "security mechanism" that doesn't enforce any 
security boundaries is no security mechanism at all.

UAC absolutely *was intended* to enforce security boundaries when it was 
originally designed -- as was the closely related UIPI, which they've since 
taken a similar position on. You don't spend as much effort on implementation 
and maintenance or impose the kind of usability costs that UAC and UIPI impose 
(on both end-users and developers), without intending there to be a security 
benefit. Actually, they completely fluffed it and there is no real security 
benefit against competent attackers; the inconsistent stance described above is 
a consequence of trying to avoid losing face over that.

Sorry for the mildly off-topic rant. It is off-topic because *actually this bug 
is not just a UAC bypass*. But the margin of this message is not large enough 
for a proof of that.

Original comment by davidsar...@googlemail.com on 5 Jan 2015 at 2:49

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

@5

It is infinitely more irresponsible not to disclose this bug. I won't comment 
on usage, however more likely then not, if Google has found it, so has someone 
else, and how much are you willing to bet that this theoretical individual is 
of the same moral fiber as the researcher who posted this bug? I will not bet 
any of my systems on them being benign, I will assume they are malicious. Now 
that the vulnerability is disclosed *I* can do something to attempt to block 
it, or something similar, from happening on my boxes. 

Original comment by phil.pgt...@gmail.com on 5 Jan 2015 at 5:30

[GoogleCodeExporter]

I think that the probleam was that google publish the vulnerability, if was an 
independent researcher, maybe would not be attacked in this form.

Original comment by marcos.a...@cloudcom.mx on 5 Jan 2015 at 6:35

[GoogleCodeExporter]

I think that Google deserves a kudos for releasing this vulnerability. Blissful 
ignorance is not a security strategy. If a researcher at Google was able to 
find this and report it to Microsoft then that is a win. A less ethical person 
may be able to find the same issue and exploit it rather than report it. The 90 
day window in my opinion is too large. The fix should be made available much 
sooner. Millions of computers are left exposed for 90 days. 

Public interest is best served by addressing issues transparently. The 
infrastructure that we call the internet should have safety standards that are 
reviewed and brought to accountability. Lulling users into a false sense of 
security is not the best way. Vulnerabilities are a bigger problem when they 
are out in the wild before they vendor is aware. 

Thanks Google. 

Original comment by ekaith...@gmail.com on 5 Jan 2015 at 6:44

[GoogleCodeExporter]

Google was wrong with what they did. They don't have all of the OS code so they 
have no idea how much other code would have to be rewritten to correct the 
problem. That extra coding takes time to ensure that something else doesn't get 
broken in the process.

As a semi-reformed black hat, I find it interesting how those that think Google 
is correct with what they did don't realize that Google is also one of the 
biggest sellers of personal information which is gleaned from the data they 
collect whenever any of their products are used. This includes those background 
programs that most end users are unaware of such as the analytics that are a 
well hidden data collector on a majority of web sites these days. If you think 
Google is right for disclosing the information then you most likely also 
condone their selling of your information to whoever wants to pay for it. The 
bottom line is that Google is the biggest single security risk on the internet 
to anyone that goes online. I have all the proof I need that they do sell your 
information as they are the ONLY site I ever gave a certain email address to 
and within a matter of two weeks there were over 500 spam emails sent to the 
account. I know for a fact that Google was the ONLY company the email address 
had ever been given to or used with because it was a test to prove what they 
are really doing with personal data. Based on the content of the spam that was 
received, they sold my information to everything from cosmetics companies to  
pharmaceutical companies to porn sites. All of this from the day I signed up 
for gmail and had to give an alternative email address. Funny how none of the 
spam ever ended up in the gmail account.

As for comment #89 - "The infrastructure that we call the internet should have 
safety standards that are reviewed and brought to accountability." How in the 
hell do you think that something as open as the internet could have any type of 
safety standards or accountability? You do realize that can only be 
accomplished by some country actually controlling the internet with censorship, 
etc.

Original comment by aramisth...@gmail.com on 5 Jan 2015 at 7:11

[GoogleCodeExporter]

This is *not* a difficult bug to fix. Look at the description; it says:

"[NtApphelpCacheControl] 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 [...]"

The needed fix is just in that specific code. Nothing else needs to be 
rewritten. 90 days is perfectly sufficient; for this particular bug, 9 days 
should have been sufficient. Microsoft just dropped the ball.

More generally: the most important thing about a disclosure policy is to *STICK 
TO IT*. The policy was clear in advance and has been correctly followed. It is 
a really bad idea to make ad-hoc exceptions for particular vulnerabilities.

(That's not to say there shouldn't be a procedure for requesting an extension. 
Maybe there is, and Microsoft just didn't follow it. Remember that there will 
have been communication between Google and Microsoft that isn't visible on this 
bug ticket.)

Original comment by davidsar...@googlemail.com on 5 Jan 2015 at 7:27

[GoogleCodeExporter]

We already disliked Google for "Being Evil" now this make us dislike Google 
even more.

Original comment by StokedOn...@gmail.com on 5 Jan 2015 at 9:44

[GoogleCodeExporter]

Wow... so many retards. Bug was reported to Microsoft 90 days prior to the 
publication of this bug. Microsoft were aware that this would be happening. If 
you think this is a bad move on Google's behalf, you are an idiot.

Original comment by simplex...@gmail.com on 5 Jan 2015 at 10:55

[GoogleCodeExporter]

I think public this bug or any other bug after 90 days is a good solution, it 
ask all software company to fix it asap instead of hide it from the end-users.

Such as: The same bug also be found on Windows NT 4 (used to use by many 
company long time ago) which allow every guest user can get the administrator 
privilege. It is more dangerous than windows 8 because this OS was use by many 
IT company, school, ...

But Microsoft never fix it until now, they leave all bushiness company leaving 
with a serious problem without any note.

Original comment by hacrot3000 on 6 Jan 2015 at 3:51

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Google is not evil. Microsoft just slept and did not fix the vulnerability in 
time. Good job google

Original comment by SilverSt...@gmail.com on 6 Jan 2015 at 6:20

[GoogleCodeExporter]

#94 The bug that you mean, is to use the "escape" button at login session ? 
It's very different that we have here. 
For example it work too (in different way) in Windows 7/8 : 
http://www.technibble.com/bypass-windows-logons-utilman/

What we have in this topic is to get elevated privilege in a already logged 
session which is not administrator. (Ex of use : Installation of malware with 
admin right silently)

It's a "little bit" different. :)

Original comment by reclad on 6 Jan 2015 at 10:24

[GoogleCodeExporter]

#97: No, the bug on Windows NT 4 is allow any logged in user (even guest) can 
get the administrator privilege to install, remove, create new admin account or 
even delete the current admin account.

I don't know how to do it but we able to download the tools from the Internet 
with only few click (year 2002-2004, I don't know we can now find that tools or 
not ^_^)

That bug did same thing with this bug.

All most windows NT 4 versions (Windows NT 4.0 Workstation, Windows NT 4.0 
Server) got that problem. I never check on Windows NT 4.0 Terminal Server 
Edition so I don't know how about it.

Original comment by hacrot3000 on 6 Jan 2015 at 1:22

[GoogleCodeExporter]

Did someone test it on domain computer?

Original comment by mpange...@gmail.com on 6 Jan 2015 at 7:13

[GoogleCodeExporter]

@99 Yes, it work too.

Original comment by reclad on 6 Jan 2015 at 7:19