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.

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:

1. Identify all PDF files that reside on a users computer to identify possible targets that could be used to carry out badness.
2. Secure Adobe Reader 9.0 by applying the Registry settings they recommended earlier this week.
3. 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!



Well I hope you enjoyed the HUMOR!

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.

As an active security researcher and enthusiast I have participated and/or came into contact with numerous security related communities in the past, but I can honestly say that none of them can compare to the open collaboration found at Emerging Threats on a daily basis.  Emerging Threats was founded by Matt Jonkman in early December of 2007 after Matt parted from his previous project Bleeding Edge (BleedingThreats).  Bleeding Edge was also a very successful project, and is where I first came into contact with Matt.  Bleeding Edge, in its day, was the premier place for malware and zero day Snort IDS signatures entirely driven by the contributions of a very active security community.  I am not privileged to the details as to why Matt left Bleeding Edge, but I do remember the shock I felt when he published his announcement to the mailing list on the 16th of November 2007 stating his departure.  I remember thinking that day what a loss for the security community and began to wonder if the project could survive without his participation.  Well long story short Bleeding Edge quickly died with the lack of new snort rule updates being published and the mailing list never receiving any feedback from the new leaders of the project.  It was really a sad few weeks for people like me that depended heavily upon the great snort signatures this community so actively published and made available to us free of charge.  Then I read an announcement from Matt announcing the Emerging Threats project with this post “Emerging Threats Online!!!“.

This announcement marked the start for what I would call one of the best open to everyone security communities online today.  Soon Emerging Threats picked up the support for the Bleeding Edge rules, Replicating the Bleeding Rulesets, and reopened the mailing lists for the community to participate in Matt’s new vision of a completely grant funded project.  Matt’s vision has lead to numerous other projects being hosted and/or sponsored by Emerging Threats.  These projects capture the creativity of some well known security community contributors such as William Metcalf, David Glosser, Victor Julien, James McQuaid, and many others.  I would definitely recommend anyone reading this post to take a serious look at these projects, as they are always looking for help and input to make them better.  Another great source for information regarding Emerging Threats snort rules and projects is the wiki, which houses a collaborative environment in which anyone that chooses to do so can provide comments and feedback regarding individual snort rules.

The Emerging Threats mailing lists are always active and some of the best community contributing snort signature writers out there participate on a daily basis.  This mailing list is not like several other mailing lists out there where a “n00b” (newbie) has to fear of being flamed by the guru’s on the list.  Instead beginners questions are answered in a professional and helpful manner providing for a very open and friendly collaborative environment.  I have seen situations arise from time to time where someone or some company representative has posted negative remarks regarding certain rulesets and/or specific signatures, but all of these situations were handled with professionalism.  Many times the answers to these complaints contain apologies and responsive corrections to errors or mishaps in a very short time frame.  Other times these posts are answered with requests for suggestions from the poster and community on how they can be corrected.  You really can’t ask for more than that from a project that is offering it’s services free of charge for all of us to benefit from where we see fit.  Warning the following is a rant so skip to the next paragraph if you don’t like to read rants!  I have had the pleasure of working for a very large organization for the last few years and during this time I have also had the pleasure of evaluating and demoing a wide range of IDS/IPS commercial solutions and/or products.  During these evaluations and demos I have heard from several sales guys, and their sales engineers that the Emerging Threats rulesets are terrible and how their in house developed rulesets do a better job of protecting you from malicious code and zero day attacks.  Now being a contributing community member of Emerging Threats this really hits me in the gut, so of course I begin to dive into these so called optimized and efficient rulesets and I bet you can guess what I find.  I find snort rules written with PCRE’s that contain no content anchor, Domain Name content matches, and in some cases reused Emerging Threat rules with a new message of course.  Now, this is not the case for all vendors or commercial products for which I have had the pleasure of evaluating or coming in to contact with, so don’t take this the wrong way.  I just hate hearing how terrible something is when in fact the Emerging Threats rulesets contain some of the best signatures for malicious code and zero day attacks available to the public.  Just a suggestion to any vendor, company, sales guy, and/or sales engineer in the business please stop spreading this non-sense, as it only discredits your professionalism and makes me question your knowledge in the area of IDS/IPS technology.  Ok, the rant has ended!

Matt’s successful leadership, persistence, and expert guidance over his vision at Emerging Threats has also lead to him starting another project that appears to be kicking off with a great start with the help of government sponsorship and funding “Open Information Security Foundation” (OISF).  According to the FAQ’s at OISF: “The OISF was formed primarily to begin the development of this new IDS/IPS engine, but will over time take on new projects and challenges. The OISF can be a home to any interested project in need of funding and long term support” (What is OISF?).  This project really appears to have the beginnings and community participation to reshape what we consider an IDS/IPS engine to be with numerous creative and innovative visions contributed by the community: “Proposed Features for the Engine and the OISF Wiki“.  I would recommend anyone reading this post with an interest in IDS/IPS technology to sign up and participate in this project, as they too just like Emerging Threats are always looking for help and/or feedback that will make the project better.

I would like to personally extend a “THANK YOU” out to Matt and the members of the Emerging Threats community.  Matt, if we are ever in the same place at the same time I owe you a beer!  Thanks again for the hard work, and I wish you and your projects nothing but success.