Bypassing ASLR and DEP under Windows

[ionut97]

More recently I have researched methods on bypassing two security protection mechanisms under windows that have proven quite difficult. Whist this is nothing new, I will provide the understanding I have of the techniques and show you a brief demonstration of the approach I took. We will discuss this techniques in relation to stack based buffer overflows only for now. What is interesting is that each one protection mechanism individually are not difficult to bypass, just when they are combined together we are presented with a difficult hurdle. Lets investigate why, by explaining what the security mechanisms actually do and then using a proof of concept to help readers visualize the process.

What is ASLR?

Address space localization randomization is nothing more than randomizing the high byte order of any address within the PEB (process environment block). Generally under windows XP and prior versions we see addresses that never change under the windows libraries. So for example the address from kernel32.dll for WriteProcessMemory() will always be at 0x7C802213. But of course, newer versions of windows have changed this, so that now an address will be randomize like this: 0xXXXX2213 (The offset will be different too under Vista and 7, this is just an example).

One important point too make is that we will always know the offset too where the functions lye in any given module. This is known as the relative offset, and will come into play when we attempt to bypass this security. Ok so as you can see, in a typical EIP or SEH exploit, we would not have too many dramas bypassing this as a lot of modules that come with applications are not using ASLR and essentially we could just find an instruction that will take us too our attacker controlled buffer. However if our target application came with no additional modules, or they were all ASLR protected, or loaded with a dynamic base (using nulls) then we would have serious issues bypassing this technology. We are generally more than unlikely too see this situation due to compatibility issues.

ASLR Bypass techniques:

Bruteforcing (as long as the parent process spawns child processes). Generally, this would only be possibly in server environments. Entropy is small in 32bit processors.

Using a call to a DEP bypassing function from within a non ASLR module. This way we dont even have to know the address at all, we can rely on code that comes inside the applications modules.

Leak an pointer to a windows modules from the stack or heap memory. As long as we can create the relevant chains, then this process works.

While this is nice, we will face another hurdle. Hardware enforced data execution prevention, that will stop the execution of attacker supplied code in memory.

What is DEP?

DEP is a CPU flag set to indicate that the NX is on (non-executable). Any attacker supplied code in either the heap or stack memory will not be executed and cause an access violation. For an attacker to bypass this issue they must execute a ret2libc type exploit where the attacker uses system API's to mark memory pages as executable or move the shellcode to an executable region and jump on it. In a stack based exploit, this will require the attacker to use a technique called Return Oriented Programming (ROP). This will allow an attacker to continually return to the stack and execute the next instruction until the shellcode is executed.

DEP Bypass techniques using windows API:

WriteProcessMemory()

WinExec()

VirtualProtect()

The three API functions above, will enable the attacker to control the execution of shellcode. I will not go into detail about these functions as there is already a lot of material on the subject. Its important to point out that WinExec() will not execute a traditional payload and you will have to be creative with this technique if that's all you can use.

Limitations:

Less character filtering the better (limited character set means limited ROP chains.)

Need lots of space. Although this is not ALWAYS the case, generally speaking we will need a decent amount of room for generating the stage 0 shellcode (the ROP chain).

We need at least one library that is not ASLR protected (That also does not have a randomized base (although this will make is VERY hard, still not impossible)).

Due to these limitations alone, many applications under the new Windows OS's will not be exploitable (assuming DEP is on). Unicode vulnerabilities, ASCII vulnerabilities, and Vulnerabilities where one no additional libraries can be provided will not work.

Putting it all together, visualize!

First and foremost, you need to be able to 'visualize' how the exploitation will pan out. You need a plan from start to finish and be willing to change your plan completely is need be. First of all, get yourself some ROP chains either by using !pvefindaddr or by manually searching. Once you have that, visualize this process:

Find an address to kernel32.dll (Leak, brute-forcing or call to windows API from the applications non ASLR modules. etc)

Store the address somewhere

Calulate the dynamic arguments for your windows API call (that will be used to bypass DEP).

Place them carefully either in the Data segment or the stack segment

Align them correctly and call the function

The handler will return us to the location we specified (unless your using the WriteProcessMemory() technique that patches itself.)

Blaze DVD (.plf) file local buffer overflow PoC Vid download here

Sursa:

https://net-ninja.net/article/2010/Jun/17/bypassing-aslr-and-dep/