Inside the guts of a fiendish Internet Explorer 0-day attack

Bite down, matey, surgeon Pott's got his chopper out

Internet Security Threat Report 2014

Sysadmin blog The latest use-after-free vulnerability in Microsoft's Internet Explorer is being actively exploited in the wild.

While this comes as a surprise to nobody, we all get to live in fear for a while until the software giant manages to get a patch out the door. In the interests of attempting to overcome a particularly nasty bout of insomnia, I decided to find out how exactly how the exploit worked.

The rough overview, according to those who have studied the attack technique, is that there is some broken code in the MSHTML core component of Internet Explorer: specifically, in the way it allocates and releases memory after malicious JavaScript commands the web browser to select the contents of a web page, just as if the user had hit "select all" from a menu.

Some memory is grabbed to create an object associated with this "select all" operation and the command is duly executed. This action immediately triggers another part of the JavaScript set to run when any part of the page is selected. So far, so good.

The selection event handler script then writes a character to the web page. This, for reasons best known to Microsoft, causes the browser to delete the original command object and free its memory.

However, the "select all" command has not finished executing - remember, it was interrupted. The selection event handler is still running, and rewrites 100 HTML image tags with extra data. This is a textbook attempt to force the browser to reuse the memory that was previously holding the "select all" command object and fill it instead with the data in the updated tags. With a lot of luck and testing on the hackers' part, it's possible to carefully overwrite the memory that held the command object with new data. The event handler then exits.

The browser returns to handling the "select all" command, and it tries to use what it thought was its object - instead the object's memory had been freed and now contains data set by the hackers. The object holds the location of an internal browser function that needs to be called, and this value can be changed to point to malicious code - thus hijacking the flow of execution and putting hackers on the road to compromising the machine. It is a classic use-after-free bug.

The malicious code runs with the same privileges as the Internet Explorer process, and can be placed in memory prior to the attack. Once the processor is executing the hackers' code, it can be instructed to download and run a second executable, such as a rootkit, worm or whatever.

The exploit in the wild has some extra steps and layers of packaging to obfuscate the code and line up the attack on Windows XP machines. However, the relevant Metasploit module to demonstrate the attack uses two HTML files, one nested inside an iframe of the other. The parent HTML file creates an array using JavaScript, and sets the first element of that array to be an image on the page. It then sets the "src" property to a random single character. (The original proof of concept used "L", so I will too.)

The parent HTML is here.

Inside the child HTML script is where the magic happens. There are two functions; one "selects all" and the other prints a single character "L" and changes the "src" value of the image object inside the parent HTML's array to the special string that mimics the command object in memory. This is the meat of the exploit. Note that the Metasploit example doesn't have to do this 100 times.

To trigger the whole process, a couple of simple additions to the body tag are used: on loading the malicious page, the child HTML calls the function that selects all the text; this triggers the function assigned to the "on select" handler, the function that writes the changes.

The child HTML is here.

The Metasploit example includes extra JavaScript to place machine code that will attempt to compromise the machine; execution is diverted from the "select all" command to these instructions.

Frightening stuff. This is a really basic view of how to create and then divert execution to a malicious block of memory. Consider that JavaScript is generally always enabled and capable of all sorts of dynamic interaction; once you have the memory block in hand, you can do all sorts of fun things here - dropping in Zeroaccess would be just for starters. Some more clues on who is behind the exploit can be found here.

Throwing a fuzzer at IE and looking at memory dumps, or calling functions in a way that Microsoft never intended, until you identify specific code that allow you to do things like this is intensive work. No matter how well-written your application is, there are always going to be bugs like this that someone can take advantage of.

What should give systems administrators the heebie jeebies on this one is just how easy it is to use, and to extend past the basic exploit to do really creative things. ®

Beginner's guide to SSL certificates

More from The Register

next story
Docker's app containers are coming to Windows Server, says Microsoft
MS chases app deployment speeds already enjoyed by Linux devs
'Hmm, why CAN'T I run a water pipe through that rack of media servers?'
Leaving Las Vegas for Armenia kludging and Dubai dune bashing
'Urika': Cray unveils new 1,500-core big data crunching monster
6TB of DRAM, 38TB of SSD flash and 120TB of disk storage
Facebook slurps 'paste sites' for STOLEN passwords, sprinkles on hash and salt
Zuck's ad empire DOESN'T see details in plain text. Phew!
SDI wars: WTF is software defined infrastructure?
This time we play for ALL the marbles
Windows 10: Forget Cloudobile, put Security and Privacy First
But - dammit - It would be insane to say 'don't collect, because NSA'
Oracle hires former SAP exec for cloudy push
'We know Larry said cloud was gibberish, and insane, and idiotic, but...'
Symantec backs out of Backup Exec: Plans to can appliance in Jan
Will still provide support to existing customers
prev story


Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
Why cloud backup?
Combining the latest advancements in disk-based backup with secure, integrated, cloud technologies offer organizations fast and assured recovery of their critical enterprise data.
Win a year’s supply of chocolate
There is no techie angle to this competition so we're not going to pretend there is, but everyone loves chocolate so who cares.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
Intelligent flash storage arrays
Tegile Intelligent Storage Arrays with IntelliFlash helps IT boost storage utilization and effciency while delivering unmatched storage savings and performance.