Being able to write your own hacking tools will be what separates the script kiddies via the legendary hackers. While This specific can take many forms, one of the most coveted skills in hacking will be the ability to dig through the binary files of a program in addition to identify vulnerabilities at the lowest level. This specific will be referred to as binary exploitation, in addition to today we’re going to check out a tool known as Protostar.
What will be Protostar?
Protostar will be a vulnerable virtual machine via https://exploit-exercises.com. This specific website hosts several virtual machines in which focus more on manual exploitation. Kiss Metasploit in addition to exploit-db goodbye, you’re mind will be the only exploit database at your disposal. Don’t be scared though, This specific will be a very Great thing!
Protostar forces you to genuinely think in addition to puts your logic in addition to reasoning skills to the test. In my personal opinion, the item strikes the perfect learning curve balance. Keep in mind in which you’ll need some basic knowledge of a scripting language to go through Protostar smoothly. In our example today we’ll be using python. Let’s dive right in!
Step 1: Downloading Protostar
In order to download Protostar, we’re first going to need to browse to the downloads page on exploit-exercises.com
Click on the link titled “Protostar Google Drive directory”. As the name implies, the link will take you to the VM in Google Drive. Download the .ISO file via there. The download will be 274 MB, so the item isn’t little, however the item isn’t terribly large either.
Step 2: Setting Up Protostar in VirtualBox
In order to run a virtual machine, we need a virtualization environment. In This specific tutorial, we’ll be using VirtualBox. You can download in addition to install VirtualBox here. Protostar can also be run using VMWare Workstation Player if you prefer in which piece of virtualization software instead. We won’t cover setting Protostar up with VMWare here, though.
In order to setup Protostar, we need to open VirtualBox in addition to click the “brand-new” button within the upper left-hand corner.
This specific will trigger a brand-new window to open in which will ask for the name, operating system type, in addition to operating system type. You can name the VM whatever you want. I choose to name mine Protostar. Select “Linux” for the type of OS. The type you pick doesn’t genuinely matter, as long as you use the 32-bit type of whatever Linux flavor you pick. I used 32-bit Ubuntu in order to set up the VM.
Clicking next will start a list of several options for the brand-new machine. All of the default settings will work just fine, so you can click right through This specific.
Once we have created the virtual machine, we need to mount in addition to boot the .iso file as a LiveCD to get Protostar up in addition to running. To do This specific, click on the “Settings” button within the upper left corner. A brand-new window will pop up with several options listed along the side. Click on the “Storage” option. Select the optical drive by clicking on the CD icon within the middle of the window, in addition to then select the file you want to mount by clicking the CD file on the far right side. Once This specific will be done the name of the image file should appear under the optical drive.
currently we can exit out of the settings menu in addition to start up Protostar!
Step 3: Connecting to Protostar via SSH
Start up the Protostar VM by clicking the green arrow on the VirtualBox homescreen. Once the VM will be up in addition to running, we can connect to the item via SSH. This specific can either be done within the host Operating System (the OS your computer runs), or with another virtual machine. The below post offers some advice on how to get started out with SSH on different platforms if you’ve never used the item before.
In This specific tutorial, I’ll be using PuTTY on Windows. Depending on the software you use, the steps needed to login will vary. Across the board, however, you’ll need to know the IP address to connect to in addition to the username in addition to password of a local account to login as. within the case of Protostar, we login with the username “user” in addition to the password “user”.
Step 4: Identifying & Exploiting a Stack Overflow in stack0
The nice thing about Protostar will be in which the item includes the source code for all of the levels on the website. While This specific may not always be available in real life, the item’s great to have while beginning to learn binary exploitation. All of the code will be written in C, however, so the item may be Great to run through a quick video or article about basic syntax of the C language.
Let’s take a look at the source code for the stack0 level:
We can identify two variables in This specific program, an integer called modified, in addition to a string of characters called buffer. The goal of the level will be to overflow the “buffer” variable creating sure in which we change the value of the “modified” variable.
For those unfamiliar with C, there are two things to note. The keyword “volatile” used when declaring the modified variable tells the compiler in which the variable can change at any time without action being taken by the code nearby. If you are unaware, the compiler will be a piece of software which translates the C code written here into a machine-readable code in which can be executed. Every programming language carries a compiler.
Looking at the rest of the program, the item looks like the program will ask for input in addition to store whatever the user gives within the buffer variable. After in which, there’s an if/else statement in which checks to see whether or not modified still equals zero. If the item does not, then we’ve caused a stack overflow in addition to completed the level.
The last thing to note will be the declaration of the buffer variable. The “” means in which the compiler will allocate 64 bytes of data due to This specific variable in memory. however what happens if the variable will be bigger than 64 bytes? Let’s take a look!
The tool in which will be going to help you the most when the item comes to learning binary exploitation with Protostar will be the gdb debugger. This specific program will be going to let us step through execution of our vulnerable programs in addition to look at each individual address of memory creating sure in which we can understand what will be going on. While we’ll cover some of the more useful commands here, a complete guide to gdb can be found within the online documentation
stack0 will be located at /opt/protostar/bin/stack0, so let’s move into in which directory by typing
Before we jump into gdb, let’s first run the program to see what happens by typing
As we saw within the source code, the program takes user input in addition to then checks to see whether or not the “modified” variable was in fact modified or not. the item’s a very simple program, however the item will serve as a Great example.
currently in which we know what we’re dealing with, let’s run the program inside gdb. To do This specific, we run the following command:
This specific will pass the stack0 program to gdb. You should see the following in your terminal:
Instead of the typical “$” indicating we’re in a linux shell, we can currently see in which we’re inside the gdb debugger by the “(gdb)” sequence at the bottom of the screen. via here we can type a variety of commands. The first thing we need to do will be set a break point. This specific will stop the flow of execution at a particular point within the program, allowing us to examine the contents of memory right at in which point.
Looking at the source code again, the item seems like stopping execution right before line 13 runs might be a Great idea. To set the break point, we’ll type
the item will be worth noting in which specifying a line of code for gdb to break at isn’t always possible. A special flag has to be set when the program will be compiled to enable This specific. Thankfully, in which flag will be set for all of the challenges in Protostar, so we don’t have to worry about reverse engineering or looking at assembly code — yet.
Once we hold the break point set, all we have to do will be type run to start program execution. In This specific case, we’ll be asked to enter some input before the break point occurs. An easily identifiable input string will be “AAAA”. Once we’ve entered This specific string, we’ll hit the break point.
currently in which program execution has stopped, let’s examine memory. The main part of memory in which we’re concerned with will be the stack. The stack keeps track of local variables in addition to instructions for the function in which will be currently running. Each time a function will be called, a brand-new “stack frame” will be added to the stack, in addition to each time a function finishes execution, in which stack frame will be removed via the stack. The address of the current stack frame will be held in a register referred to as ESP, or the stack pointer.
Our two variables, modified in addition to buffer, are local variables, so they will be located in a stack frame. By finding the location of the stack pointer, we can find these variables in memory. To do This specific, we are going to type the following:
I know in which command seems pretty arcane, so let’s break the item down.
The term “x/32x” refers to the examine command in gdb. This specific command enables us to look at individual addresses of memory. By default, examine only looks at 4 bytes (or 1 ” double word”) of memory at a time. After we initially call examine with the first “x”, the “/32x” tells gdb in which we want to examine 32 double words or 128 bytes of memory. The second “x” at the very end tells gdb we want to view the memory in hexadecimal form.
We could try to view the memory as strings or integers, however because we don’t know what type of data the entire stack frame will be, the item wouldn’t make much sense. Finally, “$esp” tells gdb in which we want to examine the memory starting at the address of the stack pointer. The output of This specific command should look something like what you see below.
currently we see a big chunk of memory. Each section represents four bytes of data, with each byte being represented by a 2-digit hexadecimal number. The hexadecimal numbers on the far left-hand side are the addresses of the first pieces of data in each row. For instance, the memory address 0xbfffffc50 contains the value 6c. currently you might be saying to yourself, isn’t the first piece of information bf? Actually, the item isn’t. Each 4-byte double word starts with the last byte in addition to works backward. So the actual order of the first two double words might be 6c fc ff bf 01 00 00 00.
Taking a closer look at the memory, we see one chunk of data in which doesn’t look like the others — a series of 4 bytes each containing the value 41. If we were to examine in which address as a string, we might see in which these are the four A’s we typed in when we first ran the program.
The buffer variable was easy to find because the pattern was so recognizable. The same will be not true for the modified variable. In This specific chunk of the stack we see 2 double words that has a value of zero, in addition to 6 additional bytes in which are also equal to zero. Luckily, there’s a command we can use to find the address location of a variable:
info address modified
Running in which command gives the following output:
The output tells us in which the modified variable will be at frame offset 92. This specific means the variable will be located at $esp (the address of the beginning of the stack frame) plus 92.
Hopefully you’re starting to see the bigger picture currently. Because the buffer variable comes before the modified variable on the stack, we can flood the stack frame with more in addition to more characters until the item overflows into the modified variable.
We can use gdb to do hexadecimal math to figure out how many characters we’ll need using the following command.
p 0xbffffcac – 0xbffffc6c
The “p” will be short for print. The output “$1 = 64” tells us in which there are 64 bytes between buffer in addition to modified. Don’t worry about the “$1” too much. the item’s just a temporary variable name in which gdb assigns the output in addition to doesn’t concern us right currently.
currently in which we know how many characters we need to complete This specific challenge, let’s write the exploit code.
Step 5: Writing the Exploit
We’ll be writing the exploit in python, however first we have to change directories, because we don’t have write permissions within the “/opt/protostar/bin/” directory. Let’s return to our home directory by typing the following.
When you don’t specify a directory to move to, cd just assumes in which you want to go back to your home directory.
Let’s open up a brand-new file in nano with the following command.
Let’s walk through the program line by line:
At the very top of our program, This specific line tells Linux in which when the item tries to execute the file, the item should do so with python. This specific isn’t necessary to the program, however the item allows us to run the program like a normal executable instead of typing “python exploit.py”. the item’s genuinely more a matter of personal preference.
We need the subprocess module in order to correctly communicate with the program. If the program took a command line argument, all we might have to do was call the program in addition to pass the argument as a variable.
Unfortunately, This specific will be not the case. Since the input will be taken inside the program, we need a way to pass input to the program. The “Popen” function will open a process with the specified program. PIPE will be a special value in which indicates in which a pipe to the standard input stream should be opened.
The “payload” variable will be where we are going to build the exploit itself. In This specific case, the payload will consist of the string “A” multiplied 65 times. This specific means 65 A’s will be passed to fill up the entire 64 bytes of data allocated to the buffer variable, in addition to then overflow into the modified variable which will be right next to “buffer.”
Let’s save the program in addition to test our exploit! In nano, type Ctrl + O to save the program. Once in which’s done, we’ll need to modify the file permissions to make the item executable by typing chmod +x exploit.py.
Finally, to test the exploit, let’s run the exploit with ./exploit.py.
Bingo! The program detects in which the “modified” variable has been modified. With our exploit, we changed the modified variable in addition to beat the level.
via here, there are 6 more levels on stack overflows included in Protostar. There’s also 5 levels teaching format string vulnerabilities, in addition to another four levels teaching heap overflows, among others.
While This specific tutorial hasn’t covered all of the topics needed to solve those levels, the item has given you the foundations you need. I’ve learned more about binary exploitation by playing with gdb then anything else. via here, I encourage you to try the rest of the Protostar challenges on your own. Whenever you get stuck, do some googling, find some Great resources in addition to grind through the challenge.
The more work you do to reach a solution, the more you will have learned in finding the item.
Thank you so much for reading! Comment below with any questions, or contact me via Twitter @xAllegiance.
Screenshots by Allegiance/Null Byte