Writing Exploits with the Elderwood Kit (Part 1)

Dan Guido
attacks, exploits

In the second part of our three-part series, we investigate the tools provided by the Elderwood kit for developing exploits from discovered vulnerabilities.

Several mitigations must be avoided or bypassed in order to exploit browser vulnerabilities, even on platforms as old as Windows XP. Elderwood provides tools to overcome these obstacles with little to no knowledge required of their underlying implementation. Historical use of the Elderwood kit for browser exploits has been focused on use-after-free vulnerabilities in Internet Explorer. Exploitation of use-after-free vulnerabilities is well documented and systematic and a quick search reveals several detailed walkthroughs. Exploits of this type have three primary obstacles to overcome:

  • Heap spray technique
  • DEP bypass
  • ASLR bypass

Each component of the kit abstracts a method for overcoming these obstacles in straightforward way. We examine how these components work, their reliability, technical sophistication, and describe how these components are exposed to the kit user. Supported targets and reliability of exploit code are directly tied to the design and implementation decisions of these components.

Heap Spray and DEP Bypass (today.swf)

Data Execution Prevention (DEP) prevents memory from being implicitly executable. Exploits commonly create a payload in memory as data and then try to execute it. When DEP is enabled, the attacker must have their payload explicitly marked executable. In order to bypass this protection, an exploit can take advantage of code that is already in memory and is marked executable. Many exploits chain together calls to functions to mark their payload executable in a practice sometimes referred to as return-oriented programming (ROP). Internet Explorer 8 on Windows XP and later takes advantage of DEP and this mitigation must be bypassed to successfully execute code.

Today.swf performs the DEP bypass for the user. This Flash document sets up many ROP chains in memory so that one will be at a known location (heap spraying). When Internet Explorer is exploited, the ROP chain performs pivots the stack to one of the fake stacks instead of the legitimate one. After the stack pivot, the ROP chain executes a sequence of instructions to make an executable copy of the deobfuscation code that turns xsainfo.jpg into a DLL, and executes it. This can be done from within Flash, a plugin, because it shares the same memory space as the browser rendering process, unlike Chrome and Safari and Firefox.

The SWF is included before the JavaScript exploit code is loaded. When the swf is loaded, the heap spraying code is run automatically. The user does not need to know about the details of the technique that it uses. The end result is that the heap is full of the stack frames and the kit user can assume that proper values will be at a specific address, 0x10ab0d0c. This means that the user only needs to know the single value of where to jump to.

window.location = unescape("%u0d0c%u10abhttps://www.google.com/settings/account");

For readers following along with our analysis, the software used to obfuscate the Flash component of the exploit is conveniently located on the first page of Google results for “SWF Encryption.” DoSWF is the first result that does not require an email address to download the installer and, as an added bonus, is developed by a Chinese company from Beijing.

As seen with many public exploits, it’s possible to perform this same task with only the JavaScript engine within the browser. This would remove the dependency on a third party plugin. Instead, this exploit will only work on browsers that have Flash installed and enabled. Techniques and libraries to perform precise heap manipulation in JavaScript are well-documented and have existed since at least 2007.

ASLR Bypass (Microsoft Office and Java 6)

Address Space Layout Randomization (ASLR) is an exploit mitigation present on Windows Vista and newer that randomizes the location of code in memory. ASLR frustrates an attacker’s ability to control program flow by making the location of code used for ROP gadgets unknown for reuse. The easiest possible method to bypass ASLR is to avoid it entirely by locating a module that is not compiled with the Dynamic Base flag, indicating a lack of support for this feature. This makes exploitation significantly easier and eliminates the advantage conferred by this mitigation entirely. Once such a module is loaded at fixed virtual address, the attacker can repurpose known instruction sequences within it as if ASLR did not exist.

In order to bypass ASLR, the kit comes with code to load several modules that are not compiled with the Dynamic Base flag. In this case, modules from Microsoft Office 2007/2010 and the Java 6 plugin without support for ASLR have been added. Memory addresses from within these modules are used to construct the ROP chains embedded in the Flash document.

It is trivial to take advantage of this feature to bypass ASLR. In all likelihood, a script is provided by the kit to call the various plugin loading routines necessary to load the correct modules. No further work is required. The kit authors use existing research and techniques off the shelf in order to develop these scripts: sample code from Oracle is used to load Java for their ASLR bypass. This example code shows up in Google using the search “force java 6” which is notable since the author needed to specifically load this version rather than the latest, which takes advantage of ASLR.

<script type="text/javascript" src="deployJava.js"></script>

try {
	location.href = 'ms-help://'
} catch (e) {}

try {
	var ma = new ActiveXObject("SharePoint.OpenDocuments.4");
} catch(e) {}

After attempting to load these plugins, config.html sets a value based on which ones were successful. It sets the innerHTML of the “test” div tag to either true, false, default or cat. Today.swf reads this value to determine which of its built-in ROP chains to load. This means that today.swf directly depends on the results of config.html and the plugins it loads, suggesting they were likely developed together and provided for the kit user.

As with the heap spray and DEP bypass, these techniques rely on third-party components to function. Unless one of these plugins is installed and enabled, the exploit will fail on Windows 7. The kit relies on Java to be outdated because its current versions do take advantage of ASLR. This issue was addressed with a Java 6 update in July 2011 and Java 7 was never affected. In the case of Microsoft Office, this weakness was described in a public walkthrough several months before the attack, however, it remained unpatched until after the attack.

We attempted to measure the number of browsers running these plugins in order to measure the effectiveness of these ASLR bypasses and, therefore, the entire exploit. What we found is that popular websites that track browser statistics neglect to track usage of Microsoft Office plugins, instead opting to list more common plugins like Silverlight, Google Gears and Shockwave. In the case of Java 6, if this were the best case scenario and no minor versions of Java had been patched yet, only roughly 30% of website visitors could be successfully exploited.

Conclusions

The Elderwood kit ships with reusable components for developing exploits for use-after-free vulnerabilities. It provides a capability to spray the heap with Adobe Flash, a set of techniques to load modules without support for ASLR, and several ROP chains for various versions of Windows to bypass DEP. The user of these tools needs little to no understanding of the tasks which they accomplish. For example, instead of requiring the user to understand anything about memory layouts and heap allocations, they can simply use a constant address provided by the kit. In fact, readers who made it this far may have deeper understanding of these components than the people who need to use them.

Many exploit development needs are accounted for by using these tools, however, some tasks are specific to the discovered vulnerability. In order to use the ROP gadgets that have been placed in memory by the SWF, the toolkit user must have control of program flow. This is specific to the exploitation of each vulnerability and the toolkit cannot help the user perform this task. We discuss the specific solutions to this problem by the toolkit user in the next section.

If you’re interested in learning more about how modern attacks are developed and performed, consider coming to SummerCon early next month and taking one of our trainings. Subscribe to our newsletter to stay up-to-date on our trainings, products and blog posts.