Series of articles to describe some of the mainstream protections used by binaries
Last updated
Hey there, Iβm Edward, Security analyst from STO, I will be talking about some modern Exploitation protections, as part of the βlessons learnβdβ from SANS 760 training course. Iβm sure if you are reading this article you must have heard about ASLR, DEP and SafeSEH, the most famous OSCP/OSCE level protections. But most of the security analysts that arenβt messing up with binary exploitation/reversing does not know some of the protections that will be listed in this article.
I will list those protections in three categories, the OS Controls, which the name already tells, that are protections imposed by the operating system, the Compile Time Controls, that are done when the binary is being compiled and Exploit Guard protections, that are the ones inherited by the EMET framework by microsoft, so Windows specific protections, some of the latest protections lie in this category.
The aim of this article is not to learn how to bypass those protections, the aim is to just briefly talk about the protections and make sure that when you are reversing something or trying to exploit a binary, you already know what you can face or what could result in an exception in the tested application.
This is the first part of a 3 parts article, that will first talk about OS Controls.
As told before, these are the operating system enforced protections, here are where the most famous ones are, so letβs list and talk a bit about them.
AKA Write XOR Execute or simply WΛX in Linux, DEP was Microsoftβs take on the linux WΛX.
DEP is a really old protection implemented in Windows XP SP2 and 2003 Server. The aim of this mainly hardware-based protection is that code shouldnβt be executed in the stack nor in the heap.
So the main mechanism to defend against code execution on those areas are that only pages explicitly marked to run codes are permitted to do so. This protection is circumvented by attacks that abuses the pages that already have the permission to run codes, like return oriented programing (ROP) and return to libc attacks.
Structured Exception Handler Overwrite Protection was a mechanism that aimed to beat SEH based exploits, and was implemented at the Windows server 2008 and Windows Vista, but was disabled by default due to problems that involved lack of applications support to the protection.
The main control that was to be implemented with SEHOP was inserting a special symbolic record at the end of the SEH chain and before passing the control to the chain of handlers, there are instructions to ensure that the symbolic record is still accessible.
Those are pretty simple, really, but extremely powerful. Were introduced in XP SP2 and 2003 Server and are very similar to the protection added to the modified version of unlink() on linux.
What this protection tries to achieve is that the pointers that are about to be unlinked are tested to ensure that they are pointing to the chunk that will be freed.
Basically thereβs an if block that ensures everything is correct and foresees that no use-after-free attacks are being held against the application. Itβs very effective against heap metadata attacks as it completely mitigates chunk FUNK/BUNK overwrites.
This protection was pretty good, at least for doubly linked lists. After that patch, attackers focused their attention on single linked lists, with attacks like Tcache poisoning and Fast Bin attacks.
This one is obviously tied to Process Evironment Block, that is a structure of data in a process that holds crucial info about that process. A curious fact about PEB is that it was always found at a specific address ( prior to XP SP2) and that made easy for attackers using techniques such as Overwriting RtlCriticalSection to be used upon the program exits.
PEB Randomization came to address this βspecific addressβ problem, and made it so that the address of the PEB could vary in 16 different positions in memory.
The problem is that it was not made with an effective randomness algorithm, and it was proved by a Symantecβs research that an attacker has 25% chance of guessing the right PEB location at first try.
Iβm sure everyone has heard of ASLR, the Address Space Layout Randomization. Introduced on Windows Vista, 7 and Server 2008.
Needless to say ASLR randomizes the image load address once per boot. Afterwords ASLR got some steroids at Windows 8/10 and Server 2012/2016, releasing the HEASLR or high entropy ASLR.
And others like Mandatory ASLR or ForceASLR and botton-up Randomization also was implemented afterwords.
Many techniques were aimed to bypass this protection, one famous attack is known as egghunting, in few words is when an attacker plants a string before the code heβs willing to execute and makes a code to find this string searching the memory in a loop.
If familiarized with ROP or JOP (Return Oriented Programming, Jump Oriented Programing) you know that stack pivoting is the key to achieve the execution of gadgets in the heap or other controlled memory segments.
The control works by verifying if the SP (stack pointer) is pointing to the stack range determined by TIB/TEB, before permitting the execution of critical functions such as the beautiful VirtualProtect(), known to be capable of defeating DEP.
Dan Rosenberg was the first to release a paper about how to defeat this protection, and itβs awesome.
Aiming at use-after-free attacks, Microsoft added a protection exclusively to IE and Edge. The mechanism was that the object allocation for those applications were not allocated on the normal heap, instead it was allocated at an isolated heap, making the replacement of freed objects a herculean task.
CFG or Control Flow Guard is yet another protection to mitigate ROP attacks, introduced on Windows 10 and back-ported to Windows 8 Update 3.
The control needs every DLL to be compiled with the protection as it adds some code. It works by creating a bitmap of all valid function entry points within the DLL compile time.
So when an indirect call is made to a protected function an exception is thrown.
Every DLL needs to have the instrumentation that CFG applies, if not, the protection is ineffective.
Maybe the newest protections that will be added to newer OS Versions. Intel came with the idea of Shadow stacks and Indirect branch tracking.
The shadow stack itself is a separate stack , and the mechanism works by making parts of the memory protected, allowing only the CALL instruction the ability to write the return addresses used in the call chain in the call stack and in the shadow stack, so the return pointer will be checked in those two stacks, if they mismatch, an exception is thrown.
Indirect branch tracking makes sure the new instruction ENDBR32 for 32 bits and ENDBR64 for 64 bits is inserted after every call instruction, and obviously, if not, an exception is thrown.
Thatβs all for part 1, in part 2 I will bring the Compile-time Controls.
Read More:
Read more:
Read More:
Read More:
Read More:
Read more:
Read more:
Read more:
