You could/can bypass Device Guard user mode code integrity with a custom CHM and execute code.
The last 6 months I have done some security research on my (little) spare time, because I find that very interesting. During this time, I was lucky enough to find another valid Device Guard UMCI bypass (I found the bginfo.exe as well: https://msitpros.com/?p=3831) and reported this to the Microsoft Security Response Center (email@example.com).
After a dialog with MSRC they told me that this was already discovered by another security researcher and that this would become a CVE with my name on it as well. (This was big news to me )
MSRC could not tell who the other researcher was, but Matt Graeber knew (Love that guy) . The other researcher was Matt Nelson and he had found this bypass a while back. Awesome!
Anyways this blogpost looks into how I made the discovery and some PoC code as well.
I am not a hardcore reverse engineer (yet ), so I will not do a full disassembly tour of the fix Microsoft has done, but rather focusing on how I found this.
For me this discovery started as I was looking through binary files in the windows and the system32 folder. I do this from time to time to discover new stuff.
I stumbled upon a binary file called hh.exe.
I went on and ran “hh.exe /?”. Assuming I either would get some help on the command or an error. Well, that is not what happened.
I got this instead:
This triggered my curiosity to the max. This trick btw still works on the latest Windows 10 and I guess if you ever need to have an explorer in a locked down environment (Terminal server etc) this could do it. You could also run for instance “hh.exe c:”.
After trying a lot of different stuff, I realized you could also browse the internet through hh.exe. Just by typing “hh.exe http://www.google.com” proves this. (Still works in the latest Windows 10)
It looks like this:
The first thing that struck my mind was to check the integrity level of the hh.exe process and guess what….
Yeah, my “browser” inside hh.exe is running in medium integrity mode and a normal iexplore process runs in Low. This should make it easier to exploit the browser inside hh.exe. (There is more research to be done here)
After trying a lot of different approaches, I thought I would try to create a custom help file with code inside, since HH.exe is primarily used for displaying help files.
I searched the web for any valid sources of these kinds of projects and stumbled upon this:
(thanks to Nikhil “SamratAshok” Mittal)
To run this script, I had to download and install the “HTML Help Workshop and Documentation” first:
I ended up creating my own version of Nikhil’s script, since I only wanted to prove my PoC and pop a Calculator.
My PoC script can be found here:
This script generates a simple .CHM that starts Calc.exe through ActiveX. There are certainly far more interesting things you can do.
For instance, running Cn33liz StarFighters to get an Empire agent going: https://github.com/Cn33liz/StarFighters/
The interesting part of my PoC script are these lines:
This gif shows you the Device Guard bypass in action:
This issue is fixed in the Windows 10 Creators update v1703 (aka Redstone 2) or if you want to patch it on older versions of Windows 10 you can find the correct patch here: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-8625
After I updated my machine to v1703 of Windows 10 I got this error when I tried to run the custom CHM file:
For you defenders out there, I would also monitor hh.exe and look at what the process is doing on your machines. Could be evil stuff going on.
That’s it. Hope this was interesting to read and that it inspired you to conduct your own security research to make Windows even more secure. If you are interested in learning more about Device Guard I suggest reading Microsoft official documentation and some blogposts by Matt Graeber (they have helped me):
Remember to send your discoveries to firstname.lastname@example.org and do not use your discoveries for evil. #WhiteHat4Life
5 thoughts on “Bypassing Device guard UMCI using CHM – CVE-2017-8625”