The Trojan.Hydraq Incident: Analysis of the Aurora 0-Day Exploit

You probably have heard the recent news [1] [2] [3] [4] about a widespread attack that was carried out using a 0-Day exploit for Internet Explorer as one of the vectors. This exploit is also known by the name Aurora Exploit. The code has recently gone public and it was also added to the Metasploit framework.

This exploit was used to deliver a malicious payload, known by the name of Trojan.Hydraq, whose main purpose was to steal information from the compromised computer and report it back to the attackers.

The exploit code makes use of known techniques to exploit a vulnerability that exists in the way Internet Explorer handles deleted object. The final purpose of the exploit itself is to access an object that was previously deleted, causing the code to reference a memory location over which the attacker has control and in which the attacker dropped his malicious code.

We have developed and released IPS signature HTTP MSIE Memory Corruption Code Exec(23599) that blocks this exploit attempt. Since the release of this particular IPS signature, the number of explot attempts in the wild is steadily increasing on a daily basis.

 
We now see the exploit code hosted in multiple countries such as China, Korea, India and Poland and the list is expected to grow.

Let’s now see the details of the exploit!

The main page begins with a simple javascript decrypter:

This code is only decrypting itself and then running the decrypted code (the encrypted data is stored in the b variant). So, after decrypting it, we have the following:

We can already recognize elements like the shellcode and the nop-like padding used for the heap spray.

Let’s break this into pieces. The script begins with the setup of the shellcode and the decryption of some encrypted bytes. Once decrypted, these bytes result in the following code:

This is the code that does the main heap spray. It fills the memory with lots of bytes that can be executed without creating meaningful changes (or crashing), then the malicious shellcode is appended to this big chunk of harmless bytes. Nothing new here, the heap spray is a well known technique.

Image 1: We can see here a piece of the heap spray nop-like bytes (0D 0C) and then the beginning of the malicious code.

After the memory has been properly filled with the attacker’s data, the code does the following:

It creates two hundred elements labelled COMMENT, and fills their .data property with the simple string abc. We will explain the meaning of this later.

The setup has been done, so the code will then start doing its serious business. It begins with a simple image:

This is a SPAN tag that contains an IMG tag. This tag references the aaa.gif  image. We also see that the onload handler is called when the image is loaded, and this will result in a call to the function ev1. So, in order to work, this exploit needs an aaa.gif file to be present in the same directory where this html page is being loaded.

Let’s jump to the ev1 function then:

It creates an event object associated to the object passed by the onload handler that we saw above in the IMG tag. Now the interesting part: it uses the innerHTML property of the SPAN tag to actually remove its inside IMG object. Basically, the IMG object has been removed and is no longer valid. The last line only sets up a timer so that the ev2 function is called back every 50 milliseconds.

This is the core of the exploit itself. First, we see a for loop that goes thru the x1 array. This array is the one that contains the two hundred COMMENT objects that were created above. For each one of these objects the code sets the .data property to a series of  0x0C0D bytes. So, is it doing  some more heap spraying with a nop-like padding? No. As you can see, the data being assigned to the .data member is of fixed length and it is too small to be a spray. Besides, the code has already done enough heap spraying above, so why all this? Well, this code is simply trying to overwrite the memory of the IMG object that was previously valid. Once the IMG object is being de-allocated, the memory it was using becomes free again. When the code does the assignment on the .data property, this data needs to be stored on some space on the heap. And guess what, the system will reuse the memory that was allocated for the IMG object and that is now free for everyone. This means that the attacker has overwritten the IMG object with the data he wants. Why 0x0C 0x0D? Because this will result in the address 0x0C0D0C0D, which is a valid address being allocated as a consequence of the previous heap spray.

As a test, I changed all the above u0c0d with u9090, so that the IMG object gets filled with 0×90909090 data, and since this value is not  possibly a valid address (it falls outside the memory of the process and it is a kernelmode address which is not directly accessible by the application) the exploit should not work, and I should be able to see it crash when this address is being de-referenced. And in fact, there we go:

Image 2: The code that does the de-reference of the deleted IMG object. In this test, it  tries to use the ECX register as a pointer, but the ECX holds the invalid value 0×90909090 so the process crashes because of a memory access violation.

The attacker instead makes it so that the ECX register will hold the value 0x0C0D0C0D. This address is going to be valid because the attacker caused the system to allocate it via the previous heap spray:

Image 3: The exploit reads the data from the valid address 0x0C0D0C0D

Finally, the code accesses the “e1” object

This function causes the system to return the object that caused the event to be fired. Said object in this case was the IMG object that as we have seen above has been removed via the InnerHTML property. So, when the code tries to access the IMG object, it will de-reference a pointer to it, but now the memory that should have the data about the IMG has been overwritten by the attacker with lots of 0x0C0D0C0D values. This will cause Internet Explorer to actually de-reference the 0x0C0D0C0D address, which is valid because the attacker performed a heap spray that resulted in allocating the memory at that address. So with this de-reference operation the code will end up executing the data that the attacker has setup and then running the malicious shellcode which will try and download a malicious executable.

Image 4: The malicious shellcode being run

In conclusion, this exploit does not seem to be very stable or reliable, yet it is very dangerous and has been successfully delivering malicious payloads. Usual good practice can be helpful in order to mitigate this threat: don’t browse untrustworthy or unknown websites; don’t click on links received by email; keep your security software updated; and also ensure that your Operating System and your browser are being updated periodically.

References:
[1] The Trojan.Hydraq Incident
[2] Protect Yourself Against Exploit Targeting New IE Zero-Day Vulnerability
[3] Hydraq – An Attack of Mythical Proportions
[4] Attack on IE 0-day refined by researchers

About the Author: