View Full Version : Is ESET able to pick-up on this PDF exploit?
Geosoft
April 6th, 2010, 11:32 AM
I know there is a rule about posting links on this forum, but I would like to know if ESET is able to protect us from this type of PDF Exploit. Information could be found here: http://www.sudosecure.net/archives/636
There seems to be a way to craft a PDF document to infect other clean PDF documents on the system to contain the exploit code within the PDF.
Feel free to modify the link. :)
-- EDIT
A more step by step details on the attack can be found here, with a sample PDF you can download to see what happens on your PC: http://blog.didierstevens.com/2010/03/29/escape-from-pdf/
I'm already seeing the return of the Word Macro virus, but now in PDF format! :o
siljaline
April 6th, 2010, 12:16 PM
See this thread (http://www.wilderssecurity.com/showthread.php?t=268866) regarding document protection.
Articles regarding PDF exploits:
http://www.theregister.co.uk/2010/04/06/wormable_pdfs/
http://www.theregister.co.uk/2010/03/31/pdf_insecurity/
The onus is on the user to protect themselves accordingly when opening questionable PDF files, to the best of my knowledge,
protection of whatever payload within said file would be detected, removed and or quarantined.
* Adobe is planning on releasing out-of-band patches for Adobe Reader and Adobe Acrobat, info on this here (http://blogs.adobe.com/adobereader/2010/04/upcoming_adobe_reader_and_acro.html)
Note that: these will be released the same day as Microsoft patch Tuesday, next Tuesday, it would be most prudent to apply the MS patches first, then attempt the Adobe patches.
Geosoft
April 7th, 2010, 09:37 AM
The good news is that ESET made a discussion on it! Good read: http://www.eset.com/blog/2010/04/06/pdfs-exploitable-im-shocked
Geosoft
April 7th, 2010, 10:05 AM
Yikes, Didier's new blog post is a little scary to read. http://blog.didierstevens.com/2009/10/05/preventing-applications-from-starting-malicious-applications/ Check out his EICAR PDF Document test.
siljaline
April 7th, 2010, 11:56 AM
Interested read and thanks for posting this, I will flag one of the Exploit Analysts on the Forum for his information.
-{ Quote: "The good news is that ESET made a discussion on it! Good read: http://www.eset.com/blog/2010/04/06/pdfs-exploitable-im-shocked" }-
stackz
April 7th, 2010, 12:26 PM
Adobe have released an official workaround for the exploit - read here (http://www.h-online.com/security/news/item/Adobe-issues-official-workaround-for-PDF-vulnerability-971932.html).
Foxit Reader have already updated to address the vulnerability.
siljaline
April 7th, 2010, 01:15 PM
Thanks for this, although the link you posted points to here (http://blogs.adobe.com/adobereader/2010/04/didier_stevens_launch_function.html) Note to readers that this advises of a Registry tweak to compensate for this vulnerability, unless you are entirely comfortable editing your Registry, do not.
-{ Quote: "Adobe have released an official workaround for the exploit - read here (http://www.h-online.com/security/news/item/Adobe-issues-official-workaround-for-PDF-vulnerability-971932.html).
Foxit Reader have already updated to address the vulnerability." }-
Rmus
April 7th, 2010, 03:25 PM
siljaline sent me the link to this thread, where I found the ESET blog.
From the ESET Blog:
http://www.eset.com/blog/2010/04/06/pdfs-exploitable-im-shocked
-{ Quote: "How the exploit works:
According to the researcher Didier Stevens, the exploit is really very simple: it uses the /launch /action to execute any arbitrary .exe file embedded into the PDF." }-Since this current PoC requires user action to OK a prompt, this attack falls into the 'Social Engineering' Attack Vector Category, and users will deal with such according to their own policies/procedures.
Embedding an executable in a PDF file is not new, although exploits in the wild have used a vulnerability in the Reader to bypass any prompt, putting this attack into the 'Remote Code Execution' category:
Sophisticated, targeted malicious PDF documents exploiting CVE-2009-4324
http://isc.sans.org/diary.html?storyid=7867
2010-01-04
-{ Quote: "the PDF document carries two embedded binaries!...the PDF document contains everything it needs to fully exploit the victim's machine - it does not have to download anything off the net." }-Which do readers think is the easier exploit to prevent: the social engineering one with a prompt, or the remote code execution one exploiting a vulnerability?
While the Band-Aid approach (reactive) to security vulnerabilities, where you patch/update vulnerable applications, is the usual remedy, Users with a robust security strategy will have protection in place (proactive) to take care of the malicious executable payloads. I'm not sure about your ESET product, but testing it against a PoC with a trusted executable (calc.exe) may not be the best test against what an exploit in the wild would do.
In the current case, a PoC, it's probably just a matter of time before the exploit becomes a part of cybercriminals' exploit kits, in which case it will do more than just launch the calculator!
The PDF file with embedded malware executable launched by remote code execution would not work with my old version of the Acrobat Reader. However, I did find awhile back a MSOffice document - an RTF file with embedded malware as a Package Object. It did require the user to OK a prompt, and while we might think we would never do such a thing, depending on the situation, we might be fooled. I had several people test this with different security products that blocked unauthorized executables from launching, and it showed us that no matter the triggering mechanism: vulnerability in a browser; plug-in; or any application (Adobe, Quicktime, MP3 file, etc), the malware executable payload is easily caught:
216954
While the current mainstream articles brand this PDF thing as a big Security hole, it's really no more such a hole than that in HTML code. If you remember when HTML mail started, it was easily demonstrated how executable code could run just by previewing an HTML message in Outlook Express. I didn't notice any call for eliminating HTML emails. How do readers here deal with such possible malicious exploitation of HTML code in emails?
Go back even further: the Command Interpreter (cmd.exe) will execute commands such as "Format" in a batch file.
So, you receive an email with an attachment: your_pictures.bat with malicious commands inside. Is this big security hole? Is this any different than receiving a booby-trapped PDF file? or WMF file in 2005? Or VBS file back with the Love.vbs worm?
I don't remember anyone clamoring for removing the .bat extension, or the Windows Script Host from the operating system. Yet Adobe takes a lot of heat because it's so widely used, but certainly no more vulnerable or feature-packed than many other applications.
What about autorun.inf files, which can execute commands to launch executable files, as Conficker.B did? Well, I and others have known about the dangers of autorun.inf since Win9x Days and infected floppy disks. It's either a feature, or a security hole, depending on your point of view, and you use/protect accordingly.
I and others like and use the autorun.inf "feature," for example, placing one on my external USB drive which, when connecting the drive, will add useful commands to the right context menu. Again, this is either a documented feature or security hole, depending on your point of view. That it -- like the Command Interpreter, HTML code, and PDF code can be used for malicious purposes -- is no reflection on the benign uses of these actions.
And we won't take the time to deal with javascript!
There will continue to be exploitation against any type of code in our many applications. New ones are just waiting to be discovered by those with nothing better to do than sit for hours, poring over every line of code, looking for inroads to exploitation.
While applying Band-Aids will always be recommended, savvy users will have protection in place to deal with these types of exploits, especially in those cases where a patch or signature is not yet available - the so-called 0-day exploit. That, coupled with firm policies and procedures about unknown files of any type.
What about the not-so-savvy user - Mr. and Mrs. Smith next door? I've advocated for years that all of us in the forums who keep up with these things, "adopt" a user and help her/him set up with secure protection. They certainly aren't going to get much help from articles with graphic headlines. such as "PDF security hole opens can of worms," which will just serve nothing more than to invoke fear.
regards,
-rich
pondlife152
April 7th, 2010, 03:30 PM
-{ Quote: "Note to readers that this advises of a Registry tweak to compensate for this vulnerability, unless you are entirely comfortable editing your Registry, do not." }-
Actually, the reqistry tweak is not needed for the majority of standard users who can simply change the settings in Preferences. It is the same for both Reader and Acrobat.
Geosoft
April 7th, 2010, 03:57 PM
Hey Rich,
FYI, there was actually a problem with "FoxIT" reader where there was NO prompt for running executables within the PDF itself, until they recently fixed tihs this.
The reason real question is if ESET can scan the document for known security threats before it can reach the reader. Proof in point was the link EICAR PDF File. ESET was not able to detect the threat until the code was executed from the PDF (granted I had to press OK within Adobe Reader to run) but still.
--edit for spelling
I really need to proofread my work after 3pm! :/
Rmus
April 7th, 2010, 04:46 PM
-{ Quote: "Hey Rich,
FYI, there was actually a problem with "FoxIT" reader where there was NO prompt for running executables within the PDF itself, until they recently fixed tihs this. " }-Yes, I'm aware of this, but since it was fixed yesterday, those with the updated Reader would receive such an exploit as a 'social engineering' one.
-{ Quote: "The reason real question is if ESET can scan the document for known security threats before it can reach the reader." }-What do you do about unknown security threats? There have been many labelled '0day' against Adobe in the past.
----
rich
vBulletin® Copyright ©2000-2012, Jelsoft Enterprises Ltd.
Copyright ©2002 - 2012, Wilders Security Forums