PDF exploit loads via i-frame

Discussion in 'malware problems & news' started by Rmus, Mar 14, 2010.

Thread Status:
Not open for further replies.
  1. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,943
    Location:
    California
    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:

    4ura_pdf.gif

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

    4ura_pdf2.gif

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


    ----
    rich
     
  2. mvario

    mvario Registered Member

    Joined:
    Sep 16, 2008
    Posts:
    339
    Location:
    Haddonfield, IL
    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?
     
  3. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,943
    Location:
    California
    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:

    [​IMG]

    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
     
  4. Threedog

    Threedog Registered Member

    Joined:
    Mar 20, 2005
    Posts:
    1,125
    Location:
    Nova Scotia, Canada
    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.
     
  5. Threedog

    Threedog Registered Member

    Joined:
    Mar 20, 2005
    Posts:
    1,125
    Location:
    Nova Scotia, Canada
    OK, two questions.:D
     
  6. mvario

    mvario Registered Member

    Joined:
    Sep 16, 2008
    Posts:
    339
    Location:
    Haddonfield, IL
    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.
     
  7. mvario

    mvario Registered Member

    Joined:
    Sep 16, 2008
    Posts:
    339
    Location:
    Haddonfield, IL
    Oooh! Oooh! :argh: 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.
     
  8. Threedog

    Threedog Registered Member

    Joined:
    Mar 20, 2005
    Posts:
    1,125
    Location:
    Nova Scotia, Canada
    Thanks Mvario!!! That definately answers the jscript question.
     
  9. Threedog

    Threedog Registered Member

    Joined:
    Mar 20, 2005
    Posts:
    1,125
    Location:
    Nova Scotia, Canada
    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.
     
  10. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,943
    Location:
    California
    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
     
  11. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,943
    Location:
    California
    Spread the word!

    ----
    rich
     
  12. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    Yes it could.
     
  13. Windchild

    Windchild Registered Member

    Joined:
    Jun 16, 2009
    Posts:
    571
    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.
     
  14. Threedog

    Threedog Registered Member

    Joined:
    Mar 20, 2005
    Posts:
    1,125
    Location:
    Nova Scotia, Canada
    Thanks Guys!
     
  15. vasa1

    vasa1 Registered Member

    Joined:
    May 1, 2010
    Posts:
    4,152
    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.
     
  16. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,943
    Location:
    California
    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:

    ff-pdfPrompt.gif

    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
     
  17. Hermescomputers

    Hermescomputers Registered Member

    Joined:
    Jan 9, 2006
    Posts:
    1,069
    Location:
    Toronto, Ontario, Canada, eh?
    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! :D
     

    Attached Files:

  18. funkydude

    funkydude Registered Member

    Joined:
    Apr 5, 2004
    Posts:
    6,852
    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.
     
  19. vasa1

    vasa1 Registered Member

    Joined:
    May 1, 2010
    Posts:
    4,152
    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.
     
  20. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    3,943
    Location:
    California
    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

    pdf-urlmon-1.gif

    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:

    pdf-urlmon-2.gif

    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
     
Loading...
Thread Status:
Not open for further replies.