Blog

Protected Mode: A Case of When No Means Yes

08/12/2015 | Author: Admin

Protected Mode: A Case of When No Means Yes

Browser exploitation is continually getting more challenging as defenders constantly introduce new protections, moving the goal posts further and further away. Memory corruption on the latest Internet Explorer is now not a task for the faint hearted with improvements like MemGC, Isolated Heap and Control Flow Guard. Life would be much simpler if we could just tell the browser what we wanted to run, and it would run it. There are a few things stopping us doing this, but for the purposes of this blog post the one we’re interested in is Protected Mode.

Protected Mode was a security feature introduced with IE7 and Windows Vista. If you’re not familiar with Protected Mode, it’s worth reading the “Understanding and Working in Protected Mode Internet Explorer” article on MSDN. Specifically, you may want to focus on “Starting Processes from Protected Mode” which states:

In general, extensions should operate as low integrity processes whenever possible. This provides the best protection against malicious attacks. However, there are times when an extension may need to access medium or even high integrity objects.

To do this, create a broker process to access higher integrity objects and then launch the broker process with a higher integrity level. By default, Internet Explorer will prompt the user to confirm the medium integrity elevated process, as shown in the following screen shot.

One such extension that requires elevation and runs outside of Protected Mode is HTML Applications (HTA), which when opened will display a warning that may scare off many users, assuming no elevation policy is in place, as shown at the top of this article.

To avoid code execution, the user simply has to click “Don’t allow” to dismiss the warning and stop the HTML application running, right? Unfortunately not! During a research project we discovered an elementary weakness in Protected Mode, which meant the HTML application would still be run, regardless of whether you selected “Don’t allow” or dismissed the warning using the “X”. Consequently, this means that if a user opens a HTA file, served up through a drive-by-download or other means, the only way to prevent arbitrary code execution is to forcibly kill the browser process!

Let’s have a look at what this looks like in action:

In the video above, we used a default Windows 7 x64 install running the latest version of IE11 and the calc.exe process is spawned in medium integrity. It is possible that other extensions (e.g. SCR, VBS?) may have a similar effect; this is left as an exercise for the reader.

We tested this behaviour in IE10 and had similar results; interestingly IE8 does not behave in this manner, while IE9 was not tested. Our HTA file looks as follows:

<script language=”VBScript”>
Function var_func()
Dim var_shell
Set var_shell = CreateObject(“Wscript.Shell”)
var_shell.run “calc.exe”
End Function
var_func
self.close
</script>

We reported this issue to Microsoft on Friday 4th of September and got the following response:

After our engineers took a look, we have determined this to not be a security vulnerability. If you have any additional information that may change this, we would love to take a look. We have passed this on to our developer team for a possible improvement/feature/behavior change.

This blog post was written by Dominic Chell.

 

Ready to start testing your applications?

Speak to one of our industry experts and find out how MDSec can help your business.

+44 (0) 1625 263 503

contact@mdsec.co.uk