Toying With MS11-050

Update 06/29/2011 – 3:46PM

I have modified a local copy of the exploit file I have to run safetly (no shellcode) and still get a crash. Initially I suspected that the final aspects of the JavaScript did not play too much in the role of the crash. After turning some values on and off I have found that a reload is in fact necessary. “window.click” and the CollectGarbage calls can be commented out while still having a crash. The reload too can be commented out, but doing so means you need to manually refresh the browser to get the crash to trigger. I suspect now that the CollectGarbage routine is called only to assist in clearing the memory on the heap rather then aiding directly in the exploitation. More to come…

Original Post

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:

• hXXp://–NO-CLICK–rgreenpea.freehostia.com/1.htm

Taking a look at the source I could tell I had the correct stuff based on the intial reports of the vulnerability. At first glance I could tell this would be the usual reversing the javascript to identify the end exploit. I saw a few write-ups on the bug, so I had some knowledge going through like what to look for or where the trigger may be. Rather then giving a screenshot of the whole exploit code (it is large), I will instead just chunk it up based on function and identify the basic functionality of each.

Towards the bottom of the script we have the initial call to DisplayInfo():

The blob looks a bit nebulous, but what the javascript is doing is actually quite simple. It should be noted that I haven’t seen this method used for getting payloads from the pages. It may be found elsewhere, but in my PDF research I have yet to come across a file that has done this. Exploits kits I have looked at did not appear to grab the shellcode generation in this way either. While this is nothing advanced, it is worth mentioning. It should also be noted that the div appears to play no true value in the exploit other then making it easily identifying through search engines. It appears that this random data could have just as easily been placed strictly within the javascript without modifying the DOM. So, from getdata we can see that two strings are passed in and used as the start/end identifiers. All code in between these identifiers is then returned back to the calling function.

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):

u0d20u0d0du5ed5u77c1u0d20u0d0du0d20u0d0du5ed5u77c1u0d20u0d0du0d20u0d0du5ed5u77c1u0d20u0d0d

Coverting the unicode reprsentation to something more suitable shows the following:

x20x0dx0dx0dxd5x5exc1x77x20x0dx0dx0dx20x0dx0dx0dxd5x5exc1x77x20x0dx0dx0dx20x0dx0dx0dxd5x5exc1x77x20x0dx0dx0d

If we begin to break this down we can start to see a pattern:

• x20x0dx0dx0d
• xd5x5exc1x77
• x20x0dx0dx0d
• x20x0dx0dx0d
• xd5x5exc1x77
• x20x0dx0dx0d
• x20x0dx0dx0d
• xd5x5exc1x77
• x20x0dx0dx0d

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.