4

When doing exploit development, the process always relies on memory address from the victim's machine.

As an exploit developer, you will have to setup an environment of attacker\victim machines and try on it. The main leads for the exploit developer in his journey toward getting a shell from the vulnerable app are the memory address (DLLs and buffer locations mainly) which he gets from attaching the app to a debugger (usually pointed to by CPU registers such as EIP , ESP , etc).

This is good if the final goal is to make a proof of concept code to prove that this app is vulnerable. However,as far as i know, those address are not permanent and can change from machine to machine. If you're doing black box Penetration Test for a company, you wont be able to attach a debugger to their application in order to get the right addresses to jump to. And the same applies for public exploits from exploit-db because most of the exploits there need some fixing regarding addresses and offsets.

So my question is: how does a penetration tester benefit from writing such exploits (or downloading one from exploit-db) as a penetration tester not as an exploit developer?

mcgyver5
  • 6,807
  • 2
  • 24
  • 45
HSN
  • 968
  • 5
  • 14
  • 1
    Probably should specify that you are talking about memory addresses rather than IP addresses to reduce confusion – mcgyver5 Mar 05 '16 at 13:55
  • 1
    It isn't always a memory address thing. You don't need to bypass ASLR or DEP to exploit a web application in most cases. You merely need to find an exploit which allows for eventual remote code execution. – Mark Buffalo Mar 05 '16 at 17:39
  • I think the question should say "When doing exploit development _involving shellcode_, the process always relies on memory address from the victim's machine." instead but I'm afraid this would change the meaning of the question too much. – mcgyver5 Mar 05 '16 at 17:59
  • @mcgyver5 I think there are shellcode attacks that don't rely on memory attacks. Eg: some PHP attacks – Neil Smithline Mar 05 '16 at 18:26

2 Answers2

7

The change of addresses on every boot is called Address Space Layout Randomization (ASLR). Together with Data Execution Prevention (DEP), ASLR is one of the most effective security control against memory corruption exploits. Read the excellent answers at How Do DEP and ASLR Works. However, when buffer overflow exploits are created which targets anything above Windows XP (practically everything nowadays), then ASLR is bypassed using a few techniques. The most common one is to transfer the code execution to a non-ASLR enabled module that is loaded at fixed or predicted address. Majority of the IE exploits that target IE8 and IE9 uses one of the two modules (MSVCR71.dll and HXDS.dll) since both of these are non-ASLR and are loaded in the IE process (either by default or can be triggered easily).

Most of the flash exploits uses a technique where length of the vector array is overwritten and more data is read than intended. When the attacker is able to read arbitrary length data inside the exploited process memory, it can be used to find addresses of common DLLs from which ROP gadgets could be constructed. You can find further details in the excellent paper from Haifei Lei here. If you want to read some code that is able to bypass ASLR, take a look at the exploit code used by Metasploit here.

In short, ASLR together with DEP is an excellent mitigation. However, techniques are there to bypass it in certain cases for reliable exploitation.

Community
  • 1
void_in
  • 5,541
  • 1
  • 20
  • 28
3

You are asking how shellcode can defeat address space layout randomization but this isn't immediately clear from the way you worded your question. The art of "Return Oriented Programming" (ROP) has evolved to meet this challenge. The goal of ROP is to make sure the return address for any code execution is to an address space that has been pre-approved for execution because it lays in the address space used by one or more modules (or "gadgets" as they are called in ROP language) that is already part of the original program that has been exploited or in a library that can be legitimately called by the exploited program. If the initial program and the associated libraries are placed in a random location, the random location will need to be discovered. Here, for example, are methods to bypass ALSR:

  • Target non-ALSR modules. Some software is not compiled to obey ALSR and won't respect it. Many of the attacks on the JRE6 browswer plugins relied on this. source
  • Finding initial address of the executable and inferring the rest. For example, this Adobe Reader exploit finds the initial address and uses the ability to manipulate pointers and then "read the vtable" for memory locations and so free itself from hard-coded memory locations. That is, it can rely on relative memory locations once this is done.

When doing exploit development, the process always relies on memory address from the victim's machine.

That initial statement is wrong. Not all exploits developed for Metasploit or listed in exploit-db depend on the ability to execute shellcode. Maybe you were only asking about these types as you mentioned a debugger, but just in case, consider the following exploit from exploitdb:

https://www.exploit-db.com/exploits/39515/ no memory locations involved. Metasploit will use an unauthenticated file upload feature to upload a JSP file which you can then connect to and issue commands to the system.

mcgyver5
  • 6,807
  • 2
  • 24
  • 45