# Here we define the context of the exploit, it is for linux os and amd64 archeticture When puts function calls itself in the GOT it leaks its location in the binary which changes every time we run the program. Objdump -D bitterman -M intel | grep puts Using vim editor I started to build the exploit by importing the pwntools library and then figuring out what are the main elements for the exploit skeleton.įirst, we need to calculate the address of the Puts function call in the binary where the BOF happens.īy using objdump we can get the address of the puts function in the GOT and PLT (Procedural Link Table) of the binary. I will use python language to create the exploit for the bitterman binary and the pwntools library to construct the exploit. These are the results of pattern offset, we found that the offset where our payload will start is 152, So we have to through 152 bytes into it to overwrite RSP. We are going to examine the RSP register now to get the value stored inside it and then use this value with pattern offset to get the actual offset where the crash happens. This is much better than random garbage □ Now I will create a better pattern instead of the random garbage to enter so that we can determine the offset where the program started to crash, by using the built-in pattern create and pattern offset commands in gef we can determine the exact offsets to build our exploit. These are the information gef provided us when the program crashed, we will notice that in 圆4-bit programs the RIP register can’t be changed directly but when we look at RSP we find that it has some of the garbage we entered. To make the things clear I switched the assembly syntax to Intel instead of AT&T and started the program.Īfter entering some garbage in the message field manually (which is not the best way to do it), the program crashed because we exceeded the length of the message we chose earlier. I started by running the checksec script in gef to show what security features enabled in the binary like (NX, PIE, RELRO, CANARY, etc.) and I found only the NX is enabled which means we cannot run shellcode from the stack, that’s why we will use ROP and return2libc techniques. I’ll use gdb debugger with gef extension to help us with exploitation and start fuzzing our bitterman. Great it works as we expected it takes the name, the length of the message and the text of the message. Now that we have a good idea about what our program is doing, it is a good practice to run the program and compare what we understood from the static analysis in IDA Pro with the actual running of the binary. Here, the hacker’s sixth sense inside you should tell you that the BOF vulnerability resides here because we control the length of the input text and there is no user input sanitization. let’s continue digging and below is the disassembly of the main function of the binary.įirst the program prompts the user to enter his name, and after entering his name the program prints “Hi, ”, after that it takes the length of the message he wants to write and the text of the message itself. I opened it with IDA and it detected it as a 64-bit ELF program, that’s fine we got something to know about the binary file. So, let’s get our hands dirty and start digging in the binary, first I prefer to take a static taste of any binary I come across with IDA Pro but this is not mandatory it is a preference, other guys prefer to run the binary first directly or with a debugger. There are various techniques to bypass DEP but here we are using the ret2libc technique through leaking the address of the function of interest through GOT (Global Offset Table) and using ROP (Return-Oriented Programming). This is really was an interesting challenge, it is a classic buffer overflow vulnerability but with DEP enabled and to exploit it we need to bypass DEP (which is exploit mitigation maintained by the OS through making the stack not executable).
0 Comments
Leave a Reply. |