Hacker Hurdles: DEP & ASLR

This is the first installment in a new series that I am calling "Hacker Hurdles." These are things, methods, techniques that make our job as hackers more challenging and difficult. Don't misunderstand me, these items don't make our task impossible, but rather more challenging and, therefore, more gratifying when we are successful.

One of the most important new hurdles for hackers is DEP and ASLR. Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) are designed to prevent hackers from being able to do "remote code execution." We as hackers know this as "pwning" the box.

Buffer Overflows

Most often, to execute remote code or hack a system, we need to overflow a buffer (look for my upcoming series on buffer overflows) in order to insert our own malicious code into the buffer and then get a command shell or meterpreter prompt. The meterpreter prompt, for instance, is the malicious code we insert into the buffer and then the CPU executes it, rather than the normal or non-malicious code.

DEP is designed to use (execute) only code in a particular part of memory that is designated as the executable area. As you know by now, CPUs are presented with both data and commands. Very often, if we can inject commands where the system was expecting data, we can get the CPU to run them. A good example of this is SQL Injection. In SQL Injection, we enter SQL commands into a web form where we should be entering data, and the commands are then sent back to the CPU and executed.

How DEP Works

The idea behind DEP is that legitimate code would be in the executable area of memory and data (and presumably, malicious code entered as data) would be in the non-executable area. In this way, only legitimate code would be executed and run by the system, thereby preventing hackers from executing their own code and owning a system.

If executable code were entered by hackers through data inputs, it would land in the non-executable area of memory and thereby rendered ineffective. DEP was first introduced in Linux in 2004, in Windows XP SP2 in 2004, and in Mac OS X in 2006. It is part of the increasing hardening of commercial operating systems we have seen in recent years.

DEP can be enforced in either hardware or software. When enforced in the hardware, there is a NX bit set that says that this code in memory should NOT be executed. For those of you who have some experience with Metasploit, you might have noticed that some payloads are designated as NX. This means that they can be used with DEP in place and the NX bit set.

Overcoming DEP

Although this strategy is ingenious and makes the hacker's job more difficult, it is not impossible to overcome. The key is to find a function with a buffer that does execute in the executable area of memory and then use that buffer's address space to execute the remote code.

For example, about one year ago, in August 2013, an exploit (CVE-2013-3893 or MS13-080) was found in the wild that worked well on Windows 7 systems with Internet Explorer 6 through 11 and Office 2007 or 2010 installed. This exploit used Microsoft Office's Help Services address space (which is marked as executable) to run its malicious code.

DEP and ASLR are ingenious attempts to keep the hacker from executing their code on remote systems, but it also demonstrates that there is no unhackable system. Given enough time, skill, and knowledge, ALL systems are hackable. The key is to learn and train.

It is up to you to take the time to learn and practice, and Null Byte is the place to do that, so keep coming back, my novice hackers!