This is the third challenge of the P0wn3d series. To follow the entire series, since I won’t explain everything again, here are the links: (P0wn3d, P0wn3d 2). Since this is a ret2win challenge, it is a good practice to check the security flags using checksec:
CheckSec
We have Partial RELRO, meaning only the Global Offset Table (GOT) is partially protected. There’s no stack canary, so we don’t have to worry about potential Buffer Overflow issues. Next, we have NX enabled, which means the stack is non-executable. Finally, No PIE means the binary has fixed memory addresses, and Stripped No, meaning the binary has not been stripped of debugging symbols. Let’s move on to the analysis of the attached files, as we were also given a C source code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
voidget_flag(void){char*args[]={"/bin/cat","flag.txt",NULL};execve(args[0],args,NULL);}intmain(void){charbuf[32];ignore();/* ignore this function */printf("Now this is an original challenge. I don't think I've ever seen something like this before\n");sleep(2);gets(buf);puts("Drumroll please!");sleep(2);return0;}
As we can see, the get_flag() function is present to print the flag, but if we pay attention, it is not called! However, as with the other challenges, we have a Buffer Overflow. The buf variable has a 32-byte buffer, but the gets(buf) function is unsafe because it doesn’t check the length of the input. This allows us to write beyond the 32 bytes allocated for buf, overwriting the saved return address in the stack. So once we exceed the buffer size, we will cause a buffer overflow, which overwrites the stack registers. When a function is loaded, its return address is passed, which “remembers” where to return to after the function execution, as it is located in a different part of memory. The problem is that with a buffer overflow, this address can be overwritten…
🔬 Vulnerability Analysis
Potential Vulnerabilities
Buffer Overflow
🎯 Solution Path
Exploitation Steps
Initial setup
The RBP (Return Base Pointer) register is 8 bytes and is located before the saved return address, so we need to craft a payload that fills the buffer of the buf variable (32 bytes) and then also fills the RBP. What happens if we set the saved return address to that of the get_flag() function? Exactly… the program, instead of terminating, would jump to the get_flag() function and execute it. This way, we can obtain the flag!
Exploitation
So the first thing I do is find the memory address of the get_flag() function, which we’ll need to overwrite the saved return address. I can do this directly in gdb with p &get_flag:
get_flag Address
Or with objdump by running objdump -D <filename> | grep "get_flag". As we can see, the address is 0x4011a5. Now that we have the address and know that it will remain the same on the server due to No PIE, we can construct the final payload consisting of 40 junk bytes (32 for the buffer + 8 for the RBP) + the get_flag address. I did this directly in the exploit, and when I ran it, I found the flag.
🛠️ Exploitation Process
Approach
The exploit connects to the server and sends A*40 to fill the buffer of the buf variable, then appends the address of the get_flag() function to overwrite the return address and execute the get_flag() function, thus retrieving the flag.
