Being able to write your own hacking tools is actually what separates the script kiddies via the legendary hackers. While This specific can take many forms, one of the most coveted skills in hacking is actually the ability to dig through the binary files of a program along with identify vulnerabilities at the lowest level. This specific is actually referred to as binary exploitation, along with today we’re going to check out a tool known as Protostar.
What is actually Protostar?
Protostar is actually a vulnerable virtual machine via exploit-exercises.com. This specific website hosts several virtual machines which focus more on manual exploitation. Kiss Metasploit along with exploit-db goodbye, you’re mind is actually the only exploit database at your disposal. Don’t be scared though, This specific is actually a very Great thing!
Protostar forces you to truly think along with puts your logic along with reasoning skills to the test. In my personal opinion, which strikes the perfect learning curve balance. Keep in mind 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!
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 is actually 274 MB, so which isn’t tiny, yet which 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 along with install VirtualBox here. Protostar can also be run using VMWare Workstation Player if you prefer 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 along with click the “brand new” button from the upper left-hand corner.
This specific will trigger a brand new window to open which will ask for the name, operating system type, along with 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 truly 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 along with boot the .iso file as a LiveCD to get Protostar up along with running. To do This specific, click on the “Settings” button from 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 from the middle of the window, along with then select the file you want to mount by clicking the CD file on the far right side. Once This specific is actually done the name of the image file should appear under the optical drive.
currently we can exit out of the settings menu along with 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 is actually up along with running, we can connect to which via SSH. This specific can either be done from the host Operating System (the OS your computer runs), or with another virtual machine. The below post offers some advice on how to get commenced with SSH on different platforms if you’ve never used which 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 along with the username along with password of a local account to login as. from the case of Protostar, we login with the username “user” along with the password “user”.
Step 4: Identifying along with Exploiting a Stack Overflow in stack0
The nice thing about Protostar is actually which which includes the source code for all of the levels on the website. While This specific may not always be available in real life, which’s great to have while beginning to learn binary exploitation. All of the code is actually written in C, however, so which 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 along which has a string of characters called buffer. The goal of the level is actually to overflow the buffer variable to ensure we change 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 which the variable can change at any time without action being taken by the code nearby. If you are unaware, the compiler is actually a piece of software which translates the C code written here into machine-readable code so which can be executed. Every programming language includes a compiler.
Looking at the rest of the program, which looks like the program will ask for input along with store whatever the user gives from the buffer variable. After which, there’s an if/else statement which checks to see whether or not modified still equals zero. If which does not, then we’ve caused a stack overflow along with completed the level.
The last thing to note is actually the declaration of the buffer variable. The “” means which the compiler will allocate 64 bytes of data due to This specific variable in memory. yet what happens if the variable is actually bigger than 64 bytes? Let’s take a look!
The tool which is actually going to help you the most when which comes to learning binary exploitation with Protostar is actually the gdb debugger. This specific program is actually going to let us step through execution of our vulnerable programs along with look at each individual address of memory to ensure we can understand what is actually going on. While we’ll cover some of the more useful commands here, a complete guide to gdb can be found from the online documentation
stack0 is actually located at /opt/protostar/bin/stack0, so let’s move into which directory by typing
Before we jump into gdb, let’s first run the program to see what happens by typing
As we saw from the source code, the program takes user input along with then checks to see whether or not the “modified” variable was in fact modified or not. which’s a very simple program, yet which will serve as a Great example.
currently 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 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 is actually set a break point. This specific will stop the flow of execution at a particular point from the program, allowing us to examine the contents of memory right at which point.
Looking at the source code again, which seems like stopping execution right before line 13 runs might be a Great idea. To set the break point, we’ll type
which is actually worth noting 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 is actually compiled to enable This specific. Thankfully, which flag is actually 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 is actually 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 is actually “AAAA”. Once we’ve entered This specific string, we’ll hit the break point.
currently which program execution has stopped, let’s examine memory. The main part of memory which we’re concerned with is actually the stack. The stack keeps track of local variables along with instructions for the function which is actually currently running. Each time a function is actually called, a brand new “stack frame” is actually added to the stack, along with each time a function finishes execution, which stack frame is actually removed via the stack. The address of the current stack frame is actually held in a register referred to as ESP, or the stack pointer.
Our two variables, modified along with 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 which command seems pretty arcane, so let’s break which 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 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, yet because we don’t know what type of data the entire stack frame is actually, which wouldn’t make much sense. Finally, “$esp” tells gdb 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, which isn’t. Each 4-byte double word starts with the last byte along with 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 which doesn’t look like the others — a series of 4 bytes each containing the value 41. If we were to examine which address as a string, we might see 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 is actually not true for the modified variable. In This specific chunk of the stack we see 2 double words which has a value of zero, along with 6 additional bytes 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 which command gives the following output:
The output tells us which the modified variable is actually at frame offset 92. This specific means the variable is actually 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 along with more characters until which 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” is actually short for print. The output “$1 = 64” tells us which there are 64 bytes between buffer along with modified. Don’t worry about the “$1” too much. which’s just a temporary variable name which gdb assigns the output along with doesn’t concern us right currently.
currently 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, yet first we have to change directories, because we don’t have write permissions from 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 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 which when which tries to execute the file, which should do so with python. This specific isn’t necessary to the program, yet which allows us to run the program like a normal executable instead of typing “python exploit.py”. which’s truly 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 along with pass the argument as a variable.
Unfortunately, This specific is actually not the case. Since the input is actually 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 is actually a special value which indicates which a pipe to the standard input stream should be opened.
The “payload” variable is actually 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, along with then overflow into the modified variable which is actually right next to “buffer.”
Let’s save the program along with test our exploit! In nano, type ctrl + o to save the program. Once which’s done, we’ll need to modify the file permissions to make which executable by typing chmod +x exploit.py.
Finally, to test the exploit, let’s run the exploit with ./exploit.py.
Bingo! The program detects which the “modified” variable has been modified. With our exploit, we changed the modified variable along with beat the level.
via here, there are 6 more levels on stack overflows included in Protostar. There’s also all 5 levels teaching format string vulnerabilities, along with another four levels teaching heap overflows, among others.
While This specific tutorial hasn’t covered all of the topics needed to solve those levels, which 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 along with grind through the challenge.
The more work you do to reach a solution, the more you will have learned in finding which.
Thank you so much for reading! Comment below with any questions, or contact me via Twitter @xAllegiance.
Screenshots by Allegiance/Null Byte