Update 06/29/2011 – 3:46PM
I happened to come across the following article this morning and wanted to take a look at the exploit being used. Understanding the workings of the original or early versions of the exploit may help out when dealing with it later, so I wanted to write up my thoughts and throw them out there.
On the above blog there were a couple sites listed as hosting the exploit. This was identified through the div tags being indexed by Google and thus making the exploit searchable (shakes head). After a few unsuccesful attempts I got a hit with the following:
Towards the bottom of the script we have the initial call to DisplayInfo():
The returned data is then sent off to the codebk function:
Which then passes data off to de:
De does a couple operations on the passed in data ultimately turning the shellcode looking code to actual shellcode. This process continues on until we get towards the bottom of the main eecc routine. Where it begins to get interesting is when we see the variable “a1″ getting filled with HTML Image Element objects with no data or attributes. By the end of the for we have 1000 of these objects stored within “a1″. At this point the random data located within the hidden div is now cleared out and removed from the equation.
After clearing out the div we can see a call to an IE specific CollectGarbage() function. It appears in this case that the garbage collection is triggered to clear up the heap to ensure the attacker has a good idea of what he is working with or that the collection routine will free up those potentially malformed image tags leaving reference pointers freed on the heap. After the garbage collect we can see that the HTML objects (potentially freed up) are modified with the addition of the following value as their title (before being passed to codebk):
Coverting the unicode reprsentation to something more suitable shows the following:
If we begin to break this down we can start to see a pattern:
It appears that the “x20x0dx0dx0d” could be some sort of padding while the “xd5x5exc1x77″ is a memory address that contains the next instructions. It is unclear what exactly the relevance to that code is unless a debugger is hooked up to the proper IE process. Because the for loop is modifying a DOM object directly, this should trigger the DOM update and display the potentially freed HTML objects causing the crash. I imagine that last window.click before the final refresh is some sort of last effort to trigger the DOM to display the images just in case something fails.