Every once in a while, security researchers try to bypass security solutions for kicks, fame, marketing and to raise awareness for a new vulnerability that totally foils protection. Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) has seen its share of bypasses and when it is bypassed, the underlying approach grabs our attention. Somewhat like EMET’s philosophy, the technologies in our HitmanPro.Alert solution are also completely signatures-less, i.e. the behaviour-based anti-exploit technologies in both EMET and HitmanPro.Alert focus on the attack techniques and stop attacks without requiring threat information or signatures based on prior knowledge of attacks.
For people who are unfamiliar with this terrain, some background explanation is in order; why is there a need for software like EMET or HitmanPro.Alert.
To deliver malware to as many victims as possible, attackers turn to web-borne exploits that abuse vulnerable software (like Flash and Java) running on computers that visit trusted websites that contain malicious ads (malvertising) or hidden iframes that load an attack site.
But did you know that there are only a two dozen techniques to abuse any vulnerability, known and unknown? And often it takes more than a year before researchers or attackers come up with a new attack technique!
Did you also know that, depending on the vulnerability, always two or more techniques (like Heap Spray, Stack Pivot and Return-Oriented Programming (ROP)) must be used in sequence in order to be successful and deliver malware on victim’ machines? Software that aims to detect and block exploit techniques are e.g. Microsoft EMET and HitmanPro.Alert. Blocking exploit techniques stops exploit attacks on existing and future vulnerabilities and prevents malware from being delivered, no matter how obfuscated, new or sophisticated this malware is. So true anti-exploit solutions that revolve around stopping the attack techniques are kind of’ the holy grail against exploit attacks and their malware. For attackers they are a formidable barrier to conquer in order to successfully compromise a pc.
Last week a new technique was disclosed by Duo Security to bypass EMET’s ROP mitigations. The technique focusses on bypassing EMET’s security hooks abusing Wow64 compatibility layer.
The Wow64 compatibility layer provides a 32-bit execution environment on 64-bit Windows systems. This environment allows legacy 32-bit software to run on 64-bit computers.
Current exploit mitigation solutions protect the 32-bit environment. The bypass technique disclosed by Duo Security demonstrates that an attacker may also use the 64-bit environment when a 32-bit application is executed under Wow64. This effectively bypasses all security measures placed in the 32-bit environment.
To read more about the bypass, see the blog of Duo Security.
To get around DEP, an attacker needs to make a piece of memory on the heap executable. This piece of memory usually contains the malicious shellcode. Windows API provides functions to facilitate the modification of the protection of memory regions. For this article we focus on the NtProtectVirtualMemory function, located in ntdll.dll.
HitmanPro.Alert 3.1 provides three mitigations that relate to syscall bypasses. The following figure illustrates these three attacks using syscalls.
Attack #1 uses a legit syscall stub (partial) with an attacker-supplied syscall index parameter. This bypasses security hooks on the NtProtectVirtualMemory stub in 32-bit ntdll.dll. This is illustrated in the following figure.
As you can see above, both syscall stubs (functions) look very similar. The only difference is the syscall index which is placed in register eax. A security solution will place a hook at the green line, the start of NtProtectVirtualMemory. If an attacker is able to resolve the address of a different syscall stub, for example NtQuerySection, it only needs to make sure eax contains the syscall index of NtProtectVirtualMemory. On this system it is 4Dh. Then by calling the address indicated by the red arrow, an attacker can mimic a call to NtProtectVirtualMemory.
Attack #2 bypasses the 32-bit ntdll.dll entirely by directly calling the Wow64 marshalling layer performing the NtProtectVirtualMemory in 64-bit ntdll.dll. This attack is similar to the above, but now the attacker needs to resolve a function in Wow64, specifically wow64cpu!X86SwitchTo64BitMode. A pointer to this function is normally stored in fs:[0xc0]. More details on this attack can be read on this post at pastebin, referenced by @r41p41.
Attack #3 is the bypass as disclosed by Duo Security. The attacker uses ROP gadgets to transition from 32-bit mode directly into 64-bit NtProtectVirtualMemory. See this paper on how this is done.
The first 2 attacks are mitigated by HitmanPro.Alert 3.1 build 310 (or newer). Attack #3 is mitigated by HitmanPro.Alert 3.1 build 332 (or newer).
To illustrate the responsiveness of our development team, the time between disclosure by Duo Security and the release of build 332 is less than a week.
Network based exploit protections are reactive based and rely heavily on signatures. Endpoint exploit mitigation solutions are behaviour-based and are not dependent on signatures. That’s why in our opinion, behaviour-based exploit technique prevention is the preferred choice. It is possible to bypass a layered behaviour-based solution, but only if an attack is entirely based on a sequence of completely new exploit techniques. However, as is shown with the new Wow64 bypass technique, the mitigation of these new techniques could quickly be incorporated into our behaviour-based solution. Which is as of then capable of mitigating all attacks (whether compressed, encrypted or otherwise obfuscated) that are based on the newly discovered exploit technique.
Together with the release of HitmanPro.Alert 3.1 build 332 we also updated our Exploit Test Tool application. This application allows to safely trigger an exploit technique, including the new Wow64 bypass technique.
HitmanPro.Alert 3.1 build 332
Exploit Test Tool