Thursday, October 25, 2012

Fuzzing the Iceberg: Finding Vulnerabilities in Third Party Software

The Iceberg
Since 2005, the number of vulnerabilities revealed annually has been generally consistent, between 7,000-9,000 [1]. According to Carnegie Mellon University's CERT/Software Engineering Institute, this number is 'likely an order of magnitude lower' than the total number of vulnerabilities discovered in the wild. Amazingly, based on their expertise in software engineering and experience fuzzing, CERT believes that about 70,000 software vulnerabilities are found each year and simply not reported [2].

Typically, 75% of vulnerabilities can be attributed to third party applications. The other 25% are due to vulnerabilities within Microsoft programs and Operating Systems [3]. The largest of these third party culprits are Adobe and Oracle.  These vendors not only represent a large number of vulnerabilities discovered, but they also represent a stunning number of the critical vulnerabilities revealed each year.

Fuzzing Adobe Reader
With this in mind, we can use the Failure Observation Engine 2 (FOE) by CERT to automatically identify potential vulnerabilities in the Windows based applications. The FOE fuzzer works by taking an input of seedfiles which are manipulated with python scripts. These manipulated seedfiles are then sent as input to an application in hopes of making it crash. Upon detection of a "crasher case", FOE can capture the state of memory and registers. From this information, it can determine whether or not the crash represents an exploitable overflow case. In the basic example below, I'll walk you through the steps I followed to start fuzzing Adobe Reader 11.0.0 for file format vulnerabilities. 

You can download FOE2 from the CERT Website [4]. I recommend installing FOE on a fully patched machine running Windows Vista, 7, or 8 (your preferred target). Also, download the latest version of of the application you'd like to fuzz. In our case below, we can visit Adobe's site to download the latest version of Adobe Reader 11. Once you've got your machine configured with the software you wish to fuzz, FOE2 can be easily configured to launch against your application via its configuration files found in the /configs/ directory. Here we can set our campaign name, control the target application, and make adjustments to how the fuzzer operates. In order to test Adobe Reader, we must change the target application in our configuration file. Otherwise, you'll be testing an application that was installed alongside the FOE application.

foe.yaml
#####################################################################
# Fuzz target options:
#
# program: Path to fuzzing target executable (Adobe Reader below)
# cmdline_template: Used to specify the command-line invocation
# of the target
#####################################################################

target:
    program: C:\Program Files (x86)\Adobe\Reader 11.0\Reader    \AcroRd32.exe
    cmdline_template: $PROGRAM $SEEDFILE NUL

Next, I'll find some seedfiles. There is nothing special about seedfiles, but you'll probably want to have at least one or two legitimate PDF files included in your seedfile directory. The configuration file can also be tuned to manipulate the seedfiles in different ways. It can be useful to play with these features as you execute different campaigns.

Once you've completed the steps above, running foe is as simple as:

C:\FOE2\>foe2.py --c configs\foe.yaml

FOE will feed Adobe Reader random input until you stop it or it breaks the virtual machine.  This process can last for weeks depending on your settings. To view the results, simply browse to the FOE2\results directory. You can view the results while the fuzzer is running. If FOE was successful in crashing Adobe Reader, you'll see a folder in this directory with one of four names. "EXPLOITABLE", "PROBABLY_EXPLOITABLE", "PROBABLE_NOT_EXPLOITABLE", and "UNKNOWN". With any luck, you'll find some exploitable crash scenarios. In the future, I will document more advanced techniques for using FOE and it's robust set of configuration options.

What's next?
Crafting the overflow, controlling EIP, and inserting shellcode. Next week, Juan Miguel Paredes will bring us an Introduction to Buffer Overflows and walk us through this process.

Disclosure 
Cert will accept and work with the vendors whose vulnerabilities are reported through the following form: https://forms.cert.org/VulReport/


References


[1] IBM X-Force 2011 Trend and Risk Report: https://www-935.ibm.com/services/us/iss/xforce/trendreports/

[2] CERT/SEI. How to More Effectively Manage Vulnerabilities and the Attacks that Exploit them: http://www.cert.org/podcast/transcripts/20120925manion-transcript.pdf

[3] Securina Yearly Report 2011: http://secunia.com/company/2011_yearly_report/

[4] FOE Scanner Download: http://www.cert.org/vuls/diDisclosurescovery/foe.html

No comments:

Post a Comment