This is the third part of a six-part blog based on the paper submitted by my colleague Gregory and myself on Advanced Persistent Threats (APT), for AVAR 2014.
Continuing from the second part of our paper…
Exploiting Popular Applications
Popular applications such as web browsers, word processors, etc. in an attempt to provide rich functionality, at times fail to handle untrusted data properly. The attackers probe these applications with a variety of mechanisms such as fuzzing, reverse-engineering, study of any stolen code, etc. in order to discover bugs that allow them to execute malicious code without any user interaction.
Lack of buffer boundary checks in the application’s code is exploited, critical memory area is over written to hijack the control flow of the program and execute the attacker’s shell code.
Likewise, bugs in handling multiple references to the same object have lead to Use-After-Free class of vulnerabilities which after seeding memory areas with malicious code can be exploited to execute the attacker’s shell code.
Data Execution Prevention (DEP) Bypass
DEP is a security feature provided by the operating system to thwart buffer overflow attacks that store and execute malicious code from a non-executable memory location. The OS leverages the No-eXecute technology in modern day CPUs to enforce hardware assisted DEP that prevents memory areas without explicit execute-privilege from executing. Attempts to transfer control to an instruction in a memory page without execute-privilege will generate an access fault, thereby rendering the attack ineffective.
Bypassing the DEP feature in a process involves locating already existing pieces of executable code from process memory space and manipulating them to use attacker controlled data to achieve arbitrary code execution. This is accomplished using one of the following techniques:
- Return-to-libc
- Branch Oriented Programming (BOP)
- Return Oriented Programming (ROP)
- Jump Oriented Programming (JOP)
Return-to-libc
This evasion technique involves replacing the return address on the call stack with that of an existing routine in a loaded binary. The parameters/arguments that are passed to such routines are controlled by the exploit data strategically placed on the stack. A system function like WinExec() can be invoked to load and run a malicious component without running non-executable exploit data.
Fig.6: The stack layout when using return-to-libc attack to invoke system() in GNU Linux (32-bit).
Branch Oriented Programming
This bypassing method involves an attacker gaining control of the call stack and executing carefully stitched pieces of executable code called “gadgets”. These gadgets contain one or two instructions which typically end in a return instruction (ROP) or a jump instruction (JOP) and are located in a subroutine within an existing program or a shared library. Chained together, these gadgets allow an attacker to perform arbitrary operations on a machine.
Fig.7: ROP gadget execution sequence based on exploit controlled stack layout
Address Space Layout Randomization (ASLR) Bypass
In order to thwart BOP attacks, the concept of randomizing executable code locations, by randomizing the base address of the loaded binary, on every system reboot was introduced. This security measure known as ASLR made it difficult for the attacker to predict where the required gadget sequence resides in memory. However, APTs have been observed bypassing this protection using the following techniques:
Loading Non-ASLR modules
Dynamic-Link Libraries compiled without the dynamic-base option cannot take advantage of the protection offered by ASLR and as a result, are usually loaded at a fixed memory space. For example, Microsoft’s MSVCR71.DLL shipped with Java Runtime Environment 1.6 is usually loaded at a fixed address in the context of Internet Explorer making it easy to construct the required gadget chain in memory.
Fig.8: An ASLR incompatible version of MSVCR71.dll
DLL Base Address calculation via Memory Address Leakage
This technique involves determining the base address of any loaded ASLR-compatible DLL based on any leaked address of a memory variable or API within that DLL. Based on the address of this known entity, the relative addresses of all the required gadgets can be calculated and a ROP attack constructed.
Attack techniques such as modifying the BSTR length or null termination allows access to memory areas outside the original boundaries, leading to the memory address of known items being revealed to the exploit code. This can then be used to pinpoint the DLL’s location to use ROP gadgets within it. Array() object also has a length component that can be overwritten to leak memory addresses beyond its bounds.
Browser Security Bypass
Leveraging the operating system’s security, popular web browsers run certain parts of their code, JavaScript execution and HTML rendering for example, as a sandboxed background process. This process runs with limited privileges and has restricted access to the file system, network, etc. A master controller acting as an intermediary interacts with the user and manages these sandboxed processes. By using this master-slave architecture and providing a controlled environment, users are protected from exploit attempts by limiting a shell code’s capability to access host system resources and confining its damage to within the sandbox.
Since these browsers rely on the operating system’s security model, exploiting unpatched kernel vulnerabilities will result in the malicious code escaping its confined environment. The infamous Duqu malware relied on vulnerability (CVE-2011-3402) in the Win32k.sys driver that improperly handles specially crafted True Type Font (TTF) files. This allowed the malware to escape a user-mode sandboxed environment implemented by the Microsoft Word process and compromise the host.
Fig.9: Vulnerable code snippet from win32k.sys that lead to the Duqu TTF exploit
Enhanced Mitigation Experience Toolkit (EMET) Bypass
EMET is a Microsoft tool that provides additional security to commonly-exploited third-party applications such as web browsers, word processors, etc. It extends the operating system’s protection mechanisms to these vulnerable applications and makes exploitation attempts extremely difficult.
The following table lists the protections offered by EMET and known bypassing techniques [4]:
Click here to read the fourth part of this blog
References:
[4] http://bromiumlabs.files.wordpress.com/2014/02/bypassing-emet-4-1.pdf
[5] http://0xdabbad00.com/wp-content/uploads/2013/11/emet_4_1_uncovered.pdf
Lokesh Kumar
K7 Threat Control Lab
If you wish to subscribe to our blog, please add the URL provided below to your blog reader:
https://labs.k7computing.com/feed/
