PDF exploit loads via i-frame

Most of the PDF exploits in drive-by attacks load into the browser via javascript code when the user is redirected to a malicious server. Several have been noted using an i-frame.

Sample code on a redirected page:

Code:

i frame  src="...../myreadme.php?q=5"

The attack requires Plugins to be enabled for the PDF file to display in the browser window:

​

If the browser is configured to display the download prompt rather than use the Plugin, then the remote code execution method fails:

​

The PDF file has been analyzed as JS/Exploit.Pdfka.NVK


----
rich

 

Just a question, is this some generic pdf exploit or an Adobe Reader/Acrobat exploit, that is, has it been shown to work on any other pdf readers?

 

PDF exploits have to be targeted specifically against a particular Reader because of differences in code.

In this exploit, I can't tell because the ususally reliable Wepawet analyzer lets us down because of clever obfuscation (disguising) of the code. Here is the problem as noted earlier this year:

Static analysis of malicous PDFs (Part #2)
Published: 2010-01-07
http://isc.sans.org/diary.html?storyid=7906

Someone working manually with a PDF analyzer could tell.

My guess is that it targets Adobe Acrobat since the preponderance of these exploits do so. However, there have been many targeting Foxit, for example in this Wepawet analysis from last year:

​

When a PDF file loaded into a browser window, it calls for the default PDF Reader on the user's system.

When it loaded into my browser window and called for Adobe Acrobat, the file did not execute any code, meaning:

1) if it were an Adobe Acrobat exploit, it didn't work on my version of the Reader

2) it targeted a different PDF Reader

No way to tell at this point.

In any case, disabling plugins prevents the file from loading/executing automatically in these types of drive-by attacks.

----
rich

 

Question for you Rmus.

1.) If you disable javascript in adobe reader can the exploit, or any PDF exploit still run.
2.) If you have the rights for Adobe Reader dropped (LUA, Defensewall, Run Safer, etc) could an exploit still run.

 

OK, two questions.

 

Thanks for that info. Seems to be a lot of .pdf exploits going around these days. I don't use a plugin, and have the browser set to 'ask' and if I open a pdf it's in the sandboxed reader. Also don't have Adobe Reader installed, I'm mostly using Foxit, but tinkering with Nuance.

 

Oooh! Oooh! I got this one!
http://isc.sans.org/diary.html?storyid=5926
There's been at least one Adobe Reader exploit that didn't need Javascript.

 

Thanks Mvario!!! That definately answers the jscript question.

 

I am still using Adobe Reader but have java script and run in browser disabled and any plug ins it uses in Firefox disabled plus I have it's rights dropped via Run Safer in online armor. Might get by unscathed.

 

I don't use those, so I haven't tested.

You can ask Sully about LUA and Run Safer, and ask about Defensewall in the antimalware software forum.

----
rich

 

Spread the word!

----
rich

 

Yes it could.

 

Yes. But, it would be limited in what it can do: no writing to system folders or HKLM registry keys, for example. Basically, the exploit couldn't be used to infect the entire system with some malware - unless it happened to be a privilege escalation exploit.

 

Thanks Guys!

 

In summary, is it sufficient (for now) to observe the following precautions?

1. Don't view .pdf files through the browser plug-in.
2. Disable javascript in your off-line pdf reader if possible.
3. Use a basic pdf reader such as Sumatra.
4. Don't respond to any prompts that appear when a pdf file is opened.
5. View them sandboxed.

 

That is a good summary! Actually, for the drive-by attacks, disabling plugins (your #1) stops the exploit from starting the automatic download. The browser, if configured to prompt, will then display something like:

​

Now, it's up to the users to have a firm policy in place of not downloading/installing/opening anything they didn't go looking for! Similar to your #4.

----
rich

 

Hi All,

For those interested in an alternative way of analyzing .PDF Exploits.
The new JoeDoc.org e-mail service works wonder. Only it does not provide an awful lot of details only the positive or negative discovery of actual exploits...

You simply submit your hostile .pdf sample and you get a result back via email...

The submit address is: submit@joedoc.org

A picture really is worth a thousand word!

 

I don't bother with PDF browser plugins anymore. I do use the latest 4.0 Foxit and always have to untick the browser plugins on install.

 

I came across this but I'm not sure where it fits:

CSI:Internet
Episode 3: PDF time bomb
by Thorsten Holz

While 99.99% of the article whizzed over my head, it may be of use to others, if they still haven't seen it.

 

Hello, vasa1,

Yes, it's a bit technical, and not being a programer, I don't understand a lot of it. Nonetheless, these are interesting and informative analyses, and I look for the jist of how the exploit works, and what the payload is.

To summarize:

1) The PDF document presents more than just a powerful document format. It has its own complete, programming language, including its own propriatory javascript, that involves document creation and manipulation, and is able to perform various execution tasks, such as downloading malware from the internet

2) The important technical information lies in where he shows the code with the URL to download the malware. This is on page 2, about half way down:

• He puts the code in red: this is a Windows function that the vulnerability in the particular Reader permits to execute.
  
  
• He puts the URL in blue

There are some on-line analysis tools that do a similar analysis. Here is an old one:

http://wepawet.iseclab.org/view.php?hash=334a732f5d026b20eb24b860b3723833&type=js

Scroll down to

Name Description

and you will see the vulnerability that is exploited in the Reader. In his article, the author goes through a number of vulnerabilities.

If you scroll down to

Hexadecimal ASCII

you will see the same type of code/url:



This particular code: URLMON.DLL.DownloadToFile is a Windows function that has been used in exploits as far back as the Animated Cursor exploit, 6 or seven years ago. The .ani and .pdf files are just "vehicles" or files that carry the exploit code. Their purpose is to call out to a website to download malware executable files.

At the end of the analysis is a description of the malware file.

Preventative measures against the PDF exploit have already been covered in this thread.

----
rich