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.
Yesterday I was configuring my firewall to allow my laptop to talk to a network printer installed on my family’s LAN. You may find that odd, but I tend to segregate my network into several slices such as a lab network, my network, and my family’s network. This ensures the stuff I am analyzing or playing within the lab doesn’t infect and/or affect my network or my family’s network. It also allows me to configure specific monitoring policies for snort, dans guardian, and other network monitoring tools targeted specifically for things like my kids Internet activities. Anyways all that is besides the point, back to the silly printer fun stuff. Once I had the firewall rule in place I utilized netcat to verify my connection over port 9100 to the printer like this: “nc 192.168.1.15 9100″. Not sure why I did it other than sheer curiosity, but I typed “test” into the connection prompt and much to my surprise the printer printed a single page with the word “test” on it. Now this is probably not news for many of you, but it was to me as I didn’t realize that network printers listened on port 9100 for just a RAW data feed. I guess I was expecting the network printer to expect some sort of formated protocol and it can, but the cool thing is it doesn’t have to be. With this new information, to me at least, I immediately started to ponder the EVIL things that could be done with this such as printer Spam. It also kind of reminded me of the nasty black fax DoS concept/trick where you tape a few sheets of black paper together to continuously feed into a fax machine and send it to a recipient with the intention of draining all the toner out of the receiving fax machine. The following image came to mind immediately:
With that thought in mind I initially created a simple Perl script to scan for printers listening on port 9001 and then also send data to any printers discovered. My first iteration of the script allowed for files to be read in and then sent to the printer in either binary format or text format, but then I kind of backed off on releasing that for obvious script kiddie reasons. Could you imagine a skiddie that could easily just read something like /dev/sda or /dev/random into a script to send it to a network printer. Obviously anyone with a little Perl knowledge could add that functionality back in and/or extend the script, but I can sleep well at night knowing I didn’t include it. My silly and simple script only allows you to send a command line passed argument message to the printer, which could be utilized in a nasty manner but it is a little more limiting than just allowing binary data to be piped into the printer listening port. If your interested you can get a copy of the script here: printerScanner.pl. It is nothing real special other than you can use it to scan a network range of printers listening on port 9001 and then if you choose to do so send a simple text based message to the printer to see if it supports RAW input for printing.
After writing this script and the first section of this blog post I did a Google search to see if anyone else had talked and/or had written about this silly network printer scenario and without disappointment I found that Adrian “Irongeek” Crenshaw had a much better write up on this and so much more here: Hacking Network Printers. The funny realization I had in regards to all this is that Adrian documented this 4+ years ago, and I just ran into it yesterday. I have no issues in admitting that I was not aware of this simple RAW input method for network printers, as it confirms my thoughts on situations like this where you can feel as if you have a really good fundamental understanding of a topic area, but there is always room to learn something new or in this case something old. Also after reading through Adrian’s write up I decided to see if I could come up with a Google dork for the Brother network printer I was testing this with on my network and low and behold here it is: inurl:”printer/main.html”. It still shocks me how many times devices like network printers are made available to the public either via a system administrators misconfiguration or a network engineer not taking security into account during his or her implementation with things such as Access Control Lists.
