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!
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 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.
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 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 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 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 with
\u9090, 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” object:
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