You probably have heard the recent news 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 as the "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
, the main purpose of which 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 a 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 the HTTP MSIE Memory Corruption Code Exec(23599)
IPS signature that blocks this exploit attempt. Since the release of this particular IPS signature, the number of exploit 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!
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 by setting up the shellcode and decrypting 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.
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 labeled 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
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 a 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 deallocated, the memory it was using becomes free again. When the code assigns the .data
property, this data needs to be stored somewhere on the heap. And guess what, the system will reuse the memory that was allocated for the IMG
object, which 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 instances of the above \u0c0d
, so that the IMG
object gets filled with 0x90909090
. Since this value is not possibly a valid address (it falls outside the memory of the process and it is a kernel mode 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 dereferenced. And in fact, there we go:
Image 2: The code that does the dereference of the deleted IMG object. In this test, it tries to use the ECX register as a pointer, but ECX holds the invalid value 0x90909090, 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
This function causes the system to return the object that caused the event to be fired. The 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 dereference 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 dereference 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 dereference operation, the code will end up executing the data that the attacker has set up and then run the malicious shellcode, which will try and download a malicious executable.
Image 4: The malicious shellcode running.
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. The usual best practices can be helpful in order to mitigate this threat: don’t browse untrustworthy or unknown Web sites, don’t click on links received through email, keep your security software updated, and ensure that your operating system and browser are updated periodically.
Next: Seeing Past Trojan.Hydraq’s Obfuscation
Previous: The Hydraq VNC Connection