Early this week Adobe released a new security advisory about a critical vulnerability found in their Adobe Acrobat and Acrobat reader applications. Even the Internet Storm Center issued a security advisory about the same exploit after it has been found in the wild.
Here at Prevx labs we have had reports of this infection on 2010, September 8th, when our community database automatically detected the dropped malware code.
Actually the exploit itself is not trivial at all and it looks like the job of one or more skilled programmers. While we are seeing more and more pdf exploits targetting Adobe Acrobat and Adobe Acrobat Readers products, we must admit this one is a really rare exploit.
It is able to fully bypass both Data Execution Prevention and Address Space Layout Randomization techniques used to prevent stack overflow, heap overflow and return to libc attacks. Actually most of the job has been done by Adobe by using insecure functions more than by the attackers themselves.
Indeed the exploit is effective due to a couple of programming errors that should have been fixed years ago.
The exploit is triggered when Adobe Reader tries to load and parse a True Type Font which contains a malformed SING table in it. When analyzing the exploit, we spot that the bug is inside the CoolType.dll library installed by Adobe product.
To be more exact, when parsing the SING table, it makes use of a deprecated function called strcat, used to append two strings together. This function is well known to be insecure because it doesn’t check for sufficient space in the destination buffer before appending the source string. There are more secure functions available to the programmer like strcat_s or just strncat. Why is this module still using an old, deprecated and insecure function as it is strcat? Why do Adobe programmers still use it?
Anyway, the stack is now overwritten, but this wouldn’t be enough to exploit the bug because the CoolType.dll has been compiled with /GS and /SAFESEH parameters. This means that a cookie is being put on the stack just before the return address and that the module is using safe exception handlers.
So, overwriting the stack and manipulating the return address is not a feasible way to execute the exploit’s payload because it would overwrite the security cookie too, resulting in an application crash. The same applies if trying to overwrite the exception handler.
Whomever wrote the exploit is much more skilled than what you could think and he deeply analyzed Adobe code, finding out a piece of code inside the exploited routine that could be used as a jump to his own payload. By overwriting initial function’s parameters on the stack, the exploit is able to force a specific call function to redirect the flow code to the malicious payload. Nothing has been overwritten, no security cookie is being alterated, execution is simply passed to the exploit payload.
Usually at this time the payload is blocked by DEP technology because it’s placed in a non-executable memory region. Or, another way to get around DEP is using a return to libc attack to call VirtualProtect API and mark the overwritten memory region as executable. Yet this one would not work because of ASLR which randomize system modules’s base addresses at every system startup. How does this exploit intend to run its payload?
The technique used is really interesting and already known for some years. It is called Return Oriented Programming, and it could be described as a way to control an application flow code by overwriting the call stack to indirectly execute specified instructions of the application code itself. Return-to-libc attack is known to be a more specific implementation of this Return Oriented programming.
To be able to use this exploit technique, the attacker must know in advance the memory addresses where he needs to redirect the flow code to. This would be quite difficult with ASLR running on the target PC, but even this time Adobe gives a hand to the attacker.
Adobe Acrobat and Acrobat Reader make use of a library called icucnv36.dll, which has not been compiled by Adobe with /DYNAMICBASE parameter. This means that, by default, it is not being randomized by the Windows ASLR unless if specifically set.
This is the perfect target the attacker was looking for. By using return oriented Programming the attacker is able to (ab)use icucnv36.dll code. He knows where the module is importing specified functions and he can alterate stack calls to re-use such functions. This way, the payload is able to call CreateFileA, CreateFileMappingA, MapViewOfFile and memcpy APIs to copy and execute its own payload from a fresh new allocated executable memory region.
The job is done. The exploit bypassed both DEP and ASLR, it is now able to run its own code which is a trojan downloader, able to download new malware on the machine. At this time the website from where the trojan is downlading new malware has been shut down. Though we are seeing more pdf exploits using same technique to drop malware.
The trojan downloader dropped by the pdf exploit, called hlp.cpl, has been digitally signed. Yes, this is another case of digital certificate stolen by legal owners. This time the victim was an american financial institution called Vantage Credit Union. The malware appears to be digitally signed by this bank. Clearly it is not, their digital certificate has been stolen. The certificate has been revoked since last Sept. 9th 2010.
Who claimed years ago that digital signatures were the solution to malwares?
By the way, what could we learn from this attack? Adobe could have easily prevented this type of exploit. When developing software, please take time to respect security development guidelines, don’t use deprecated functions and make your own developed code DEP,ASLR and SAFESEH compabile to enforce the security of your software and the safety of your whole operating system.
A more detailed analysis has been published by security company Vupen at this link. While waiting for a security patch that Adobe should release soon, Windows users could use Microsoft EMET tool – Enhanced Mitigation Experience Toolkit – that will enhance system security by tuning up DEP and ASLR system settings.
View full post on Prevx Blog
