Toying With MS11-050
by admin • June 28, 2011 • Uncategorized
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 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.