Waves of Attacks Target Adobe Reader Bug From 2010

Type threatpost
Reporter Dennis Fisher
Modified 2013-04-17T16:32:46


Adobe vulnerabilityThanks to the wonderful tendency of users not to update their applications, old vulnerabilities never die, they just get overtaken by newer and shinier ones. The attackers know this well, and every once in a while they serve up a nice reminder to the rest of us. The most recent one of these is a string of attacks against an Adobe Reader vulnerability from 2010.

The vulnerability, which is more than two years old, is a flaw in Reader and Acrobat that can be exploited remotely. At the time of the first reports about the bug, there were active attacks going on against it and exploit code was circulating online. But the CVE-2010-0188 bug didn’t turn into one of those huge things that involve widespread malware attacks and so on. And it’s been patched for a long time at this point, but that doesn’t mean it’s of no use to the bad guys anymore.

Researchers at Symantec have found that there are still attacks ongoing against the bug, which affects Reader and Acrobat on all of the major platforms. The attacks involve some highly obfuscated JavaScript, as such attacks are wont to do, and the end result is that once the resultant shell code is on the victim’s machine, it attempts to download a malicious executable from a remote server.

The attacks against this bug have been coming in waves for the last month or so, and Symantec researchers said that the company has seen more than 10,000 such attacks in just the last couple of weeks.

“The JavaScript was embedded in an XFA object (object 8 in the above figure) in an Acrobat Form. The JavaScript manipulated a subform field by using a reference to an embedded element, ‘qwe123b’ in the example. When such an exploited PDF sample is loaded into the vulnerable PDF reading application, the XFA initialize activity is triggered and the embedded JavaScript will be called. After manually de-obfuscating it, we were able to extract the hidden JavaScript,” Jason Zhang of Symantec wrote in an analysis of the attacks.

Once the JavaScript runs, it does a few things, including checking the version of the vulnerable application that’s on the targeted machine. That version number is then converted into a huge integer and the JavaScript builds an exploit and shell code that’s specific to that version. It then sprays the shell code into the application’s memory and is off and running. But that’s only half of the game.

The shell code includes an obfuscated URL to which the code attempts to connect and then download an executable.

“It clearly shows that a malicious executable file will be downloaded once the shellcode gets executed successfully. Unfortunately, the malicious file link only existed for a very short time and we have been unable to retrieve the actual executable sample as yet,” Zhang said.