Exploitation Protections From Old To Bleeding Edge pt 1

Published in

stolabs

6 min readSep 21, 2020

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.

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.

DEP

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.

Image showing parts of the stack with read-write permissions and read-execute permissions

SEHOP

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.

Illustration from Microsoft showing how the mechanism works

Safe Unlinking

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.

Code used by GLIBC at 2005 to address the unsafe unlinking issue

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.

PEB Randomization

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.

ASLR

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.

ANTI ROP or Win8 ROP protection

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.

Isolated Heaps and Deferred Free

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

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.

CFI and CET

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.