Google’s Project Zero – A research project which was announced by Google to detect vulnerabilities in different types of OS. The task of the project members is to report bug or vulnerabilities which the respective vendor should fix within a specific deadline, not doing so will result in publishing the vulnerability in public. The level of the vulnerability has been mentioned by Google project members as “Highly Severe“. This a terrible thing for Windows 8.1 users in the year 2015.
You May Also Like – 5 Reasons Why CyanogenMod Is Better Than Stock ROM
The Vulnerability
The vulnerability describes itself as a major detecting problem of impersonation. If someone tries to exploit this vulnerability he/she might get the access to rights which is very sensitive to the original administrator by some fake request. Microsoft that the one who tries to exploit it with the code published by Google will need to provide the credentials for the complete login process, yet this can’t be said as completely harmless.
This vulnerability was tested successfully on Windows 8.1 32/64- bit systems. It is also expected to affect Windows 7 users, although it has not been tested on it.
Here is what the Google project member reported :
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.
You May Also Like – Every Website To Get Free SSL From This Summer
Public Reactions
Some private developers and other Windows 8.1 users are unhappy with Google to disclose the vulnerability. But from the experts point of view, it is a necessary task to disclose the vulnerability to the public when no patch is applied to it within the deadline which enforces more pressure to the Microsoft Security Team to fix it soon. The year 2015 doesn’t seem a good “secure” start for Microsoft. Windows 8.1 users are eagerly waiting for a security patch to come soon.
There are also some “crazy-fan” users who think that Google did this purposefully and on the other side some say that Google did a good thing by disclosing the vulnerability.
Well, Microsoft known for it’s security expertise has not been able to fix this vulnerability within the deadline specified by Google. The project members reported this problem on September 30, 2014. So, it was published live on 29 December, 2014 to the public for exploitation till Microsoft applies a patch for it.
Let us know what you think about it.