Note: All the related files that are mentioned in this post can be found here.
Category: Pwn
The task:
In this challenge, we were given a zip file, contains:
- A binary we need to exploit (runs on the target server):
app.out
- Source code of this binary was also provided (
.c
,.h
files).
The extracted zip can be found at ./ctfd in this repo for further analysis.
Analysis
Libc leak(?)
The app.out
file is a pseudo-RPG game, allowing you to choose one out of 3 characters:
- Warrior
- Wizard
- Elf
Hello epic warrior, it's time to begin your quest
Choose your character:
1 - Mighty warrior
2 - Wizard
3 - Elf
Your Choice:
2
Choose your character name (limit to 12 chars)
Your Choice:
AAAABBBBB
Hello AAAABBBBB The Wizard!!!
Your health is 1200 pt.
Your shield is 400 pt.
Your strength is 200 pt.
Your lucky number is 140241813315216
You will need 2147483647 points to get the flag
Good luck, the kingdom trust you!!
You meet a Dragon!!!
AAAABBBBB
choose your move:
1 - hit
2 - protect
3 - run
Your Choice:
The ‘lucky number’(Your lucky number is 140241813315216
) appears to be a libc address leak.
Digging down the code, it was found that each game-character is a C struct of type player
.
During init_player
, there’s a variable assignment of rand
to p_player->luck
:
rand
is not actually called here, so it means the player’s lucky number 140241813315216
is the decimal value of 0x7F8C97771E90
, which is rand@GLIBC
address.
This leak will help us along the way to figure out the remote server’s libc version and calculate offsets.
log_error
If the player didn’t choose a valid option, the server will call log_error
:
This will log an error with the user input into a global variable error_log
:
All the variables above(except buff
) are located in the .bss
segment:
After we got those two things in mind, we can start pwning.
Time to pwn
Obstacle #1: Boundary check in log_error()
The boundary check here is supposed to stop logging if the player tries to overflow the log with over 1024/0x400 bytes(==the size of error_log
):
At first glance, it looks like:
snprintf
returns the size of bytes written and accumulating the result intocur += snprintf(...)
- The size of ‘how much to write’ is enforced by the 2nd parameter
sizeof(error_log)-curr
. - This is how boundaries are checked in order to toggle-off
write_to_log
and stop logging.
However, after taking a closer look at the binary, it is not the exact behaviour of snprintf
(See: Return Value):
https://www.cplusplus.com/reference/cstdio/snprintf/
If we provide a buffer with size 0x3ff
, then curr
will be 0x3ff
. But if the buffer has 0x1
bytes left available and we’re trying to write 0x3
bytes, only 1 byte will be written. But the return value will still be 0x3
.
This is the secret sauce for unlocking the overflow and bypassing the boundary check. curr
continues to accumulate and becomes 0x402
. As a result: the boundary check which verifies that curr
is not yet 0x400
will not evaluate:
while in reality: it’s already beyond that number.
Obstacle #2: We’re in the .bss
segment
Even though we got the buffer overflow, we’re not landing in a useful place like stack or heap. Instead, we are in the .bss
segment.
My first guess was to overwrite some GOT entries, but error_log
is located after the GOT. ugh, boomer.
So what CAN WE overflow?
The only things in memory after error_log
are values of curr
and write_to_log
:
pwndbg> x/gx 0x4044b0
0x4044b0 <error_log+1008>: 0x4242424242424242
0x4044b8 <error_log+1016>: 0x0042424242424242
0x4044c0 <write_to_log>: 0x0000000000000001
0x4044c8 <curr>: 0x0000000000000402
0x4044d0: 0x0000000000000000
0x4044d8: 0x0000000000000000
To overcome this, we can overwrite curr
to be a negative number -87(0xffffffffffffffa9
) in order to create a write-what-where primitive, which will land before the error_log
buffer.
Then, the next time log_error()
will be called, it will trigger a write to the GOT entry strtoul@GLIBC_2.2.5
with our user-controlled input.
Note:
curr
has an unsigned type ofuint64_t
, hence, it can’t really be negative.However, if we enter the ‘unsigned representation’ of -87(
0xffffffffffffffa9
) and add&error_log
to it = we’ll end up reaching the GOT:pwndbg> x/gx 0x4040c0 0x4040c0 <error_log>: 0x4242424242424242 0x4040c8 <error_log+8>: 0x4242424242424242 pwndbg> p/x (unsigned int)0x4040c0+0xffffffffffffffb8 # adding `curr` value to `error_log` $7 = 0x404078 pwndbg> x/gx 0x404078 # inspecting what's inside the result 0x404078 <strtoul@got.plt>: 0x00007fb8e512fc60
Note2: In the snippet above,
curr
ends withb8
and nota9
because the program adds0xf
when we send our payload. So we’re taking that into account as well.
strtoul
is a good candidate to override because the user input is supplied as the 1st argument to it inside the main loop of the program:
Sample of what happens after we adjust curr
properly to override strtoul
:
Your choice:
BBBBAAAA
Input Error
...
Your choice:
/bin/sh
Program received signal SIGSEGV, Segmentation fault.
0x00000000004010f0 in strtoul@plt ()
LEGEND: STACK | HEAP | CODE | DATA | RWX | RODATA
───────────────────────────────────────────────────────────[ REGISTERS ]───────────────────────────────────────────────────────────
*RAX 0x7ffcaf47dcc0 ◂— '/bin/sh\n'
RBX 0x0
*RCX 0x9858df ◂— 0x0
*RDX 0xa
*RDI 0x7ffcaf47dcc0 ◂— '/bin/sh\n'
*RSI 0x0
*R8 0x7ffcaf47dcc0 ◂— '/bin/sh\n'
R9 0x0
*R10 0x402017 ◂— 0x65206f6c6c654800
R11 0x246
R12 0x401110 (_start) ◂— xor ebp, ebp
R13 0x7ffcaf47de50 ◂— 0x1
R14 0x0
R15 0x0
*RBP 0x7ffcaf47dd60 ◂— 0x0
*RSP 0x7ffcaf47dbe8 —▸ 0x40196e (main+1434) ◂— mov dword ptr [rbp - 0x148], eax
*RIP 0x4010f0 (strtoul@plt) ◂— jmp qword ptr [rip + 0x2f82]
────────────────────────────────────────────────────────────[ DISASM ]─────────────────────────────────────────────────────────────
► 0x4010f0 <strtoul@plt> jmp qword ptr [rip + 0x2f82] <0x4141414142424242>
We reached the PLT trampoline, RDI
contains our input string & we control RIP
. Perfect gadget.
Now let’s change it to system
.
Obstacle #3: Overcoming ASLR, finding system
Even though PIE
is disabled on the challenge binary itself, this is not a statically linked file. Hence: libc is loaded dynamically and the addresses are randomized.
Using the leak of the ‘lucky number’ (described in Analysis), we can determine the libc version on the remote server. This can be done using libc database tools such as niklasb/libc-database and libc.blukat.me.
Note: After finishing the challenge, I noticed we didn’t had to recognize & download the right libc version in a blackbox perspective using leaks. That’s because the docker container(provided in the challenge zip file) already has a copy of it. That was a painful lesson, but it’s part of the adventure I guess. I hope you learned something new.
After downloading the relevant .so
file, we can open it in pwntools
in order to calculate the base address of libc. And from there, adding offsets to discover where system
is located.
Combining everything together
( ͡▀̿ ̿ ᴗ ͡▀̿ ̿ )✊