marco
blog
Menu:
CVE-2009-3459, CVE-2009-4324, and one PDF trick
December 19, 2009
PDF exploits—mostly targeting Adobe Reader and Acrobat programs—are very commonly used on drive-by web sites. This situation is probably the result of the widespread use of the Adobe plugin, a rather large of number of vulnerabilities found in it, and reliable exploitation techniques.
Two recent vulnerabilities for which I have added detection in Wepawet are CVE-2009-3459 and CVE-2009-4324 (click on the links to see analysis reports of two malicious samples). The former is an integer overflow in the PDF parser, the latter is a bug in the JavaScript interpreter.
The analysis of malicious PDF files is often complicated by the use of various obfuscation (or better, “confusion”) techniques. In particular, malicious PDF files are often malformed: expected sections are missing entirely, others are truncated. The attacks are still successful because Adobe Reader does a good job at automatically repairing the damaged file. Of course, analysis tools are not necessarily as good at that.
I recently found an interesting, small trick that was used in the wild.
A little background first. A stream is a basic object (technically, a
dictionary) used in PDF files to contain arbitrary content. In
particular, malicious PDFs use streams to contain the JavaScript code
used to launch an exploit. The Length entry in the stream dictionary
is used to specify, you guessed it, the length of the encoded content.
According to the PDF specification (Section 7.3.8.2 for the curious), the length
is to be specified as an integer. The sample I found, however,
used an expression (a sum) to declare the stream
length in the length declaration.
obj
<</ / / / /Filter/ASCIIHexDecode/Length 100000+12488>>
stream
... stream contents ...
endstream
endobj
Lessons learned: do not trust specs and be a little lenient in the parsing of PDF files...
Update 1/7/2010: Richard B. pointed out that Acrobat seems to detect that the length specification is malformed, discards it, and falls back to a simple parsing strategy to extract the stream contents. Thanks!
Analyzing and detecting malcious flash advertisements
December 10, 2009
Today, Sean Ford is going to present our paper Analyzing and Detecting Malicious Flash Advertisements at the ACSAC Conference.
The paper describes some of the techniques we use to detect malicious Flash files. More precisely, we focused on two main threats:
Flash-based malvertisements that automatically redirect victims to malicious or questionable pages. This type of malware essentially exploits a design flaw in the current advertisement technology: the Flash language and its run time, as implemented in today's browsers, are too powerful and too unrestricted. To put it more plainly, why should an advertisement be able to hijack the browser?
A possible solution here (which we do not explore in the paper) would be to identify a secure subset of Flash and restrict Flash-based advertisement to this subset. Of course, similar work has already been done in the JavaScript camp, see ADSafe or Caja for example, so many lessons could probably be reused.Malformed Flash files that exploit vulnerabilities in common Flash players, typically, Adobe's player. This type of malware exploits classic implementation problems (buffer overflows, integer overflows, etc.).
The paper also describes in some detail a number techniques that are used in malicious Flash files to evade detection (trigger-based behavior, timezone checks, etc.) and obfuscate the malicious code.
Here is the abstract:
The amount of dynamic content on the web has been steadily increasing, and sites now offer user experiences that come close to those found when running local native applications. Advanced scripting languages such as JavaScript and Adobe's Flash have been instrumental in delivering dynamic content on the Internet. Dynamic content has also become popular in advertising, where Flash has achieved success allowing the creation of rich, interactive ads that are displayed on hundreds of millions of computers per day. The success of Flash-based applications and advertisements attracted the attention of malware authors who use Flash to deliver attacks through advertising networks. This paper presents a novel approach whose goal is to automate the analysis of Flash content to identify malicious behavior. We designed and implemented a tool based on the approach, we made it available to the world, and we tested it on a large corpus of real-world Flash ads. The results show that our tool is able to reliably detect malicious Flash ads with very limited false positives.
