Author

Google Security Research

Risk

[

Security Risk Medium

]

0day-ID

0day-ID-30610

Category

dos / poc

Date add

20-06-2018

CVE

CVE-2018-8214

Platform

windows

Windows: Windows: Desktop Bridge Virtual Registry CVE-2018-0880 Incomplete Fix EoP
Platform: Windows 1709 (not tested earlier version)
Class: Elevation of Privilege
 
Summary: The handling of the virtual registry for desktop bridge applications can allow an application to create arbitrary files as system resulting in EoP. This is because the fix for CVE-2018-0880 (MSRC case 42755) did not cover all similar cases which were reported at the same time in the issue.
 
Description:
 
Looking at the fix for CVE-2018-0880 the Cache directory and sub files are now secured so only admins and system can access them. This breaks my original PoC but it doesn’t fix the issue. In my original report I also noted that User.dat and UserClasses.dat could also be abused in the same way and those files exist in the Helium directory above the Cache. Therefore the exact same attack can be employed on the Helium directory instead of the Cache directory.
 
To be honest I’m not even convinced that locking down the security on the Cache directory is a robust fix. As we have FILE_DELETE_CHILD access on the Helium directory we could always rename the Cache folder and the activator will recreate it for us. With a bit of effort we could mount the original attack through things like holding a reference to one of the files with WRITE_DAC permissions and race the security descriptor checks in DAXEXEC!OfflineRegistry::EnsureCacheIsSafe. It’d be slightly more work but not unduly so. 
 
IMO the only real way to fix this issue would be completely remove the opportunity to replace the registry cache files from a normal user, perhaps by placing them in a secondary location on the system such as under a secured directory in c:\ProgramData. 
 
I also haven’t bothered to check if you’ve fixed the read issue that I also reported as part of case 42755. I’ve no reason to believe you have based on what I can see in the code.
 
Proof of Concept:
 
I’ve provided a PoC as a C# project. In order for the exploit to work you need a copy of the Get Office/My Office application installed (I tested with version 17.8830.7600.0). It could be any desktop bridge application however as you just need to run a program inside the container although for that to work some strings in the poc would need to be changed.
 
1) Compile the C# project. It will need to grab the NtApiDotNet from NuGet to work.
2) Start the poc. It should print that it successfully created the badgers.dll file in system32.
 
The exploit works as follows:
* The Helium folder is renamed to Helium-X.
* The Helium folder is recreated as a mount point which redirects to the object manager directory \RPC Control
* Symbolic links are dropped for the registry hive files. The LOG files are redirected to an arbitrary name in the windows folder.
 
Note that the PoC will leave the user profile for the Office Hub application broken, you should delete the fake Helium folder and rename the Helium-X folder to try the exploit again.
 
Expected Result:
The application creation fails or at least the symbolic links aren’t followed.
 
Observed Result:
The file badgers.dll is created in the system32 folder which is writable by a normal user.
 
 
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/bin-sploits/44915.zip

#  0day.today [2024-11-14]  #