It has been a few months since I posted anything here but tonight as I was fiddling around with the Launch action within a PDF file I discovered another oddity that I thought would make an interesting blog posting. As we are all probably aware of the Launch action within the PDF specification allows for arbitrary files to be opened and/or executed in Adobe reader versions prior to version 9.3.3 with very little restrictions. Adobe attempted to apply some basic blacklisting restrictions to prevent the Launch action from executing these arbitrary executables in version 9.3.3, but this attempt was poorly implemented as the blacklist was easily escaped by simply adding double quotes. Needless to say Adobe quickly corrected this with the release of Adobe reader version 9.4. So what was the oddity I discovered in a fully patched Adobe reader version 9.4 release that may be of interest?
What I discovered is that the PDF Launch action specification allows for any PDF file accessible by the end user to be printed to the default printer and Adobe reader implements this specification without properly disclosing that a print action is being carried out. What I mean by not properly disclosing that a print action is being carried out is that a warning dialog box is presented to the end user, but the message within the this dialog box provides no indication that the PDF file is being printed. The following screen capture is what is displayed to the end user prior to the Launch action being executed to print a PDF file:
As you can see no where within the warning dialog box is the name of the PDF file being accessed displayed to the end user nor is there any indication that a PDF file is being submitted as a print job to the end users default printer. The warning dialog box in my opinion is very misleading to say the least, as it would appear that we are attempting to open the AcroRD32.exe file which is the Adobe reader executable. Once the Open button is clicked the PDF file referenced by the Launch action is printed to the end users default printer.
Now this is definitely not as serious of an issue as the previous Launch action issues that allowed malicious actors to carry out attacks that would allow for the execution of arbitrary executables, which is why I titled this post an “Oddity”. Although I can think of a scenario where this oddity could be used to carry out an information disclosure attack. Since the Launch action will allow you to specify any PDF file accessible to the end user to be printed it would be possible to send a crafted PDF file to someone to gain access to other PDF files that you may not have access to. Take for instance, lets say we know our boss keeps all of the annual performance reviews on a network share drive that only he has access to and that we all share a common network printer in the office. We could easily craft a PDF file that printed all of these PDF files to our network printer without him knowing it for us to then just swoop by the network printer to pick up. Basically all we need to know is the path and the file name to carry this attack out. The second style of attack I could think of utilizing this oddity is more of an announce than a security issue. We could easily craft a PDF file with say 1,000 solid black pages which when opened by the end user would drain the default printer of all it’s ink or toner. This kind of attack sort of reminds me of the old black fax attack.
If your curious to the syntax feel free to download this PDF file “print.pdf” which when opened in Adobe reader on Windows will print itself to your default printer. One thing to note about the Launch action and printing is that we do not get to specify what printer the document is printed to and it is automatically sent to the end users default printer. If your curious to what the syntax would look like to print one PDF file from another download these and save these two PDF files in the same directory: “print_test.pdf” and “test.pdf“. Opening the “print_test.pdf” file will print the “test.pdf” file to the end users default printer.
Earlier this week Adobe released security updates and patches to resolve several security vulnerabilities, but after some manipulation of my original POC found here: “Are PDF’s Worm-able” I have found that the /Launch misuse attack can still be carried out. The following video demonstrates this attack being carried out on a fully patched Adobe Reader version 9.3.3.
As you can see in the video Adobe has successfully prevented me from manipulating the warning dialog box that pops up and warns users that the PDF is attempting to launch an external application, but it still fails to capture the entire command. In the demonstration the warning dialog box reported I was attempting to launch “c:\windows\system32\cmd.exe”, but failed to report the full activity of my command. Launching cmd.exe is bad in itself, but to carry out my attack the following unreported or undisclosed actions were carried out without any indication within the warning dialog box:
cmd.exe launched with execution arguments
A VB Script was generated using the arguments passed into cmd.exe.
The VB Script was executed to reach back into “ownit.pdf” to read out my embedded payload.
The VB Script then performed an Incremental Update to the “empty.pdf” file, which was carried out with full compliance of the PDF Specification 7.5.6 titled “Incremental Updates”.
The warning dialog box also did not disclose the full actions being carried out within the updated “empty.pdf” file after it was attacked via an incremental update. The launching action to shoot the user over to my blog within Firefox was never disclosed within the warning dialog box. With that I would say the security patch to stop an attacker from manipulating the warning dialog box text was somewhat successful and should disclose to a user not only the file and/or command being executed but also report any arguments being passed to the command.
Today’s update includes changes to resolve the misuse of this command. We added functionality to block any attempts to launch an executable or other harmful objects by default.
This claim is semi-true in that I have found that only executables in the windows system path are capable of being launched, but it does not block any attempt to launch an executable or other harmful objects by default. If I can launch “cmd.exe” and pass it parameters then by default I can launch any executable on the system and even do so much more. With that I would not follow Adobe’s recommendation to re-enable the Launch functionality within Adobe Reader if your organization depends upon this functionality, as in my mind it is still not safe to do so. It may be a little safer, but by no means is it completely safe. Attackers can still misuse the Launch action to carry out all sorts of malicious activities.
The real danger with the /Launch escape from PDF proof of concept that Didier Stevens published is no longer a mystery to the malicious malware developers out there, as a recent sample I acquired doesn’t rely on JavaScript and embeds the executable as a PDF comment. Within this PDF comment is a simple vbscript that encodes the executable as an ANSI character code array which is latter extracted from the PDF file, converted to binary form, written to the user’s computer as “game.exe” and executed. How I found this was just by pure luck as I stumbled across this blog posting here: /Launch Malicious PDF. The blog posting goes into most of the details, so no use reiterating them here. One thing I would like to point out is that this is very different from the Zeus attempt at utilizing the /Launch action. Zeus appeared to have utilized the Metasploit PDF module which doesn’t really take full advantage of the /Launch action, so I don’t count that as the first real escape from PDF malicious usage.
The good folks over at M86 Security Labs is reporting the first instance of the Zeus data stealing bot taking advantage of the PDF Launch action. You can read the full blog posting here: PDF ‘Launch’ Feature Used to Install Zeus. The malicious actors involved with this instance appear to only have a very small grasp of the capabilities surrounding the Launch action, as this attempt at utilizing the Launch action to carry out badness is very rudimentary. The malicious actors require the targeted user to click through two different warnings dialog boxes and do not take advantage of controlling the second warning dialog box text at all. There intentions are clearly shown in the Launch dialog box as shown in the screen shot:
They also do not take advantage of being able to extract the executable with some crafty scripting to avoid having to use the JavaScript exportDataObject function. This means the malicious code writers delivering this nasty PDF file have not figured out how to get around the requirement to use JavaScript, so by just turning off JavaScript in your PDF reader you will be safe. This is why I would classify this attack attempt as rudimentary at best, with little to no real sophistication. If this was the best the malicious actors have to offer we would have nothing to worry about, but I am afraid this is only the beginning and I am sure we will see far more sophisticated attempts at exploiting the Launch action in the future.
In regards to the vast functionality of the PDF specification I would not only recommend security professionals to look over the PDF specification document that has been referenced all over the Internet these last few weeks “PDF 1.7 Specification“, but also to look over the “JavaScript for Acrobat API Reference” for a better understanding of what is possible and what is to come. If you don’t care for Adobe’s live document viewer you can down load the older version here: JavaScript for Acrobat API Reference, Version 8. One thing to note is that although the PDF specification documentation is very thorough the JavaScript for Acrobat API Reference manual is not. To prove this take a look at this vulnerability CVE 2007-5659 or for a little more details on the vulnerability specific function look here: OSVDB 41495. So the JavaScript function in question is called Collab.collectEmailInfo(), and my challenge for you is simple. Find this Method in the JavaScript for Acrobat API Reference manuals. Bet you can’t find it! Pablo Sole from Immunity claims there are actually 48 members of the Collab JavaScript method all of which only 3 are documented in this presentation: ID_reCON_2008.pdf. Apparently Pablo used the Immunity Debugger to fuzz this method and published his findings. Another interesting thing to note here is that Pablo published this in 2008 and these 45 undocumented members still appear to be undocumented.
We all knew it was coming, so I doubt anyone is going to be shocked to learn that SophosLabs is reporting they have now seen the first instance of a malicious PDF file utilizing the Launch action. Paul from SophosLabs did a short blog posting found here: Troj/PDFEx-DF: SophosLabs sees malware exploiting /Launch. Now my only question concerning this instance is whether or not the malicious PDF file contained the logic or feature set to perform incremental updates on other PDF files. Adobe will be releasing their official patch for the Launch action tomorrow, but from all that I can tell it will not address the incremental update issue at all.
The most common question I have received this week is are there any legitimate use cases for the /Launch action within the PDF specification. With that in mind I sat back for about 15 minutes today and gave this some serious thought, which resulted in the following three legitimate use cases:
Identify all PDF files that reside on a users computer to identify possible targets that could be used to carry out badness.
Secure Adobe Reader 9.0 by applying the Registry settings they recommended earlier this week.
Secure my “idiot” users computers that would fall for this /Launch attack by uninstalling Adobe Reader if they click through the WARNING MESSAGE.
So as you can tell there is a little sarcasm or humor in this post, but there is also some seriousness for use cases 2 and 3. Use case 1 really is just my way of showing everyone that identifying PDF files on your hard drive is really not all that hard and can be done fairly easy. This relates back to extending my proof of concept where I only attacked a single PDF file. If this video doesn’t clarify how simple it would be to inventory your system for PDF files, well I don’t know what will.
Use case 2 could be considered a configuration management use case. I mean who would have ever thought that a PDF rendering application could replace those expensive desktop configuration management solutions? Oh and it’s free!
This last use case is my favorite and I can see real potential for this one. How can you make sure you are completely secured from all Adobe Reader attacks, well just uninstall it. How can you make sure that only the “idiot” users that would ignore WARNINGS don’t get PWND in the future? If we sent this PDF to all of our users in our enterprise environment we can ensure only the “idiots” are secured by unistalling their PDF reader, and still allow our more responsible users to enjoy Adobe Reader. What a deal!
Just a few minutes ago I learned via a comment submitted on my “Are PDFs Worm-Able?” posting that another proof of concept was created performing the same style of attack. Have a look for yourself:
As you can see YunSoul demonstrates this attack can be conducted on multiple PDF files, just as I claimed. I provided no help and/or guidance to YunSoul and this was the first interaction I had with him, so it clearly demonstrates how easy this attack is to pull off and how likely it is that we will soon see malicious code writers taking advantage of this creative use of the PDF specification. YunSoul also has a blog posting regarding his proof of concept here: PDF. I couldn’t get google translate to translate the blog posting, so I don’t know what the specifics are. If I have time I will try to read it later with another translator service.
Another point I would like to make is that these hacks do not require the Launch action to work, as any application or program that has write access permissions could be utilized to perform the misuse of the incremental update feature in a PDF. The reason I chose to use the Launch action is I figured it was a nice compliment to Didier’s original proof of concept. I wrote a little more about another use case that could utilize the incremental update feature in a malicious way here: Clarifying and Dealing with the Recent PDF Hackery.
I have received several email questions and explanation requests regarding my blog post “Are PDFs Worm-Able” and the proof of concept video within the post. Instead of repeating a post I wrote over on my company’s blog I figured I would just link to it from here: Implications of Recent PDF /Launch Hacks. In the linked blog post I describe some of the implications of this style of hack and I also walk through a scenario in which a variation of my proof of concept is utilized to infect all PDFs found on a users system. I don’t think my proof of concept was as clear as I would have liked it to be. Within the proof of concept I infected a single benign PDF file from another PDF file, but this proof of concept could easily be modified to recursively traverse a users computer directories to find and infect all PDF files on that users computer and/or accessible to that user at the time of execution with any payload of my choosing. I chose to infect the benign PDF with another /Launch hack that redirected a user to my website, but this could have just as easily been an exploit pack and or embedded Trojan binary. Worse yet this dynamic infection vector could be utilized to populate all PDFs for some new O-day attack, thereby multiplying an attackers infection vehicles while still exploiting user systems (“worm-able”). This should really make you think twice even before you open up PDF files that have resided on your computer for years, as they could soon be the utilized against you if an attacker chose to do so. Now I have never seen this style of attack carried out and in the past I have preached that PDF files could be utilized in an attack like this but until now it always required the usage of an external script and/or binary that possessed the capabilities for updating PDF files on the fly. The cool thing about Didier’s hack is it brought to light for me a way to perform this attack without having to utilize anything outside the PDF file and without having to exploit the PDF application itself. Now if this clarification doesn’t scare you I don’t know what will, as it scares the hell out of me. I am an avid Linux user and tend to use “okular” for reading PDF files, which doesn’t support all the features many main stream PDF rendering applications like Acrobat Reader and Foxit, so I am not to worried with regards to my own systems, but in an enterprise environment this style of attack could spell real disaster. What I would really like to see as a solution is a minimalistic version of the main stream PDF rendering applications that do not support all these robust feature sets made available to the public. This would really help out those of us who tend to only use PDFs for reading documents and don’t require the ability to launch applications, play media files, dynamically fill-out forms, and/or utilize all the other robust features on a daily basis. Just a thought.
Yesterday I posted about a thought I had that expanded upon Didier Steven’s Escape From PDF built in feature discovery where he executed a embedded executable binary using some crafty hacking. My thought was that it may very well be possible to launch an attack internally from one PDF onto another already existing PDF. I emailed Didier with my idea and some of the specifics, and he said it was definitely possible. So I decided to try my luck at creating a proof of concept and created this video to demonstrate it:
Before you ask, no I will not be disclosing the internal code that makes this possible nor will I be sharing out the PDFs within the proof of concept to the general public. Didier has already informed all of the relevant vendors about this issue and my proof of concept is just an expansion of his work, so there is no need for me to beat the vendors up with the same issue. If the vendors figure out a method to prevent Didier’s example this same fix will stop this proof of concept as well. With all that being said I look forward to receiving your comments and feedback and I hope you enjoyed the video. Oh and no this is not an APRILS FOOLS JOKE…
If you haven’t heard yet Didier Steven’s has made public a feature he discovered within the standard PDF document language that allows a specially crafted PDF file to execute programs and/or open files without utilizing JavaScript. This feature really isn’t new as it is documented in the specifications of a PDF document found here: PDF 1.7 Specification. Just search for “Launch Actions” within the PDF document or turn to page 422 to find the section titled “12.6.4.5 Launch Actions”, everything you need to know about launching applications from within a PDF can be found here. Also Security-Labs.org created origami in PDF which is a Ruby framework designed to parse, analyze, and forge PDF documents. The interesting part of origami is they provide a sample called “calc.pdf” that demonstrates a PDF file that can open applications in not only Window’s but in Linux and also in Mac’s with Adobe Acrobat Reader. If you want to tweak the sample PDF file just follow the example code in “calc.rb” file and tweak away.
So what is so new, special, and innovative about Didier’s discovery and proof of concept? Well he has crafted a PDF document that takes advantage of the Launch action to execute an embedded executable from within the PDF file, which has yet to be done by anyone else as far as I know. The really cool thing about this is that by default the Launch action can not execute an embedded executable within a PDF file, but Didier has found a way to do it. I think I have a pretty good idea how he has done it, and sent him an email which expands upon his craftiness to possibly turn the PDF document format into a worm-able document format without using any JavaScript or an external binary. Here is a hint, think Incremental Updates. I haven’t created a proof of concept yet, but I did share my idea with him and look forward to getting his feedback on my thoughts. I don’t know if it is entirely possible either, but I think my logic is sound which is why I thought it would be a good idea to bounce the concept off of him. His craftiness is far superior to mine.
Anyways to join in on the fun I spent a few minutes modifying Didier’s cmd.exe proof of concept to launch Firefox in Windows and passed it my URL, so if you open this PDF file: “win_sudosecure.pdf” within Windows under Foxit or Acrobat Reader and have Firefox installed you should get sent to my website. Of course if your using Acrobat Reader you have to click through the pop up. So why would I demonstrate that you can pass arguments to the Launch action that opens a URL? Well I can think of some really nasty phishing attacks this style of attack could be utilized for. Just think if you landed on one of the oh so common web exploit packs or if the PDF was crafted to look like an official banking document that provided instructions to verify your information by entering it into the targeted URL. Hmm since arguments can be passed here is another thought. The PDF document itself could be an official looking banking document with a form embedded that allowed a user to fill out his or her information within the PDF document itself. At the bottom of the form a submit button calling the Launch action to execute Firefox or Internet Explorer while passing the information via URL arguments to an attackers happy to receive, parse, and store server. Obviously the attacker should post an official thank you from the URL for your submission to really dig the knife in. Not a pretty picture and I could see this style of attack being pretty effective since we all know users have a tendency to fall this sort of stuff.
I also modified the origami “calc.rb” Ruby script to create a PDF that when opened in Linux with Acrobat Reader it will launch Firefox. Now for this PDF to work Firefox has to be installed in “/usr/bin/firefox”. The interesting thing about attempting to do this in Linux was I could not pass arguments to the Launch command, so it is not as effective as the Windows version. Darn not as easy to phish those pesky Linux users, oh well. If you want to test it just open this PDF: “linux_firefox.pdf” within Linux. When I first started playing with this Linux version I thought of some really nasty things you could possibly do by passing the sudo command arguments/parameters, but again as I stated earlier I was quickly disappointed when it didn’t work. Oh well, better luck next time.
