Exploits Explained: PE Format and Memory<\/h4>\n\n\n\n
Before learning about exploit protections, we need to state some elements about the “PE” Portable Executable format, the executable format introduced in Windows 95\/NT. A PE file contains multiple parts, but we will focus here on only one of them, the image section header format<\/strong>, represented by the IMAGE_SECTION_HEADER<\/strong> structures. Sections headers are used to organise code and data in an efficient way. In this representation, only interesting members are show :<\/p>\n\n\n\n Let\u2019s take a look at some common sections:<\/p>\n\n\n\n The .text section<\/strong> is where all the program instructions emitted by the compiler ends up. Its attributes are Executable<\/strong> and Writable<\/strong>. When a PE file is loaded into memory, each section is instantiated with its following attributes<\/strong>. The memory layout of a PE file has the following pattern.<\/p>\n\n\n\n We can notice the presence of two additional fields, the heap<\/strong> and the stack<\/strong>. The heap segment is a block of memory where dynamic memory allocation takes place. Global variables are also stored on the heap. Its attributes are Readable<\/strong> and Writable<\/strong> and, on legacy systems, Executable<\/strong>. <\/p>\n\n\n\n The stack segment handles allocation of all non-static variables and functions call data (parameters, return address, registers contexts, etc.) and as such, is responsible for the control-flow of the program. Its attributes are Readable<\/strong> and Writable<\/strong> and, on legacy systems, Executable<\/strong>.<\/p>\n\n\n\n The goal of an attacker is to manipulate the target program control-flow (shellcode) in order to execute some code of its own (payload). Usually the attack is used to gain access to some system or data.<\/p>\n\n\n\n The approximate disassembly of the foo() function is the following (x86 CDECL<\/a> calling convention):<\/p>\n\n\n\n Usually this won\u2019t work because of Data Execution Prevention (see Protection mechanisms below) forcefully terminating the process<\/strong> if code is executed on the stack or heap.<\/p>\n\n\n\n The attacker will look for code sequences (gadget) containing the POP assembly instruction<\/strong> to load suitable values<\/strong> in the processor registers then calling a function with these values as parameters (return-to-libc<\/a>). This process can be repeated multiple time to find an exploitable function, hence the name ROP Chaining<\/strong>.<\/p>\n\n\n\n Many protection mechanisms have been developed to protect users against exploitation of insecurely written software (see part I<\/a>). Each software has its own way to implement such mechanisms. Since only closed source anti-exploit software is currently available, we will refer to the protections methods implemented in the Enhanced Mitigation Experience Toolkit (EMET)<\/strong>:<\/p>\n\n\n\n Canaries are known values placed between an allocated buffer and control data on the stack or heap<\/strong>. If a buffer overflow occurs, the first data to be corrupted will be the canary one<\/strong>. Functions that will check data integrity will fail and an error or exception will be raised.<\/p>\n\n\n\n In the example above, the magic value represented by the third bloc is likely to be overwritten if a buffer overflow occurs.<\/p>\n\n\n\n Data execution prevention is a system-level memory protection feature that marks one or more pages of memory as non-executable<\/strong>, usually heap and stack sections. If a program attempts to run code from a page memory where execution is disabled a memory access violation exception occurs.<\/strong> A hardware solution marketed as the NX bit<\/strong> is present on modern CPUs. Any operating system with support for the NX bit can mark areas of memory as non-executable. The processor will not execute any code residing in these specific areas<\/strong>.<\/p>\n\n\n\n When the linker creates an executable, it assumes it will be placed in a specific memory-mapped area<\/strong>, by default at address 0x400000<\/strong>. When the process is loaded, its instructions and resources are always present at the same address<\/strong>. An exploit writer can use this fact to write buffer overflow or ROP exploits more easily. Address Space Layout Randomization (ASLR)<\/strong> is a technique which randomizes the base addresses (ImageBase) of executable code, heap and stack<\/strong> in a process\u2019s address space on each boot<\/strong>, which really complicate exploitation and shellcode development.<\/p>\n\n\n The image above, represents the base value of process smss.exe (Session Manager Subsystem) of a Windows 7 x64 system with Data Execution Prevention and Address Space Load Randomization features enabled.<\/p>\n\n\n\n On Windows OS, hardware and software exceptions<\/strong> are handled through the use of the structured exception handling mechanism (SEH)<\/strong>. This mechanism makes use of the exception registration record structure, which is composed of a pointer to the next structure and an exception handler function pointer.<\/p>\n\n\n\n SEHOP<\/strong> complicate the use of the technique by verifying that a thread\u2019s exception handler recorded list is not altered<\/strong>, using a symbolic record, before allowing any of the registered exception handlers to be called<\/strong>. If the symbolic record cannot be reached, the system assumes SEH overwrite<\/strong> may have occurred and terminate the thread<\/strong>.<\/p>\n\n\n\n By default, a null pointer<\/strong> point at virtual address 0x00000000<\/strong>, which content may be overwritten (kernel mode<\/a>) with any address. A software vulnerability may arise when a null pointer is used, allowing a shellcoder to execute any code. The Null Page Protection<\/strong> pre-allocates memory at the virtual address 0x00000000 and enable memory protection<\/strong> on this specific memory page. Dangling or wild pointers<\/a>, pointers that do not point to a valid destination, can be exploited in a similar way, allocating memory at the address they point to.<\/p>\n\n\n\n Heap spray attack involves allocating the thread\u2019s heap memory at predetermined (the heap is deterministic) addresses with the right values<\/strong> in order to store a shellcode at a predictable address<\/strong>. The Heap Spray Protection<\/strong> works by pre-allocating certain regions in the heap, breaking the possibility to insert a shellcode<\/strong> using heap spray.<\/p>\n\n\n\n Usually a program relies on external functions provided in other executables or DLLs files. These functions are listed on the PE files Export Address Table (EAT)<\/strong>. In order to do something useful, an exploit usually needs to import functions exported by Windows internal modules (kernel32.dll, ntdll.dll, etc.). Because of ASLR<\/strong>, the exploit must first find where it is loaded.<\/p>\n\n\n\n This protection is able to detect if the thread\u2019s stack has been pivoted, and also monitor stack registers of some Windows API<\/a> functions.<\/p>\n\n\n\ntypedef struct _IMAGE_SECTION_HEADER {\n BYTE Name[IMAGE_SIZEOF_SHORT_NAME];\n DWORD VirtualAddress;\n DWORD SizeOfRawData;\n DWORD PointerToRawData;\n DWORD Characteristics;\n} IMAGE_SECTION_HEADER, *PIMAGE_SECTION_HEADER;<\/code><\/pre>\n\n\n\n
Name<\/strong> : Name of the section, usually automatically added by the compiler
VirtualAddress<\/strong> : Offset in virtual memory where to load the section (RVA)
SizeOfRawData<\/strong> : Size of the section
PointerToRawData<\/strong> : Pointer to the \u201ccode\u201d part of the section
Characteriscs<\/strong> : Section attributes to set when loading in memory<\/p>\n\n\n\n\n
The .bss section<\/strong> is where all uninitialized data are stored. Its attributes are usually Readable<\/strong> and Writable<\/strong>.
The .data section<\/strong> is where all the initialized data goes, except local variables that are located on the thread’s stack. Its attributes are Readable<\/strong> and Writable<\/strong>.<\/p>\n\n\n\n![\"stack](\"https:\/\/www.adlice.com\/wp-content\/uploads\/2016\/11\/PE_Memory_Layout-400x1024.jpg\")
Exploits Explained: Exploitation methods<\/h4>\n\n\n\n
Buffer overflow exploitation<\/strong>
Let\u2019s consider the following C vulnerable code:<\/p>\n\n\n\n#include <stdio.h>\n\nvoid foo() {\n char buffer[10];\n printf(\"Input:\\n\");\n scanf(\"%s\", buffer);\n printf(\"Output: %s\\n\", buffer);\n}\n\nint main() {\n foo();\n return 0;\n}<\/code><\/pre>\n\n\n\n
This program calls the foo() function that allocates a space of 10 bytes on the stack and asks the user for input. It then displays the input characters and exits. However, no verification of the input is made<\/strong>, so it\u2019s possible for the user to write data outside the allocated space: a stack buffer overflow <\/strong>can occur.<\/p>\n\n\n\n; _foo\npush\tebp; ; Save the return address to _main into the stack\nmov \tebp, esp ; New call frame\nsub esp, D4h ; Allocate memory on the stack to store variables content\n\n; printf() and stack cleaning\npush\t\"Input:\\n\"\ncall\t_printf\nadd esp, 4h\n\n; user input and stack cleaning\nlea eax, [ebp+buffer]\t\npush \teax\t\t\t\npush \t\"%s\"\ncall\t_scanf\nadd \tesp, 8h\n\n; user output and stack cleaning\nlea eax, [ebp+buffer]\t\npush eax\t\t\t\npush \"Output: %s\\n\"\ncall _printf\nadd esp, 8h\n\n; Stack unwinding and exit\nmov ebp, esp\npop ebp ; Recover the return address to _main from the stack\nret ; Return to _main<\/code><\/pre>\n\n\n\n
As we can see, it\u2019s possible when inputting enough characters to overwrite the stack frame designed to store the variable content<\/strong>. The goal of an attacker is to overwrite the return address to _main stored into the stack (line 2) by an address pointing to its own code using a shellcode as input sequence.<\/p>\n\n\n\n
ROP Chaining exploitation<\/strong>
A trick to bypass such protection is known as Return-oriented programming (ROP)<\/strong>. This technique makes use of executable instructions found within the program code<\/strong> (.text section) and shared libraries<\/strong>.<\/p>\n\n\n\n![\"stack](\"https:\/\/www.adlice.com\/wp-content\/uploads\/2016\/11\/ROP_Illustration.png\")
<\/a>
Exploits Explained: Protection methods<\/h4>\n\n\n\n\n
Canaries<\/strong><\/p>\n\n\n\n![\"buffer](\"https:\/\/www.adlice.com\/wp-content\/uploads\/2016\/11\/Canary_Illustration.png\")
<\/a>
Executable space protection \/ Data Execution Prevention (DEP)<\/strong><\/p>\n\n\n\n
Address Space Layout Randomization (ASLR)<\/strong><\/p>\n\n\n\n![\"DEP](\"https:\/\/www.adlice.com\/wp-content\/uploads\/2016\/11\/DEP_ASLR_Sample.png\")
<\/a><\/figure>\n<\/div>\n\n\n
Structured Exception Handler Overwrite Protection (SEHOP)<\/strong><\/p>\n\n\n\ntypedef struct _EXCEPTION_REGISTRATION_RECORD {\n struct _EXCEPTION_REGISTRATION_RECORD *Next;\n PEXCEPTION_ROUTINE Handler;\n} EXCEPTION_REGISTRATION_RECORD, *PEXCEPTION_REGISTRATION_RECORD;<\/code><\/pre>\n\n\n\n
When an exception occurs, the program control-flow will be redirected to the address of the exception handler function<\/strong>. Using buffer overflow, it may be possible to replace this address with anything<\/strong>, which may force the application to jump to a shellcode.<\/p>\n\n\n\n
Null Page Protection<\/strong><\/p>\n\n\n\n
Heap Spray Protection<\/strong><\/p>\n\n\n\n
Export Address Table Access Filtering (EAF)<\/strong><\/p>\n\n\n\n![\"Ndll.dll](\"https:\/\/www.adlice.com\/wp-content\/uploads\/2016\/11\/PE_Export_Illustration.png\")
<\/a>
This mitigation method works by terminating<\/strong> any thread which tries to access the export table of these modules<\/strong>.<\/p>\n\n\n\n
Stack Pivot Protection<\/strong>
Stack pivoting may be used to facilitate ROP Chaining<\/strong>. This method alters the address contained within the special register ESP<\/strong>, altering the stack frame, even replacing it with a fake stack<\/strong> containing more ROP gadgets.<\/p>\n\n\n\n
Conclusion<\/h4>\n\n\n\n