Drive-by attacks caused by known and unknown exploits are one of the biggest and most worrying issues in the security industry. Today a relevant number of security incidents are caused by malware infections often dropped on the system by specific exploits targetting browsers, browser plugins like Adobe Flash Player, Java and PDF documents.
Malware using exploits to spread are actually not new, let’s just recall for instance the first worm in the computer history, the Morris worm dated 1988 which was exploiting a bug in the fingerd program when calling the gets() function. This bug allowed the worm to quickly spread on more than 6.000 systems. Another example is the BubbleBoy worm incident back in 1999, the first worm able to automatically spread by e-mail, it was exploiting a flaw in the Internet Explorer’s ActiveX management routine used by Outlook Express to render HTML-formatted e-mails.
Today there are many malicious kits sold in the black market able to exploit several bugs in many popular applications, they are used to build up fake webpages able to drop malicious code in the victim’s PC through some exploits. Blackhole, Elenoire, are just some of the most common ones.
This is the reason why more and more security companies and security researchers are focusing on writing applications able to detect and block exploits as soon as they land on the system, even before they actually could be executed.
Writing an exploit means doing a thorough research which consists in finding a useful bug in a specific application, checking if it can be replicated and triggered in some specific way, checking if it can be used to redirect in some way the execution code flow of the targetted application and then writing the exploit code. In short terms, something which is definitely not trivial at all.
Let’s firstly say that the first layer of defense against exploits is writing secure code, though this is up to the developer(s), definitely a field where end users can’t actually do anything.
Besides this, starting from Windows XP Service Pack 2, Microsoft decided to implement some security features able to defense against exploits. From Windows Vista, Microsoft completed the implementation of all the known security features that could prevent the execution of exploit code.
The goal of an exploit is to execute an arbirary payload by finding a bug in a vulnerable application and using it to redirect the code flow in a way that the malicious code injected by the exploit itself can be executed.
In this scenario, the most common way to exploit a bug is injecting the malicious payload into the stack or heap by overwriting some vulnerable buffer. Anyway, both stack and heap are memory locations that are usually marked as non-executable memory pages, this is a critical point as the Data Execution Prevention (DEP) is based on detecting this specific behavior. DEP technology checks if the code is being run from a memory region marked as non-executable. If so, the operating system will consider the process as compromised and the victim process will be immediately terminated.
To make the job of exploit writers harder, another key security feature has been added, which is the Address Space Layout Randomization (ASLR). To explain why this feature is vital to the prevention of exploit attacks, let’s just give an very basic example: if the attacker knows since the beginning the address of the VirtualProtect() API in the vulnerable process, it could force the code flow (ROP attacks) into calling the VirtualProtect() API and mark the memory region where the exploit code is located as executable memory, and then allow the exploit code to be executed. This is a very common trick which allows an exploit to bypass the DEP technology, as the memory region from where the malicious code is being run is now marked as executable. With ASLR enabled, all the system libraries’s base address, process’s base address, stack and heap addresses are randomized, so that it becomes basically impossible to know in advance the memory address of the needed APIs.
Both DEP and ASLR, if rightly implemented and used together, add a very strong layer of defense against exploits. It may happen to find exploits able to bypass both security techniques by design, though it’s a quite uncommon scenario – let’s recall the exploit used by VUPEN against Internet Explorer at the last Pwn2Own 2012. Most of the times we can find exploits bypassing both those security features just because the exploit itself relies on the presence of some library in the vulnerable process which is still not using ASLR, so the attacker can use its already-known memory addresses to build up the ROP chain able to break the DEP technology. The most common example is the msvcr71.dll library used by Java jre6, still installed in many computers.
This brief introduction was needed to better explain the various approaches used by security software to try mitigate exploits. In Windows Vista and Windows 7 both the DEP and ASLR technologies (along with a couple others as well) can be customized on a per-process basis, to provide system compatibility with older applications that could eventually break otherwise.
So the two different approaches used to try mitigate the exploit attacks are:
- Try to prevent exploit shellcodes from actually starting at all (preventive approach)
- Try to sandbox in some way the exploit code, by hooking system APIs (reactive approach)
The first one is what is being done by DEP,ASLR,SEHOP security features, by randomizing the memory space address, blocking execution from non-executable memory regions and preventing the overwriting of the security exception handlers’s chain. Their final goal is to actually prevent the exploit from getting it working at all.
Microsoft released a tool called EMET (Enhanced Mitigation Experience Toolkit) which can be used as a management tool for the above listed security features. EMET doesn’t add any major security feature (though it adds something very useful to prevent heap spraying, null page allocations and EAT access filtering) but it allows the end user to better tune up the already-available system security features for each process.
Then there are other security software that instead try to block exploit code by monitoring the shellcode’s execution and preventing it from doing any malicious activity, like executing other processes or download additional malware from the web. We can recall two free security software doing this, the older (not anymore officially available) Comodo Memory Firewall and the newest ExploitShield from a brand new security company called ZeroVulnerability Labs Inc.
While both approaches are useful, the weakest point in the second one is that, to sandbox the exploit code, you are basically allowing the shellcode to be executed. So you are up to what the attacker decided to do with his own shellcode. Usually those security products are hooking user mode APIs like CreateProcess, URLDownloadToFile, LoadLibrary, all those common APIs used by exploit’s shellcodes to drop additional malware on the system. While this approach looks to be effective against most common exploits out there, the real reason is that many exploit coders usually don’t care about potential hooks placed in the APIs they are going to use.
Let’s think a bit about this approach: if the protection is based upon the interception of some APIs, this means that the exploit shellcode has already been able to get executed, so the attacker is now fully controlling the code flow. If the attacker is controlling the code flow, what is actually preventing him from bypassing the placed hook before calling the wanted API?
Technically it is something easy to do, and we are aware of past exploits using this technique to bypass security software’s hooks. The reason why this is something easy to do is because both exploit code and security software are working at the same level, so the attacker can actually get around the hook by writing its own API stub and then jump to the original APIs right after the placed hook.
Just to give a brief example of this attack, we wrote our own exploit webpage using a very old Internet Explorer exploit which drops a customized shellcode, and we tried this against ExploitShield. The video below shows the result:
We have been able to execute calc.exe process without getting intercepted by ExploitShield. This happened because we didn’t call the CreateProcess API as exploit coders usually do, but we wrote our own CreateProcess API stub which then redirect to the original CreateProcess API right after the hook placed at the begininng of the original CreateProcess API.
This post is not intended to blame about security solutions like ExploitShield, we really think it could add a strong layer to the security of whole system as most exploits out there are not taking care about API hooks at all, so it’ll anyway hit a very good detection rate. What it should be clear is that solutions like ExploitShield must not be intended as a replacement for security features like DEP,ASLR, SEHOP: they are working at very different level and they both enforce system’s security, just in very different ways.