Speaking from first hand knowledge gained from monitoring web-based honeypots, I can attest to the drive-by downloading methodology used in a majority of these attacks. They initially inject some small javascript/iframe snippet of code into the application and then they bounce the web web requests around until finally they send the malicious code.

If your browser has the AcroPDF plugin, it will then be sent to the p.htm page which simply includes an iframe to download the final malicious pdf file called "pef.pdf":

<iframe src=pef.pdf width=0 height=0></iframe>

A quick check on the VirusTotal website lists the following data:

Antivirus

Version

Last Update

Result

AhnLab-V3

2010.10.05.00

2010.10.04

-

AntiVir

7.10.12.136

2010.10.05

HEUR/HTML.Malware

Antiy-AVL

2.0.3.7

2010.10.05

-

Authentium

5.2.0.5

2010.10.05

PDF/Pidief.O

Avast

4.8.1351.0

2010.10.05

JS:ShellCode-B

Avast5

5.0.594.0

2010.10.05

JS:ShellCode-B

AVG

9.0.0.851

2010.10.05

-

BitDefender

7.2

2010.10.05

Exploit.PDF-JS.Gen

CAT-QuickHeal

11.00

2010.10.05

-

ClamAV

0.96.2.0-git

2010.10.05

BC.PDF.Parser-4.MalwareFound

Comodo

6290

2010.10.05

-

DrWeb

5.0.2.03300

2010.10.05

Exploit.PDF.181

Emsisoft

5.0.0.50

2010.10.05

-

eSafe

7.0.17.0

2010.10.05

-

eTrust-Vet

36.1.7893

2010.10.05

-

F-Prot

4.6.2.117

2010.10.04

PDF/Pidief.O

F-Secure

9.0.15370.0

2010.10.05

Exploit.PDF-JS.Gen

Fortinet

4.2.249.0

2010.10.05

-

GData

21

2010.10.05

Exploit.PDF-JS.Gen

Ikarus

T3.1.1.90.0

2010.10.05

-

Jiangmin

13.0.900

2010.10.05

-

K7AntiVirus

9.63.2680

2010.10.05

-

Kaspersky

7.0.0.125

2010.10.05

Exploit.JS.Pdfka.ju

McAfee

5.400.0.1158

2010.10.05

-

McAfee-GW-Edition

2010.1C

2010.10.05

-

Microsoft

1.6201

2010.10.05

Exploit:JS/Mult.AG

NOD32

5506

2010.10.05

JS/Exploit.Pdfka.NKB

Norman

6.06.07

2010.10.05

JS/Shellcode.EP

nProtect

2010-10-05.02

2010.10.05

Exploit.PDF-JS.Gen

Panda

10.0.2.7

2010.10.05

-

PCTools

7.0.3.5

2010.10.02

Trojan.Generic

Prevx

3.0

2010.10.05

-

Rising

22.67.02.07

2010.09.30

-

Sophos

4.58.0

2010.10.05

Troj/PDFJS-CJ

Sunbelt

6990

2010.10.05

Exploit.PDF-JS.Gen (v)

SUPERAntiSpyware

4.40.0.1006

2010.10.05

-

Symantec

20101.2.0.161

2010.10.05

Downloader

TheHacker

6.7.0.1.048

2010.10.04

-

TrendMicro

9.120.0.1004

2010.10.05

-

TrendMicro-HouseCall

9.120.0.1004

2010.10.05

-

VBA32

3.12.14.1

2010.10.05

-

ViRobot

2010.10.4.4074

2010.10.05

-

VirusBuster

12.67.4.0

2010.10.05

-

If you had not kept up with your Adobe Acrobat updates, or as it seems more and more frequently, if the badguys have 0-day PDF reader exploits, then your system will get pwned...

File Upload Abuse

While these attack vectors are prevalent, another vector that is often used is to abuse an applications own file upload capability to plant malicious files on the site for other clients to download later. Allowing clients to upload files to your web application can potentially cause big problems however many businesses require this functionality.

If you must allow for file uploads in your web application, I strongly encourage you to review the OWASP Unrestricted File Upload vulnerability page. While it is certainly possible to attack the web application platform itself, the salient point to highlight in this blog post is the following section:

This means that the end goal of the attack is to use the web applications own file upload mechanism in order to spread malicious files to other clients. So, the question them becomes "How can we analyze these file attachments being uploaded in order to prevent any malicious ones from making into our web application?"

Don't be fooled into thinking that this an easily solved question. Many business owners erroneously believe that you can use your standard AV software to scan the file. What they fail to grasp is the fact that AV software typically only scan OS leve files and these file attachments are usually transient in the HTTP transaction. They often traverse reverse proxy servers, load-balancers, etc... until they are finally stored inside a database in a blob format. OS level AV software scanning won't really help in this situation. So how can we do AV scanning of HTTP file attachment uploads?

ModSecurity's @inspectFile operator provides the capability to extract out file attachments so that they can be examined by OS level validation tools. Older versions of ModSecurity also include a perl script called modsec-clamscan.pl that can be used to have clamAV scan the extracted file attachments. Keep in mind that you are not tied to using only clamAV. You can use any script/tool that you want to inspect a file's contents. In this example we are going to show using the @inspectFile operator in action.

In my modsecurity_crs_15_customrules.conf file, I add this example rule -

I then need to update the modsec-clamscan.pl file to adjust settings for my local system and call up the clamscan tool. Now, if a user uploads a malicious PDF file, such as the "pef.pdf" example I gathered from the web honeyopts, it can be inspected by our modsec-clamscan.pl script. If we send a fie attachment request with the pef.pdf file to our web server with the new rule, we will get a 403 Forbidden and see the following in the Apache error_log:

While clamAV is an adequate free open for AV scanning, the old adage holds true: You get what you pay for. PDF exploit development has advanced to such a degree that signature analysis along is not sufficient to identify malicious files. What is needed is a heuristic analysis of the PDF structure to identify malicious characteristics. It just so happens that one of my colleagues here on the Trustwave SpiderLabs Research Team, Rodrigo (@spookerlabs) Montoro has developed a really cool method based on this concept and he will be presenting it at the upcoming Toorcon conference. Check out his blog post that lists some rather surprisingly low detection rates for malicious PDFs from the AV software used with VirtualTotal. He created a script that checks various PDF structures and scores the components. Here is an example of running his script against a malicious PDF that clamAV did not trigger on:

So, if we want to apply this PDF analysis check against our uploaded files, we simply need to update the format of the script output for use with the ModSecurity @inspectFile operator. We need to make sure that the the first character is a "1" if the file is not malicious and a "0" if it is malicious. After plugging in the new script to my SecRule, here is what I get when trying to upload this new malicious PDF that was missed by clamAV:

So as you can see, we can get more accurate results for identifying malicious PDF files uploaded vs. other AV software. OK, now before you ask, access to Rodrigo's PDF analysis script is not ready for public release. It will be released by Trustwave SpiderLabs at some point in the future.

Keep in mind that the @inspectFile operator is simply a type of API that will allow you to inspect file attachments. It is up to you to decide which type of program you would like to plug-in and use.