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:

1. cmd.exe launched with execution arguments
2. A VB Script was generated using the arguments passed into cmd.exe.
3. The VB Script was executed to reach back into “ownit.pdf” to read out my embedded payload.
4. 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.

Now Adobe claims the following with regards to the /Launch action on their blog entry (“Adobe Reader and Acrobat 9.3.3 and 8.2.3“):

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 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!

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…

First off let me say that writing this post was a very difficult decision for me to make, as I normally try to work with vendors, companies, and organizations to fix issues like this one I am about to disclose without ever really disclosing them to the public, but in this case it just never worked out.  I have tried for the last 18 months to contact just about everyone I could think of at Brainbench to disclose this issue to them, but none of my emails were ever returned.  I utilized their bug reporting “Contact Us” form several times over this time period, but still no one even acknowledged the receipt of my emails or submissions.  I even tried emailing common email addresses such as these: support@brainbench.com, security@brainbench.com, security-alert@brainbench.com, info@brainbench.com, webmaster@brainbench.com, admin@brainbench.com, and postmaster@brainbench.com to name a few, but again no response, well unless you count a few bounced emails for accounts that do not exist.  I have sent them a copy of “Full Disclosure Policy (RFPolicy) v2.0” a few times telling them they had 5 days to contact me before I release this information, but like I said they never return any of my emails.  This to me is just plain ridiculous and irresponsible on their part, as what I am about to provide you all with is information on how their core business objective for providing assessment products is just plain flawed, and cannot be relied on to accurately trust their assessment results.

I have personally been forced to take several of Brainbench’s assessment tests during both the interviewing process and continual certification processes that Brainbench offers for a fee to companies looking to evaluate, assess, and/or validate future and current employee’s skill sets.  Here is a direct quote from Brainbench’s website:

Brainbench, a PreVisor company, has served over 5,000 corporate and 6 million individual customers. The company was founded in January 1998 with the same mission it has today: Delivering easy-to-use assessment products that predict success on the job.

Here are some statistics, again copied directly from their website:

Number of Brainbench customers serviced in the US: Over 4,000

Number of countries where Brainbench has tested people: Over 120

Average Small Business Sale: $6000; 2 week sales cycle

Average Mid-Size Business Sale: $20,000; 4 week sales cycle

Average Large Business Sale: $120,000+, 10 week sales cycle

Brainbench customer renewal rate: 85%

Average renewal contract value: 140%

So as you can see they really appear to take pride in their ability to provide corporations and individuals with assessments that can aid in selecting the right candidate for a position or validate a current employee’s skill set.  This is why I could not comprehend their actions or lack of actions when I attempted to contact them in regards to this issue, which defeats their assessment engines validity.  Well I think I have provided enough background details and such, so lets get to the meat and potatoes of the issue at hand.

JavaScript injection is a simple technique that can be utilized to manipulate client side rendering and code, HTML forms, cookies, and/or  just about any parameter on a web page after it has been rendered by the browser.  To perform this type of attack all that is needed is a web browser and the address/location bar built into all web browsers.  To perform this attack all that is done is the clearing of the address/location bar and entering in JavaScript functions and/or code in it’s place.  A sample alert message can be rendered on any page by clearing the address/location bar and adding in this code:

javascript:alert(“Hello World!”);

JavaScript injections conducted in the address/location bar must always be started off with “javascript:”, but several commands and or code segments can be entered into the address/location bar by ending each one with a “;” to terminate each section and/or segment.  A really nice write up on JavaScript injections with some really cool functions can be found here: “How to Use Javascript Injections“.

It is clear that JavaScript executed in the address/location bar isn’t really a bug or security vulnerability by itself, as it can only be seen on the client side, but it can be utilized to perform some interesting things and/or actions such as web form manipulation and parameter modifications.  This is why no one should ever trust inputs from a client and JavaScript validation by itself is just not enough to secure your data.  Server side validation must occur for every single input received from the client to ensure it is valid and safe to process.

Brainbench’s assessment engine relies solely on a JavaScript function to process a test/assessment takers time spent on each question.  This time is normally restricted to 3 minutes or 180 seconds, which sounds like a pretty nifty feature to ensure test/assessment takers are answering questions based off knowledge.  Given more time a test/assessment taker could easily Google the answer or even reference a book for the correct answer, which sort of defeats the purpose of the assessment.  So let us take a little journey into this JavaScript code utilized by Brainbench’s assessment engine, and see if you can’t spot the issue before you get to me just spelling it out for you.  Here is the function in question:

function TimerFunc()
{
if( !doTimer )
return;

tf = window.setTimeout( “TimerFunc();” , 1000 );
tcount++;
timeLeft = 180 – tcount;
minutes = 0;
seconds = 0;

if( timeLeft > 0 )
{
minutes = Math.round( ( timeLeft / 60 ) – 0.5 );
seconds = timeLeft – 60*minutes;
if( minutes > 0 )
{
document.qform.timerbox.value = minutes + ‘ Min. ‘ + seconds + ‘ Sec. Remaining’;
}
else
{
document.qform.timerbox.value = seconds + ” Seconds Remaining”;
}
}
else
document.qform.timerbox.value = “Time Expired”;
// window.status = timeLeft + ” ” + “Seconds Remaining”;
// document.qform.timerbox.value = timeLeft + ” ” + “Seconds Remaining”;

if( timeLeft == 30 )
{
doWarning();
}

if( timeLeft <= 30 )
{
document.qform.timerbox.className = “timertextboxred”;
}

if( timeLeft <= 25 )
{
doWarningOver();
}

if( timeLeft == 0 )
{
window.clearTimeout( tf );
timeUp = 1;
document.qform.nextitem.disabled=true;
document.qform.submit();
}
}

This function is called by another JavaScript function:

function doOnload()
{
if( resetVals )
{
setem();
}

if( doTimer )
{
tf = window.setTimeout( ‘TimerFunc()’ , 1000 );
}
}

This “doOnload()” JavaScript function is called using the HTML event “onload” when the web page is first loaded with this code:

<body topmargin=”15″ leftmargin=”15″ onload=”doOnload(); ” bgcolor=”#ffffff” marginheight=”15″ marginwidth=”15″>

Now is the issue or vulnerability at hand apparent yet?  I can think of a few ways to defeat this code, but I am only going to demonstrate one very simple and straight forward method for “Stopping” and “Starting” the timer at will.  To stop the timer simply copy and paste the following code into the address/location bar of your browser and hit the “enter” or “return” key while you are taking the assessment/test and the timer will stop:

javascript:void(doTimer=false);doOnload();

To start the timer back up simply change the “false” parameter to “true” and hit “enter” or “return” to execute the code once again.  Like magic the timer will start up again where it left off.

Very simple right?  So what harm does something like this do?  Well your not going to get “root” or “own” Brainbench, but now how valid are these assessments and/or exams?  By stopping the timer at will a test/assessment taker can easily go look up the answer to a question he or she has absolutely no knowledge of, and score a perfect score in areas that the test/assessment taker has no knowledge of.  This completely defeats the validity of the assessment, and now these certifications and/or assessment results can no longer be trusted.  Now if I was an organization reading this article and utilizing these assessments I would immediately contact my sales representative and pose the same question, but hey that is just me.  If I took pride in holding these certifications and paid to take these assessments, I would also call or email Brainbench to pose this question to them as well.  This really hurts and/or questions the overall validity of these assessments and certifications.  Maybe if enough people and/or organizations seek out Brainbench’s response and/or support in regards to this matter it can be fixed quickly.

So how can they fix this?  Simply validate or remove the client side “timer” input variable.  Removing it would ensure the timer variable has no impact on the actual exam time and/or timer.  To validate the timer a server side function and/or timer to compare with could be utilized.  The visual timer makes for a good reference for the test/assessment taker, and should not be removed in my opinion, just don’t trust it to be accurate.  Removing the “doTimer” variable would be a good idea as well, since I really can’t come up with a valid reason for having this functionality or variable.  Just start the timer and let it run, no need to check if the timer should be running when a test/assessment taker is actually taking the exam.  I could be wrong here since I didn’t write the code, but then again I could be right too.

Just as a historical reference since I am optimistic that Brainbench will fix this issue in the near future I have recorded a video demonstrating that this vulnerability really did work, and as of today still works.

As always if anyone has any questions or would like to share their comments feel free to do so, or just send me an email.