Time Element Memory Corruption – a remote code execution vulnerability, recently patched by Microsoft as part of MS11-050, bearing the Common Vulnerabilities and Exposures (CVE) number CVE-2011-1255 is being actively exploited in the wild.
M86 Security Labs team was contacted and asked to inspect the URL of a legitimate website of a large private company that was blocked by one of the proactive detection rules implemented in our Secure Web Gateway product.
We were asked to investigate if it was indeed a malicious page or a case of Over-Blocking.
Was injecting an iframe:
pointing to a malicious page that was very easilty classified as malicious due to shellcode patterns being part of the page’s DOM:
So, just another infected site – big deal right? But, after further inspection, we saw that it exploited an un-published security vulnerability in Internet Explorer. To verify this, we viewed the malicious page on the latest fully patched version of IE and saw a crash followed by execution of malicious code.
You can imagine the excitement on the team – finding a 0-day in the wild!
The excitement of finding a 0-day in the wild didn’t last that long, since soon after, Microsoft released details about this particular vulnerability.
Based on data we have reviewed from various sources, we can say with a high level of certainty, that the anonymous researcher who according to Microsoft’s security advisory, reported the vulnerability details to VeriSign iDefense, or at least one of his acquaintances, had used the vulnerability details for malicious purposes, as part of targeted attacks.
We decided that we should inspect the shellcode to see what the attacker was after. It used various anti-debugging tricks, but after decoding, it revealed a clear-text URL pointing to a malicious server already listed in our repository.
The attack sample stored in our repository was an attack for the well-known iepeers.dll vulnerability exploiting CVE-2010-0806.
It is interesting to note that the first saved sample of the attack was dated 21.3.10, while details of the vulnerability were reported and patched by Microsoft’s MS10-018 security patch for Internet Explorer on 30.3.10.
Two 0-day exploits served from the same server – impressive!
We wanted to find out where else he is serving his malicious code.
Remember the code snippet shown above, showing how the attacker hid the shellcode as part of the DOM?
Hiding data in the DOM of the page is a good obfuscation technique that bypasses security software that doesn’t act as an actual browser, and where their script engine does not have access to the actual DOM.
It turns out that one of the side-effects of hiding data inside DIV elements is that it makes the data indexable by search engines.
Google searching the pattern “TTu0d0f[...snip...]d0dLL1043416UU” revealed about 16 results and as of this writing, only a few were still alive.
Here is the list of the infected sites according to Google’s search result:
Not to mention the service of caching samples for us, it’s ironic that an attacker’s obfuscation technique can be used against him to find his infection servers using a simple Google search.