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.
We interrupt our regularly scheduled programming to bring you an important announcement: On Thursday, June 6th, just in time for SummerCon, we will be hosting a free Ruby Security Workshop in NYC! Signups are first-come, first-serve and we only have space for 30 people. Sign up here and we will email the selected participants the location of the training on Tuesday night.
In the last year, many new vulnerabilities and vulnerability classes have been discovered in Ruby applications. These vulnerabilities make use of features specific to the Ruby language and common idioms present in large Ruby projects, such as serialization and deserialization of data in the YAML format. As these vulnerability classes were initially discovered in popular and well-studied open source software, it’s extremely likely that they occur in applications throughout the Ruby ecosystem. These applications frequently represent lucrative targets for attackers, and with the appearance of new and easily exploitable bug classes, the potential for targeted and mass exploitation of Ruby programs has been demonstrated to the world. In this workshop, we aim to bridge a knowledge and skills gap by bringing information about these new vulnerability classes to software developers.
Our Ruby Security Workshop will be led by Hal Brodigan (@postmodern_mod3) and covers recent Ruby on Rails vulnerabilities classes, their root causes, and exercises where students develop exploits for real-world vulnerabilities. Attendees will learn the patterns behind the vulnerabilities and develop software engineering strategies to avoid introducing these flaws into their projects.
If you’re in the city for SummerCon and interested in attending on Thursday, fill out our signup form and selected participants will be sent more info tomorrow. We’re excited to bring you programs like this and we hope to see you there!
ExploitShield has been marketed as offering protection “against all known and unknown 0-day day vulnerability exploits, protecting users where traditional anti-virus and security products fail.” I found this assertion quite extraordinary and exciting! Vulnerabilities in software applications are real problems for computer users worldwide. So far, we have been pretty bad at providing actual technology to help individual users defend against vulnerabilities in software.
In my opinion, Microsoft has made the best advances with their Enhanced Mitigation Experience Toolkit. EMET changes the behavior of the operating system to increase the effort attackers have to expend to produce working exploits. There are blog posts that document exactly what EMET does.
In general, I believe that systems that are upfront and public about their methodologies are more trustworthy than “secret sauce” systems. EMET is very upfront about their methodologies, while ExploitShield conceals them in an attempt to derive additional security from obscurity.
I analyzed the ExploitShield system and technology and the results of my analysis follow. To summarize, the system is very predictable, attackers can easily study it and adapt their attacks to overcome it and the implementation itself creates new attack surface. After this analysis, I do not believe that this system would help an individual or organization defend themselves against an attacker with any capability to write their own exploits, 0-day or otherwise.
The analysis I performed was on their “Browser” edition. It’s possible that something far more advanced is in their “Corporate” edition, I honestly can’t say because I haven’t seen it. However, given the ‘tone’ of the implementation that I analyzed, and the implementation flaws that are in it, I doubt this possibility and believe that the “Corporate” edition represents just “more of the same.” I am welcome to being proven wrong.
Usually we can use some excellent and free tools to get a sense of software’s footprint. I like to use GMER for this. GMER surveys the entire system and uses a cross-view technique to identify patches made to running programs.
If you recall, from ExploitShields marketing information, we see popup boxes that look like this:
This screenshot has some tells in it, for example, why is the path specified? If this was really blocking the ‘exploit’, shouldn’t it never get as far as specifying a path on the file system?
In the following sections, I’ll go over each phase of my analysis as it relates to a component of or a concept within ExploitShield.
ExploitShield uses a Device Driver
One component of the ExploitShield system is a device driver. The device driver uses an operating-system supported mechanism (PsSetCreateProcessNotifyRoutine) to receive notification from the operating system when a process is started by the operating system.
Each time a process starts, the device driver examines this process and optionally loads its own user-mode code module into the starting process. The criteria for loading a user-mode code module is determined by whether or not the starting process is a process that ExploitShield is protecting.
The user-mode component seems to exist only to hook/detour specific functions.
The act of function hooking, also called function detouring, involves making modifications to the beginning of a function such that when that function is invoked, another function is invoked instead. The paper on Detours by MS Research explains the concept pretty thoroughly.
Function hooking is commonly used as a way to implement a checker or reference monitor for an application. A security system can detour a function, such as CreateProcessA, and make a heuristics-based decision on the arguments to CreateProcessA. If the heuristic indicates that the behavior is suspect, the security system can take some action, such as failing the call to CreateProcessA or terminating the process.
ExploitShield seems to function largely by detouring the following methods:
Here we can get a sense of what the authors of ExploitShield meant when they said “After researching thousands of vulnerability exploits ZeroVulnerabilityLabs has developed an innovative patent-pending technology that is able to detect if a shielded application is being exploited maliciously”. These are functions commonly used by shellcode to drop and execute some other program!
Function Hook Behavior
Each function implements a straightforward heuristic. Before any procedure (on x86) is invoked, the address to return to after the procedure is finished is pushed onto the stack. Each hook retrieves the return address off of the stack, and asks questions about the attributes of the return address.
- Are the page permissions of the address RX (read-execute)?
- Is the address located within the bounds of a loaded module?
If either of these two tests fail, ExploitShield reports that it has discovered an exploit!
A Confusion of Terms
- Vulnerability: A vulnerability is a property of a piece of software that allows for some kind of trust violation. Vulnerabilities have a really broad definition. Memory corruption vulnerabilities have had such an impact on computer security that many times, ‘vulnerability’ is used simply as a shorthand for ‘memory corruption vulnerability’ however other kinds of vulnerabilities do exist, for example information disclosure vulnerabilities or authentication bypass vulnerabilities. An information disclosure vulnerability could sometimes be worse for individual privacy than a memory corruption vulnerability.
- Exploit: An exploit is a software or procedure that uses a vulnerability to effect some action, usually to execute a payload.
- Payload: Attacker created software that executes after a vulnerability has been used to compromise a system.
It is my belief that when ExploitShield uses the term ‘exploit’, they really mean ‘payload’.
A Good Day for ExploitShield
So what is a play by play of ExploitShield functioning as expected? Let’s take a look, abstracting the details of exactly which exploit is used:
- A user is fooled into navigating to a malicious web page under the attackers control. They can’t really be blamed too much for this, they just need to make this mistake once and the visit could be the result of an attacker compromising a legitimate website and using it to serve malware.
- This web page contains an exploit for a vulnerability in the user’s browser. The web browser loads the document that contains the exploit and begins to parse and process the exploit document.
- The data in the exploit document has been modified such that the program parsing the document does something bad. Let’s say that what the exploit convinces the web browser to do is to overwrite a function pointer stored somewhere in memory with a value that is the address of data that is also supplied by the exploit. Next, the vulnerable program calls this function pointer.
- Now, the web browser executes code supplied by the exploit. At this point, the web browser has been exploited. The user is running code supplied by the attacker / exploit. At this point, anything could happen. Note how we’ve made it all the way through the ‘exploitation’ stage of this process and ExploitShield hasn’t entered the picture yet.
- The executed code calls one of the hooked functions, say WinExec. For this example, let’s say that the code executing is called from a page that is on the heap, so its permissions are RWX (read-write-execute).
ExploitShield is great if the attacker doesn’t know it’s there, and, isn’t globally represented enough to be a problem in the large for an attacker. If the attacker knows it’s there, and cares, they can bypass it trivially.
A Bad Day for ExploitShield
If an attacker knows about ExploitShield, how much effort does it take to create an exploit that does not set off the alarms monitored by ExploitShield? I argue it does not take much effort at all. Two immediate possibilities come to mind:
- Use a (very) primitive form of ROP (Return-Oriented Programming). Identify a ret instruction in a loaded module and push that onto the stack as a return address. Push your return address onto the stack before this address. The checks made by ExploitShield will pass.
- Use a function that is equivalent to one of the hooked functions, but is not the hooked function. If CreateProcess is hooked, use NtCreateProcess instead.
Both of these would defeat the protections I discovered in ExploitShield. Additionally, these techniques would function on systems where ExploitShield is absent, meaning that if an attacker cared to bypass ExploitShield when it was present they would only need to do the work of implementing these bypasses once.
Obscurity Isn’t Always Bad
The principle of ‘security through obscurity’ is often cited by security nerds as a negative property for a security system to hold. However, obscurity does actually make systems more secure as long as the defensive system remains obscure or unpredictable. The difficulty for obscurity-based defensive techniques lies in finding an obscure change that can be made with little cost and that the attacker can’t adapt to before they are disrupted by it, or a change that can be altered for very little cost when its obscurity is compromised.
For example, consider PatchGuard from Microsoft. PatchGuard ‘protects’ the system by crashing when modifications are detected. The operation of PatchGuard is concealed and not published by Microsoft. As long as PatchGuards operation is obscured and secret, it can protect systems by crashing them when it detects modification made by a rootkit.
However, PatchGuard has been frequently reverse engineered and studied by security researchers. Each time a researcher has sat down with the intent to bypass PatchGuard, they have met with success. The interesting thing is what happens next: at some point in the future, Microsoft silently releases an update that changes the behavior of PatchGuard such that it still accomplishes its goal of crashing the system if modifications are detected, but is not vulnerable to attacks created by security researchers.
In this instance, obscurity works. It’s very cheap for Microsoft to make a new PatchGuard, indeed the kernel team might have ten of them “on the bench” waiting for the currently fielded version to be dissected and bypassed. This changes the kernel from a static target into a moving target. The obscurity works because it is at Microsoft’s initiative to change the mechanism, changes are both cheap and effective, and the attacker can’t easily prepare to avoid these changes when they’re made.
The changes that ExploitShield introduces are extremely brittle and cannot be modified as readily. Perhaps if ExploitShield was an engine to quickly deliver a broad variety of runtime changes and randomly vary them per application, this dynamic would be different.
Some Implementation Problems
Implementing a HIPS correctly is a lot of work! There are fiddly engineering decisions to make everywhere and as the author you are interposing yourself into a very sticky security situation. ExploitShield makes some unnecessary implementation decisions.
The IOCTL Interface
The driver exposes an interface that is accessible to all users. Traditional best-practices for legacy Windows drivers ask that interfaces to the driver only be accessible to the users that should access it. The ExploitShield interface is accessible to the entire system however, including unprivileged users.
The driver processes messages that are sent to it. I didn’t fully discover what type of messages these are, or their format, however IOCTL handling code is full of possibilities for subtle mistakes. Any mistake present inside of the IOCTL handling code could lead to a kernel-level vulnerability, which would compromise the security of your entire system.
This interface creates additional attack surface.
The Hook Logic
Each hook invokes a routine to check if the return address is located in a loaded module. This routine makes use of a global list of modules that is populated only once by a call to EnumerateLoadedModules with a programmer-supplied callback. There are two bugs in ExploitShields methodology to retrieve the list of loaded modules.
The first bug is that there is apparently no mutual exclusion around the critical section of populating the global list. Multiple threads can call CreateProcessA at once, so it is theoretically possible for the user-mode logic to place itself into an inconsistent state.
The second bug is that the modules are only enumerated once. Once EnumerateLoadedModules has been invoked, a global flag is set to true and then EnumerateLoadedModules is never invoked again. If the system observes a call to CreateProcess, and then a new module is subsequently loaded, and that module has a call to CreateProcess, the security system will erroneously flag that module as an attempted exploit.
Neither of these flaws expose the user to any additional danger, they just indicate poor programming practice.
Why Hook At All?
An especially baffling decision made in the implementation of ExploitShield is the use of hooks at all! For each event that ExploitShield concerns itself with (process creation and file write), there are robust callback infrastructures present in the NT kernel. Indeed, authors of traditional anti-virus software so frequently reduced system stability with overly zealous use of hooks that Microsoft very strongly encouraged them to use this in-kernel monitoring API.
ExploitShield uses unnecessarily dangerous programming practices to achieve effects possible by using legitimate system services, possibly betraying a lack of understanding of the platform they aim to protect.
The Impossibility of ExploitShield’s success
What can ExploitShield do to change this dynamic? The problem is, not much. Defensive systems like this are wholly dependent on obscurity. Once studied by attackers, the systems lose their value. In the case of software like this, one problem is that the feedback loop does not inform the authors or users of the security software that the attacker has adapted to the security system. Another problem is that the obscurity of a system is difficult to maintain. The software has to be used by customers, so it has to be available in some sense, and if it is available for customers, it will most likely also be available for study by an attacker.
What Hope Do We Have?
It’s important to note that EMET differs from ExploitShield in an important regard: EMET aims to disrupt the act of exploiting a program, while ExploitShield aims to disrupt the act of executing a payload on a system. These might seem like fine points, however a distinction can be made around “how many choices does the attacker have that are effective”. When it comes to executing payloads, the attackers choices are nearly infinite since they are already executing arbitrary code.
In this regard, EMET is generally not based on obscurity. The authors of EMET are very willing to discuss in great detail the different mitigation strategies they implement, while the author of ExploitShield has yet to do so.
Generally, I believe if a defensive technique makes a deterministic change to program or run-time behavior, an attack will fail until it is adapted to this technique. The effectiveness of the attack relies on the obscurity of the technique, and on whether the change impacts the vulnerability, exploit, or payload. If the attack cannot be adapted to the modified environment, then the obscurity of the mitigation is irrelevant.
However, what if the technique was not obscure, but was instead unpredictable? What if there was a defensive technique that would randomly adjust system implementation behavior while preserving the semantic behavior of the system as experienced by the program? What is needed is identification of properties of a system that, if changed, would affect the functioning of attacks but would not change the functioning of programs.
When these properties are varied randomly, the attacker has fewer options. Perhaps they are aware of a vulnerability that can transcend any permutation of implementation details. If they are not, however, they are entirely at the mercy of chance for whether or not their attack will succeed.
ExploitShield is a time capsule containing the best host-based security technology that 2004 had to offer. In my opinion, it doesn’t represent a meaningful change in the computer security landscape. The techniques used hinge wholly on obscurity and secrecy, require very little work to overcome and only affect the later stage of computer attacks, the payload, and not the exploit.
When compared to other defensive technologies, ExploitShield comes up short. It uses poorly implemented techniques that work against phases of the attack that require very little attacker adaptation to overcome. Once ExploitShield gains enough market traction, malware authors and exploit writers will automate techniques that work around it.
ExploitShield even increases your attack surface, by installing a kernel-mode driver that will processes messages sent by any user on the system. Any flaws in that kernel-mode driver could result in the introduction of a privilege escalation bug into your system.
The detection logic it uses to find shellcode is not wholly flawed, it contains an implementation error that could result in some false positives, however it is generally the case that a call to a runtime library function, with a return address that is not in the bounds of a loaded module, is suspicious. The problem with this detection signature is that it is trivially modified to achieve the same effect. Additionally, this detection signature is not novel, HIPS products have implemented this check for a long time.
This is a shame, because, in my opinion, there is still some serious room for innovation in this type of software…
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.
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.
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)
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.
Although I haven’t done any development on KARMA for a little over 5 years at this point, many of the weaknesses that it demonstrates are still very present, especially with the proliferation of open 802.11 Hotspots in public places. A few weeks ago, I was invited to help prepare a demo of KARMA for CBS News and the segment actually aired a few weeks ago. If you’re like me and don’t have one of those old-fashioned tele-ma-vision boxes, you can check out the segment here.
Unfortunately, they weren’t able to use the full demo that I prepared. The full demo used a KARMA promiscuous access point to lure clients onto my rogue wireless network with a rogue network’s gateway routed outbound HTTP traffic through a transparent proxy that injected IFRAMEs in each HTML page. The IFRAMEs loaded my own custom “Aurora” exploit, which injected Metasploit’s Meterpreter into the running web browser. From there, I could use the Meterpreter to sniff keystrokes as they logged into their SSL-protected bank/e-mail/whatever. The point was that even if a victim only uses the open Wi-Fi network to log into the captive portal webpage, that’s enough for a nearby attacker to exploit their web browser and maintain control over their system going forward. Perhaps that was a little too complicated for a news segment that the average American watches over breakfast.
As it has been quite a while since I have talked about KARMA, here are a few updates on the weaknesses that it demonstrated:
- Windows XP SP2 systems with 802.11b-only wireless cards would “park” the cards when the user is not associated to a wireless network by assigning them a 32-character random desired SSID. Even if the user had no networks in their Preferred Networks List, the laptop would associate to a KARMA Promiscuous Access Point and activate the network stack while the GUI would still show the user as not currently associated to any network. This issue was an artifact of 802.11b-only card firmwares (PrismII and Orinoco were affected) and is not present on most 802.11g cards, which is what everyone has these days anyway.
- Even with a newer card, Windows XP SP2 will broadcast the contents of its Preferred Networks List in Probe Request frames every 60 seconds until it joins a network. Revealing the contents of the PNL allows an attacker to create a network with that name or use a promiscuous access point to lure the client onto their rogue network. Windows Vista and XP SP3 fixed this behavior.
- Mac OS X had the same two behaviors, except that Apple’s AirPort driver would enable WEP on the wireless card when it had “parked” it. However, the WEP key was a static 40-bit key (0×0102030405 if I recall). Apple issued a security update in July 2005 and credited me for reporting the issue.
- On 10/17/2006, Microsoft released a hotfix to fix both of the previous issues on Windows XP SP2 systems that Shane Macaulay and I had discovered and presented at various security conferences over the previous two years.
- Newer versions of Windows (XP SP3, Vista, 7) are only affected if the user manually selects to join the rogue wireless network or the rogue network beacons an SSID in the user’s Preferred Networks List.
Although the leading desktop operating systems found on most laptops have addressed the issue, most mobile phones now support 802.11 Wi-Fi, which may give KARMA a chance to live again!
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.
- RSA Brief Session Webcast, Video, Podcast, and Slides (Login with Delegate access required)
- SOURCE Boston 2010 Slides (more complete and technical than the RSA talk)
- ITWeb Security Summit 2010 (Upcoming)
This year, Alex Sotirov and I will be teaching our first “Assured Exploitation” training class at CanSecWest. This training class is focused on various topics in advanced exploitation of memory corruption vulnerabilities. This includes a thorough understanding of exploitation mitigations (where they are effective and where they aren’t), heap manipulation, return-oriented programming, and ensuring a clean continuation of process execution so that the application does not crash.
Over the course of the training, the hands-on exercises will be oriented around taking the students through the steps of fully understanding the “Aurora” Internet Explorer vulnerability and developing their own reliable and robust exploit for Internet Explorer 8 on Windows 7, just like the exploit demonstrated in this video demo of my exploit: