CS 290 Host-based Security and Malware Christopher Kruegel [email protected] Memory Corruption ExploitsAdvanced Memory Corruption Exploits • Windows shellcode • Kernel exploits and shellcode CS 290: Host-based security and malware 3!CS 290: Host-based security and malware 4 Windows Shellcode • System calls are not the answer – Native API implemented in ntoskrnl.exe and exposed via ntdll.dll – Windows system call interface (int 0x2e or sysenter) changes between versions – Windows system call interface is limited and poorly documented (no standard network calls such as open, connect, …) • Using system calls in Windows shellcode is “bad practice” – instead, use library functions (Windows API) – first, decide which functions you need – then, find their (absolute) addressesCS 290: Host-based security and malware 5 Library Functions • Which library functions can be used? • All Windows programs link against two libraries – ntdll.dll (Native API exports) – kernel32.dll (base services – processes, files, …) • kernel32.dll contains two important functions – LoadLibraryA(libraryname) – GetProcAddress(hmodule, functionname) • Enough to execute any function we need, but ... we have to find their correct addresses firstCS 290: Host-based security and malware 6 Finding Function Addresses • Addresses of library functions can be found with dumpbin – easy to do, but inflexible (non-portable) – problem is that function addresses can differ between Windows versions and service packsFinding Function Addresses CS 290: Host-based security and malware 7!Finding Function Addresses CS 290: Host-based security and malware 8!Finding Function Addresses CS 290: Host-based security and malware 9!Program sleeps for 5 seconds and then exitsCS 290: Host-based security and malware 10 Dynamic Addressing Now, we want to find function addresses dynamically – two problems need to be solved 1. Kernel32.dll is not always loaded at the same address – locate start address of kernel32.dll 2. Addresses of functions inside kernel32.dll may vary – locate our two important functions in kernel32.dllCS 290: Host-based security and malware 11 Locating kernel32 • The operating system allocates a Process Environment Block (PEB) structure for every running process – The PEB can always be found at fs:[0x30] in the process memory • The PEB structure contains three linked lists with info about loaded modules that have been mapped into process space – One list is ordered by the initialization time – kernel32.dll is always the second module to be initialized • It is possible to extract the base address for kernel32.dll from PEBCS 290: Host-based security and malware 12 Locating kernel32CS 290: Host-based security and malware 13 Locating kernel32 • Alternative ways (smaller in size) – find a pointer that points into kernel32 – possible pointers • Unhandled Exception Handler default entry (top entry located at fs:[0]) • via top of stack, referenced via Thread Control Block (TCB – fs:[0x18]) – search pages backwards in memory until you find one that starts with ‘MZ’ (actually, 64KB steps sufficient)Locating kernel32 CS 290: Host-based security and malware 14!CS 290: Host-based security and malware 15 Locating GetProcAddress • Use the image export directory of the DLL (.edata) – declares exported functions, using the following four tables: address table (relative virtual addresses – indexed by ordinal) name pointer table (pointer to strings) ordinal table (same order as name pointer table) name table (actual string data) • Algorithm to obtain address (RVA) for symbol “ExportName” i = Search_ExportNamePointerTable(ExportName); ordinal = ExportOrdinalTable [i]; SymbolRVA = ExportAddressTable [ordinal - OrdinalBase];CS 290: Host-based security and malware 16 Locating GetProcAddress • To resolve a symbol one must – search it in the name table (via name pointer table) – the corresponding entry in the ordinal table is function index – use index to retrieve the function virtual address from address table • Storing function names as strings in the shellcode is bad – takes too much space – solution: hash function names (and only store hashes in shellcode) – requires that shellcode comes with a hash functionPayloads • Once functions can be located … – (Reverse) Bindshell kernel32.dll: CreateProcessA ws2_32.dll: WSASocketA, connect, bind, listen, accept – Download / Execute kernel32.dll: CreateFile, CreateProcessA wininet.dll: InternetOpenUrlA and InternetReadFile CS 290: Host-based security and malware 17!Advanced Memory Corruption Exploits • Windows shellcode • Kernel exploits and shellcode CS 290: Host-based security and malware 18!Kernel Exploits • What types of kernel space vulnerabilities are there? – invalid (user) pointer dereference – kernel stack buffer overflows – heap (slab) overflows … • What is special about the payload? – locate other functions (making a system call is not an option) – stage standard (user mode) payload – recover to prevent kernel crash • In general, most kernel exploits require some special twist CS 290: Host-based security and malware 19!Locating Functions • Quite similar to what we have just seen – need to find exported kernel functions – typically, functions are used by kernel modules / device drivers – scan memory for known byte signature ‘MZ’ at beginning of ntoskrnl.exe system call table signature (and known offsets into table) CS 290: Host-based security and malware 20!Stager • Copy the ring0 or ring3 to a suitable location – currently loaded pages of a process – Windows SharedUserData – space between kernel stack and thread_info – unused entries in the IDT – Asynchronous Procedure Calls (APCs) CS 290: Host-based security and malware 21!Stager • Problem – sometimes, exploit happens in interrupt context – no process associated with kernel code, cannot block or sleep • Install a hook that executes payload later (in desired context) – interrupt handler – system call handler – MSR (mode specific register) – used with sysenter – saved