Zero-day - Part 1 Anatomy of an exploit - inside the CVE-2013-3893 Internet Explorer

Zero-day - Part 1 Anatomy of an exploit - inside the CVE-2013-3893 Internet Explorer

As you are probably aware, Microsoft's October 2013 Patch Tuesday includes an update for Internet Explorer that closes no fewer than ten RCEs, or Remote Code Execution holes.

This sort of vulnerability means that merely looking at a booby-trapped web page could infect you with malware, even if you don't click on anything on the page.

Unfortunately, an exploit that takes advantage of one those ten holes, CVE-2013-3893, is known to be in the wild.



Cybercriminals have been using it; a proof-of-concept HTML page has been published that you can tweak for your own attacks; and the popular penetration tool Metasploit now includes it.

So rather than just leave you to apply the patch and be done with it, we thought we'd look at this exploit in some detail.

We hope that this will help you understand the lengths that cybercriminals will go to in order to attack your computer, despite the layers of protection that modern versions of Windows and Internet Explorer include.

Don't worry if you aren't technical: we've tried to keep the assembler code and the programming jargon to a minimum.

Just glide over anything you don't understand and get a feeling for how cyberattackers think - "know thine enemy" is a handy part of any defence.

And, no, we haven't given away so much that you can turn this article into an attack of your own: it's an explanatory guide, not a how-to tutorial.

The core of the hole

Our attackers will be exploiting a bug in Internet Explorer's mouse capture functionality.

In JavaScript, an object on an Internet Explorer web page can take or relinquish control over the mouse events that happen in the brower window, such as clicking and double-clicking.

This is done using the functions setCapture() and releaseCapture().

An object can also declare an onclosecapture function, which will automatically be called if ever it loses control of the mouse, for example because another object calls setCapture() to take over.


Our attackers seem to have discovered that these functions can be used to trick Internet Explorer, by orchestrating an unusual sequence of operations, something like this:

[1] Create 10,000 items in the current web page, giving each one a title string of "3333....3333".
[2] Free the memory of the last 5000 items by setting the title back to a blank string.
[3] Create two more items, making one the parent of the other.
[4] Set an onclosecapture event for the child item, in which 10,000 more items entitled "3333....3333" will be created.
[5] Call setCapture() from the child item.
[6] Call setCapture() from the parent (thus causing the onclosecapture from [4] to be called in the child item).
What it does

Here's what you see if you run the trigger code that does this under a debugger, using Windows 7 with Internet Explorer 9:



If you aren't familiar with debuggers, this window tells you that the program has crashed at the address 0x6AA33859 in the system library MSHTML.DLL, trying to run the instruction:

MOV EDX,DS:[ECX]
(In Intel assember notation, data flows from right to left, so this means "move the value of [ECX] into the register EDX". And the square brackets mean "fetch the value at the memory address stored in ECX, not the value of ECX itself." The DS: just denotes that the value comes from the processor's data segment.)

To explain further, the code at and after the offending instruction above does the following:

MOV EDX,[ECX] ; Fetch the contents of the
; memory address in ECX,
; where ECX is controlled
; by the string in [1] and [4]
; on the attacker's web page.
MOV EAX,[EDX+C4] ; Fetch the contents of the
; address C4 bytes past that.
CALL EAX ; And call it as a subroutine.
The exception occurs because ECX = 0x33333333 (the ASCII code for the text string "3333"), but there is no memory allocated at that address for the processor to read.

It looks as though memory that was freed up in [2] was then re-used by Internet Explorer to store data that controls the flow of execution in MSHTML.DLL (Microsoft's rendering engine), and then wrongly re-used against for saving the text strings created in [4].

That's a use after free bug, and in this case, it means our attackers can lead Internet Explorer astray: they can trick the browser into using untrusted data from their remote web page to tell your computer where to jump next in memory.

That means there is very likely to be a chance for RCE, or Remote Code Execution.

The next step

To make further headway, the attackers needed to to force ECX to contain the address of memory that is allocated, and that they can influence.

Adding a step [4.5] to the list above does the trick:

[4.5] Create 320 text strings that take up 1MB each, containing the bytes 0x12121212 repeated over and over.
This is known as a heap spray, and it's an operation that uses JavaScript's powerful string-handling functions to force the operating system to allocate large blocks of memory in a controlled way.

If we run Internet Explorer again until it crashes, and then peek at the memory blocks allocated by Windows, we can see the results of the heap spray.

The size column shows that these blocks are all 0x00100000 bytes in length, or 1MB:

If you aren't familiar with debuggers, this window tells you that the program has crashed at the address 0x6AA33859 in the system library MSHTML.DLL, trying to run the instruction:

MOV EDX,DS:[ECX]
(In Intel assember notation, data flows from right to left, so this means "move the value of [ECX] into the register EDX". And the square brackets mean "fetch the value at the memory address stored in ECX, not the value of ECX itself." The DS: just denotes that the value comes from the processor's data segment.)

To explain further, the code at and after the offending instruction above does the following:

MOV EDX,[ECX] ; Fetch the contents of the
; memory address in ECX,
; where ECX is controlled
; by the string in [1] and [4]
; on the attacker's web page.
MOV EAX,[EDX+C4] ; Fetch the contents of the
; address C4 bytes past that.
CALL EAX ; And call it as a subroutine.
The exception occurs because ECX = 0x33333333 (the ASCII code for the text string "3333"), but there is no memory allocated at that address for the processor to read.

It looks as though memory that was freed up in [2] was then re-used by Internet Explorer to store data that controls the flow of execution in MSHTML.DLL (Microsoft's rendering engine), and then wrongly re-used against for saving the text strings created in [4].

That's a use after free bug, and in this case, it means our attackers can lead Internet Explorer astray: they can trick the browser into using untrusted data from their remote web page to tell your computer where to jump next in memory.

That means there is very likely to be a chance for RCE, or Remote Code Execution.

The next step

To make further headway, the attackers needed to to force ECX to contain the address of memory that is allocated, and that they can influence.

Adding a step [4.5] to the list above does the trick:

[4.5] Create 320 text strings that take up 1MB each, containing the bytes 0x12121212 repeated over and over.
This is known as a heap spray, and it's an operation that uses JavaScript's powerful string-handling functions to force the operating system to allocate large blocks of memory in a controlled way.

If we run Internet Explorer again until it crashes, and then peek at the memory blocks allocated by Windows, we can see the results of the heap spray.

The size column shows that these blocks are all 0x00100000 bytes in length, or 1MB:

If you aren't familiar with debuggers, this window tells you that the program has crashed at the address 0x6AA33859 in the system library MSHTML.DLL, trying to run the instruction:

MOV EDX,DS:[ECX]
(In Intel assember notation, data flows from right to left, so this means "move the value of [ECX] into the register EDX". And the square brackets mean "fetch the value at the memory address stored in ECX, not the value of ECX itself." The DS: just denotes that the value comes from the processor's data segment.)

To explain further, the code at and after the offending instruction above does the following:

MOV EDX,[ECX] ; Fetch the contents of the
; memory address in ECX,
; where ECX is controlled
; by the string in [1] and [4]
; on the attacker's web page.
MOV EAX,[EDX+C4] ; Fetch the contents of the
; address C4 bytes past that.
CALL EAX ; And call it as a subroutine.
The exception occurs because ECX = 0x33333333 (the ASCII code for the text string "3333"), but there is no memory allocated at that address for the processor to read.

It looks as though memory that was freed up in [2] was then re-used by Internet Explorer to store data that controls the flow of execution in MSHTML.DLL (Microsoft's rendering engine), and then wrongly re-used against for saving the text strings created in [4].

That's a use after free bug, and in this case, it means our attackers can lead Internet Explorer astray: they can trick the browser into using untrusted data from their remote web page to tell your computer where to jump next in memory.

That means there is very likely to be a chance for RCE, or Remote Code Execution.

The next step

To make further headway, the attackers needed to to force ECX to contain the address of memory that is allocated, and that they can influence.

Adding a step [4.5] to the list above does the trick:

[4.5] Create 320 text strings that take up 1MB each, containing the bytes 0x12121212 repeated over and over.
This is known as a heap spray, and it's an operation that uses JavaScript's powerful string-handling functions to force the operating system to allocate large blocks of memory in a controlled way.

If we run Internet Explorer again until it crashes, and then peek at the memory blocks allocated by Windows, we can see the results of the heap spray.

The size column shows that these blocks are all 0x00100000 bytes in length, or 1MB:



Each of those blocks is crammed with the bytes 0x1212....1212.

Notice particularly - and we shall soon see why this is terribly convenient - that the memory block containing the address 0x12121212 (and the address 0x121212D6, which is 0xC4 bytes further on), is one of the chunks filled with 0x1212....1212.



Finding the right size for each heap spray object, and the right number of memory allocations to perform in order to get a neat and exploitable result, doesn't need to be done analytically.

Cybercriminals can save time and effort simply by using trial and error - a process that can be automated.

So, instead of using the text string "3333", as in steps [1] and [4] above, our attackers can choose a value that corresponds to an address inside one of the blocks they know their heap spray will produce.

In the published exploit, they chose 0x12121202, though many others would have done just as well, so that steps [1] and [4] no longer have ECX set to "3333".

Instead, ECX becomes 0x12121202, and the crooks get this:

; EDX gets the contents of 12121202

MOV EDX,[12121202]

; EDX is now 12121212, so
; EAX gets the contents of EDX+C4 (121212D6)

MOV EAX, [12121212+C4]

; EAX is now 12121212, which we call

CALL 12121212

; Execution is now at an address we control!
On versions of Windows before XP SP3, the attackers would already have won the battle at this point, by adapting the text strings from [4.5] so that they contained shellcode (executable code hidden in chunks of data) starting at 0x12121212 , thus instantly getting control.

But these days (and we're on Windows 7 in this article, remember), memory blocks dished out by the operating system - allocations "on the heap", as they are known - are set to be NX, or No Execute, by default.

If you try to execute an instruction in a memory page marked NX, the processor steps in and stops you.

This is the basis of DEP, or Data Execution Prevention, and it means that even though our attackers can control exactly what is at address 0x12121212, and divert the processor to it, they can't make it run:



On Windows XP, DEP slows the attackers down a bit, but not much: all they need to do is to tweak the heap spray so that the value at 0x121212D6 is an address in executable memory.

(0x121212D6, remember, is 0x12121212+0xC4: that's where the CPU will jump as a side-effect of triggering this bug, due to the CALL EAX instruction shown above.)

The richest sources of ready-to-use executable memory are the numerous system DLLs that are almost always loaded, such as KERNEL32.DLL, USER32.DLL and GDI32.DLL.

Getting around ASLR

On Windows 7, however, picking addresses in system DLLs is much harder than it sounds, because of ASLR, or Address Space Layout Randomisation.

For example, here's a table from our test computer, showing where Internet Explorer and its first few DLLs are supposed to load, and where they actually loaded on three successive reboots:



In short:

DEP stops attackers with a vulnerability like this one from jumping straight to their shellcode as soon as the exploit gets control.
ASLR stops attackers from bypassing DEP by jumping into a system DLL, because they don't know where it will be in memory.
→ On Windows XP, system DLLs load at the same place every time, on every computer, making XP much easier to hack. That alone is enough reason to ditch XP as soon as you can, regardless of the looming "no more patches" deadline of April 2014.

But our attackers have a way around this, because some common and popular DLLs still advertise themselves as incompatible with ASLR, and are therefore loaded without it.

So they added this line of JavaScript for attacking Windows 7 users:

try{location.href='ms-help://'} catch(e){}
If you have Office 2007 or Office 2010 installed, trying to open an ms-help:// URL causes Internet Explorer to load the support library hxds.dll:



Sadly, the address 0x51BD0000 is exactly where this DLL always loads, because it was compiled by Microsoft without the so-called DYNAMICBASE option, thus causing it to be left out of ASLR:



Admittedly, this restricts the attackers to infecting computers on which Office is installed - but in practice, that isn't a major limitation: even if you don't own Office, you may well have a demo version left over from when you bought your PC.

At this point, our attackers are on the brink of controlling your computer, having evaded all of the following:

Windows memory management.
JavaScript's "sandbox".
Data Execution Prevention.
Address Space Layout Randomisation.
The good news is that they still have a fair amount of work to do.

Before they can go any further, for example, they need to choose which address in hxds.dll they will write at offset 0x121212D6, to be the target of the fateful CALL EAX that will give them their first unlawfully executed machine code instruction.

The bad news, of course, is we already know that our crooks are going to succeed in the end.

So, please join us next week for Part Two, where we'll show you what they are going to do next, and why, and how you can detect and prevent their nefarious activities.