Security Research

There’s No Place Like Localhost: A Welcoming Front Door To Medium Integrity

There’s No Place Like Localhost: A Welcoming Front Door To Medium Integrity


Matt Molinyawe

Security Researcher

HP Security Research – Zero Day Initiative


This year, Abdul Aziz Hariri, Jasiel Spelman, and myself (Matt Molinyawe) of the Zero Day Initiative were involved in producing an exploit for this year’s Pwn4Fun. It demonstrated our work and that people from major companies could produce a full exploit in the name of charity, good will, and trying to make positive change in software without asking for anything in return. The Zero Day Initiative had also disclosed 6 additional Microsoft Internet Explorer vulnerabilities found by Abdul Aziz Hariri over the two weeks prior to this event.



Our exploit and winning choice of cat picture allowed us to donate $50,000 to the Canadian Red Cross along with $1000 donated on our behalf to the ASPCA thanks to Dr. Jon Oberheide.


The exploit demonstrated remote code execution by modifying the Windows Registry to launch scientific calculator along with handling process continuation.  It included a sandbox bypass which Microsoft has now decided does not ‘meet the bar‘ for security fixes.  While this bypass may not qualify for a security fix, it lowers the bar to achieving privileged code execution for attackers and is quite unfortunate.


Discovery – Know your exploit history because sometimes history repeats itself


With all the vulnerabilities that have come through the ZDI over the years, I feel that the most interesting vulns are the simplest ones.  And this issue that we identified is dead simple. 


Reading sandbox bypass history and news led to the discovery of this simple flaw.  The Verizon Protected Mode bypass paper from 2010 was one of the candidates on the reading list as well as numerous news articles.  One news article contained a Microsoft issued statement regarding this paper:


“The issue discussed in the report is not a vulnerability. It is a method for bypassing a security mitigation. In order to use this method, an attacker would first need to be able to exploit an unpatched vulnerability on the target computer. Protected Mode was designed to help defend against “elevation of privilege” attacks and to help protect users from malicious downloads by restricting where files can be saved without the users consent. Protected Mode is not a security boundary – it does not provide direct protection, only a chance for a user to verify an action before it happens.”


This event occurred during the time that I did not have a vulnerability research job and it was during the lifetime of Internet Explorer 7.


After reading this quote, I couldn’t help but wonder why things in that statement appeared to be contrary to the facts presented by the paper.  So, I dug into the Verizon paper further.  The paper had noted that IELaunchURL could be called to launch a new tab to navigate to http://localhost/exploit.html or similar.  It also had noted that the page would be rendered in the Local Intranet Zone and the rendering process would now be executing at medium integrity.  To resolve this issue, IELaunchURL would have been a target for patching and perhaps the medium integrity process creation of localhost.  I figured that Microsoft surely would’ve fixed it properly after the rough press articles back in 2010 despite the defensive commentary. 


Even with some changes to the browser over the years, I was completely wrong.


After hand typing in http://localhost into Internet Explorer 11’s address bar, Process Explorer noted that the process launched was running at medium integrity.  I also tested this against Google Chrome and it did not exhibit this peculiar behavior.   After that assessment, the group figured that it wouldn’t matter whether IELaunchURL was there or not because just redirecting to localhost would launch a process at medium integrity. It is important to highlight the fact that launching medium integrity processes is a problem in four major versions of Internet Explorer since the Verizon paper.  You don’t need the required protected mode API or have to interface with the broker at all.  Simply redirect with any means possible, whether it be with JavaScript, page reload, etc.  Our identification that redirection to medium integrity can occur with what can be considered normal operation demonstrates that this can potentially be used in a covert manner without triggering anomalous behavior. 


And there you have it. This is how reading sandbox bypass papers of the past, reading the news, and enjoying a cold beverage led to verifying a specific behavior about Internet Explorer, which spawns a medium integrity process. 


Localhost with Protected Mode


While testing on Internet Explorer 11, typing in http://localhost into the address bar resulted in a launch of a medium integrity process.  Here is a picture of the latest Internet Explorer launching a process running at medium integrity.


Internet Explorer running on Windows 8.1 x64:


Attackers have a very simple way of launching a medium integrity process with localhost.


Bypass code


After finding out the news about localhost, Abdul began testing remote code execution with localhost as the hostname, while Jasiel and I began trying to develop a way to deliver the same remote code execution to localhost.  Jasiel had done some initial tests with his process introspection python code by remotely running SimpleHTTPServer.  This led to the idea to write proxy shellcode in order to serve the second exploit page to localhost after a JavaScript redirect call from low integrity for simplicity purposes.  With all of us working together, it took little time for us to assemble the whole chain.


The chain of events looks like this:



The proxy was developed by modifying the PIC_Bindshell project workspace from Matt Graeber – mattifestation which is available at:

Kudos to Matt for his excellent work!


Here is what one function of the shellcode looks like:


It’s pretty straight forward and the 0x43434343 and 0x4444 values leaves room for run time patch configuration.


Post Exploitation Process Continuation


Brett Moore defines continuation in the Post Exploitation Process Continuation presentation as: “target process continues to execution after the exploit has completed its mission.”  Find this presentation and read it.  I highly recommend it.


We tackled continuation in one way or another when we performed the following parts of the exploit:

  • Generating the first infoleak
  • Execution of proxy shellcode
  • Generating a second infoleak
  • Cleaning up the process after exploitation

With regards to the sandbox bypass, after the proxy shellcode is executed, it is required that you continue execution and return from a function call as if nothing happened.  This is necessary because this will allow for the redirect to occur and will allow the exploit to run a second time at medium integrity.  It is also required that your low integrity process and threads do not die upon redirect. 


Patching mshtml’s process and thread related code in the shellcode to keep the process alive is how this was achieved.  It is also required to fix any destructive memory behavior.  After medium integrity code execution is achieved, you have several options.  You can clean up the process, jump out and inject into something else, or redirect to another page, etc. The third option mentioned creates a process at low integrity and leaves you with your medium integrity process along with the proxy shellcode process.  The latter two you can kill, leaving no real artifacts hanging around in memory except for your amazing cat picture of choice.


Checking that the proxy is up


Checking for proxy execution before redirection is one of the things we felt was required.  Internet Explorer has a cross-domain policy that inhibits certain localhost requests in JavaScript. To ensure that the proxy is up, requesting a picture from localhost will bypass the policy and will allow you to check that the proxy is working before the exploit page redirect. 


This code looks like this:





The following is a video of code execution of the proxy shellcode and code execution at medium integrity:




The charitable donations from both HP’s win and Google’s win at Pwn4Fun are something quite unprecedented. On Day 2 of Pwn2Own, the Keen Team announced they would donate a portion of their winnings to support a charity. Bruce Dang announced he would donate proceeds from his book to charity as well.  The charitable spirit from the events of Pwn2Own/Pwn4Fun made tangible positive change. Pwn2Own is stronger than ever and results in some of the most innovative public research every year.  Meeting the great minds involved with this event has been an amazing experience as well as inspiring because of their truly brilliant research brought to the forefront.  When you bring your exploits to Pwn2Own, it demonstrates clear proof to everyone that your research is strong and effective.  We look forward to seeing all participating researchers and new faces to the competition again soon!


For those of you headed to Las Vegas, come say “Hi!” to the ZDI!

We will be speaking at both Black Hat and DEF CON 2014.


More info on other sandbox bypasses that were demonstrated at Pwn2Own will be discussed at Brian Gorenc’s and Jasiel Spelman’s Blackhat presentation called “Thinking Outside The Sandbox – Violating Trust Boundaries In Uncommon Ways”. 


Cell phone research in SMS/MMS fuzzing performed by Brian and I will be discussed at DEF CON in a presentation called “Blowing up the Celly: Building your own SMS/MMS Fuzzer”.


Hope to see you there!



  • HPSR
  • Internet Explorer
  • localhost
  • sandboxbypass
  • ZDI
  • Zero Day
0 Kudos
About the Author