Document-Based Exploits (Part II)

[Nytro]

Document-Based Exploits (Part II)

Several factors make Adobe Reader an attractive target for exploitation to get malicious code run on a target machine. The first is the application has many buffers that can be populated by loading a document. Adobe Reader can also be thought of as an interpreter, executing whatever valid code might be contained within a document, using functions that potentially have vulnerabilities.

The biggest factor is the software is common to most desktop computers, giving the largest number of potential victims, a problem that’s exacerbated by web browsers that automatically load PDFs in a browser plugin after fetching them from web servers.

Here I’m going to illustrate that with two particular exploits I found in the CRIMEPACK, Blackhole, Eleanor and Phoenix crimeware kits (full write-up on these later).

Collab.getIcon()

Discovered (or publicly disclosed) in March 2009, the Collab.getIcon() method/function vulnerability appears to be specific to Adobe Reader, and the exploit must be implemented as a JavaScript call to this function. According to the advisories the exploit is a typical stack overflow through a malformed call to getIcon(), and this allows arbitrary code execution – a typical way of changing the Instruction Pointer value to the address of some malicious code. An example of this and a copy of the vulnerable application (for Windows users) are available from the Offensive Security exploit database (number 9579). The exploit is also available as a Metasploit module.

We’re looking for two things within a malicious PDF: something that causes an exception, and a payload that executes when the exception occurs. So, if we run the strings utility on an example PDF from SecurityFocus… where the hell is the exploit? Where is the getIcon() request for that matter?

The best place to start is by looking at the file’s structure and layout. PDFs are self-referencing, that is each section is an object marked by a reference number such as 10, 20, 30, etc. The contents of each object can also contain a reference to another object. In the SecurityFocus PDF, one section, 30, references some JavaScript in another section, 70R:

By the way, I’m using the SecurityFocus example because the references within the actual crimware PDF are also obfuscated.

Looking further through the code, at the referenced object, some random characters are found. This, I believe, is the exploit and payload.

However, it’s unintelligible because the content of that section is compressed and obfuscated, which enables the malicious code to get past various intrusion detection/prevention methods. For a while it would also have made reverse-engineering tricky because the tools were less readily available. Obfuscated code is indicated by the ‘/Filter /FlateDecode‘ string.

To uncompress/decode this section, I used qpdf. Since this doesn’t work on the SecurityFocus sample, I ran qpdf on the actual crimeware PDF instead:

$qpdf --stream-data=uncompress geticon.pdf 3rdattempt.pdf

The output file contains the unobfuscated exploit and its payload, and the following section is instantly recognisable as an array buffering the payload:

Of course, the payload is unreadable as the strings utility is attempting to convert hex shellcodes into ASCII text. To get those, the PDF must be run through a hex editor or something like Bokken.

Unfortunately the shellcode is OS-specific and I wasn’t using a Windows machine, so I didn’t analyse it further. What we do already know is the payload results in the installation of a banking Trojan. The payload was buffered as an array for the exploit code itself, which is seen further down:

util.printf()

Problems with the printf() function in the C programming language are well-known. They aren’t necessarily caused by the developers of Adobe Reader, but instead it’s a vulnerability native to the C language, where the function doesn’t check the stack boundaries. Here the vulnrability might be in the C code underlying the JavaScript interpreter.

A full description and an exploit attempt is published on the CORE Security site, and that works by overwriting the Structured Exception Handler address with that of another location where the shellcode is placed. Again, the malicious code is only executed with the privileges of whoever’s running the PDF reader.

Conclusion

As both exploits were found in three crimeware kits, it’s obvious their authors targeted something common to most desktop computers – Adobe Reader. The versions of CRIMEPACK, Blackhole and Eleanor being examined were all created around the same period, so they were either sold by the same group, or the exploits were proven the most effective for circulation among the crimeware authors.

What’s the worst that can happen? Both exploits have already been out there for five years, and other vulnerabilities like them have been found since, so this post only gives a taste of what to expect in a crimeware kit.

The impact of a successful exploit here depends on the credentials the Adobe Reader application is running under. If it’s a standard user account with limited privileges, the exploit would lead to only that account being initially compromised, although privilege escalation is always possible afterwards. The latter is unlikely, though, as the crimeware has obviously been developed to automate things as much as possible, and the attacker would have many compromised admin accounts. If the user has admin privileges at the time the application is exploited, the payload has full control of the system.

As can be demonstrated using Metasploit, the payload could be anything, including a reverse shell for remote access or code that fetched a malware installer. The people behind the crimeware were counting on some victims being logged into the admin account, or on being able to escalate their privileges after the account was compromised.

Sursa: https://xerocrypt.wordpress.com/2014/04/19/document-based-exploits-part-ii/