Exploitation Protections From Old To Bleeding Edge pt 3
Here we are at the third and final part of this exploit mitigation series. this is kind of a special one, as it talks about some of the most bleeding edge protections on the Windows environment, the exploit guard protections.
Without further ado, lets talk about this “category” of protections, the majority of the mitigations uses one technique widely known in the pentesting world: hooking.
Application hooking or simply hooking is the art of interrupting the execution of a function in execution time and changing the output or the code inside with your “hooking code” that, in this case, are a series of checks done by exploit guard before passing the control to the desired function.
There are some protections that work as system level mitigations (not hooking), that are, at the moment of this article:
- CFG
- DEP
- Mandatory ASLR (disabled by default)
- Bottom-up ASLR
- High entropy ASLR (HEASLR)
- SEHOP
- Validate Heap Integrity
As some of the protections aforementioned were already covered at the other parts, I’ll be skipping those.
I’ll begin by describing a mitigation that is from the EMET framework, so not quite yet the exploit guard protections, but as it’s windows specific and you could come across that one in some older systems, I decided to talk about it.
Heap Spray Protection (HSP)
This one, (obviously) aims at heap spray attacks, those are known to target a lot of applications, mainly browsers. It’s not the focus of this paper, but this attack is directly linked to ASLR and heap allocations.
And by making the heap spray technique the attacker makes repeated large allocations in memory containing the arbitrary code and, eventually, this allocation will be reached.
The protection works by pre-allocating areas of addresses those attackers rely during a heap spray attack.
This mitigation was deprecated as the new HEASLR came to make it unnecessary.
Export Address Table Filtering (EAF & EAF+)
This one Aims to defeat the shellcodes that iterates through EAT (Export Address Table) of kernel32.dll and ntdll.dll, that are nearly all of them, as the shellcode needs to resolve the location of it’s functions, and to do this, the EAT needs to be consulted.
To defeat those shellcodes, EAF works by monitoring the “AddressOfFunctions” field on the EAT and creating an exception handler. Hardware breakpoints are set on the EAT of the DLLs mentioned. By doing this when the hardware breakpoint is reached, if the iteration has come from a shellcode, an exception (setted by the EAF) is thrown.
EAF+ is the EAF on steroids, where yo can specify modules used in memory corruption bugs and deny the access to write and read the EAT and the IAT ( Import Address Table) of common DLLs.
The EAF and EAF+ shown here was the EMET version of the EAF and EAF+, the exploit guard version of this mitigation, adds the protection to the CALL instruction as it cannot be used if it’s not from the code segment itself, such as the heap.
Import Address Table Filtering (IAF)
The IAF is the protection that targets the IAT (Import Address Table) rather than the EAT. IAT is like the GOT (Global Offset Table) from linux. They store the resolved address of dynamically linked functions. And by targeting this tables (they are writable) the attacker could overwrite an entry to achieve code execution.
And the protection itself acts like the. checking if the function called listed in the IAT reside within the allocated memory.
Mandatory Address Layout Randomization (MASLR)
This one is easy to understand, as it only forces an option to make the application rebase itself on memory.
There’s an option on Visual Studio called /DYNAMICBASE when you compile a DLL, what this does is basically ignores this option and make the ASLR active anyway.
This protection was made to mitigate the problem that if just one DLL is not ASLR enforced, the whole protection would serve to nothing.
Read More:https://msrc-blog.microsoft.com/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/
Bottom-Up Address Space Layout Randomization (BASLR)
This protection works alongside the MASLR, what BASLR do is basically improve the randomization by choosing a random number from 0 to 256 and blocks that number of 64Kb allocations from the compiler base address up until that point. And this random number will change each time there’s a process invocation.
Block Remote Images Or Load Library Protections
As you will see a lot of exploit guard protections aim to defeat ROP (Return Oriented Programing) and Ret to libc attacks, this one is one of those controls. How attackers commonly use ROP is by using non-rebased modules into the application that they can use static addressing to achieve their goal.
Block remote Images work by blocking modules from being loaded within a DLL via UNC (Universal Naming Convention) file paths(eg. AttackersWebsite.com/evil.dll).
Read a bit more (not much about this subject): https://www.microsoft.com/security/blog/2017/10/23/windows-defender-exploit-guard-reduce-the-attack-surface-against-next-generation-malware/
Validate Heap Integrity
there are two types of heap allocators at userland, the frontend heap allocator, and the backend heap allocator, the first was launched at windows vista with the name of lookaside lists, they work similarly to the previously mentioned LFH, by randomizing the allocation from free lists and by encoding chunk metadata in the headers.
read more: https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/using-lookaside-lists
Arbitrary Code Guard (ACG)
Better known by the name of MemProt given by EMET, this protection aims to protect against ROP attacks, said that, where you guys think they aimed? the DEP-killers functions of windows, VirtualAlloc and VirtualProtect :(.
Yeah, the party is over for those, they evaluate the address passed to the functions and other similar functions to ensure that they are not setting the execute permission on an existing or new allocation.
Luckily for us Project Zero from google, has made an extensive research on the topic and found a way to bypass that one, the name of the beast is Ivan Fratric and you can read the article here : https://github.com/googleprojectzero/p0tools/blob/master/JITServer/JIT-Server-whitepaper.pdf
Read more :https://blogs.windows.com/msedgedev/2017/02/23/mitigating-arbitrary-native-code-execution/
Validade API Invocation
As everybody knows, there is the CALL instruction in many architectures, that as the names implies, it calls functions, what not everybody knows, that after every call there must be a RET instruction, that is used to give the control to the address after the CALL what made.
Explained that, the protection, again, aiming at ROP exploits, made it in a way that functions such as VirtualAlloc and VirtualProtect could not be reached by RETs. This one is also called Caller Check in EMET.
Simulate Execution (SimExec)
This one is pretty neat as it does exacly what the name tells, it simulates the execution of several (15 on EMET and probably more on Exploit Guard) instructions looking obviously for patterns of ROP attacks (LET ROP ALONE PLZ).
As it’s known to cause problems to legal applications it’s disabled by default.
Read a bit more: https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/customize-exploit-protection
Validate Stack
Images:
https://www.thesecuritybuddy.com/vulnerabilities/what-is-heap-spraying/
https://resources.infosecinstitute.com/the-export-directory/
https://www.researchgate.net/figure/The-structure-of-the-Import-Address-Table-IAT_fig4_305755349
https://msrc-blog.microsoft.com/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/
