nc 184.108.40.206 8888
nc 220.127.116.11 8889
- Leak the canary
- Use ROP to leak the address of
- Find the
libcversion by libcdb.com
- Use ROP to
dup2 dup2 system
babypwn is a TCP server. If we connect to it, it is basically a echo server.
The bug is a simple buffer overflow. At line 10 of the following code snippet, it reads 0x64 bytes to a buffer of 0x28 bytes.
Although the return address is protected by a canary, this program doesn’t append a null byte when receiving data and later return all the data before a null byte. Therefore, we can concatenate our input with the canary and leak it in the response of server. With the knowledge of canary, it is trivial to override the return address and launch a ROP attack.
I want to make use of the
system to spawn a shell, so my next step is to leak the address of the
libc. Using ROP chain such as
send, padding, GOT of atoi, I can leak the address of several
libc functions. Finally, I need to know the
libc version of the remote to calculate the correct offset of
system. At first, I used libc-database but couldn’t find the matched version. Then, I try libcdb.com and luckily found the target
libc. Now, I can use the standard
dup2 dup2 system ROP chain to launch a shell and get the flag.
The whole exploit is as follows. (Note that since it is a fork server, the canary and the
libc base won’t change unless the server is relaunched. Therefore, I hardcoded the canary and
libc functions in the script.)
from pwn import *
- I spent some unnecessary work on finding the address of
systembecause I didn’t see that
systemwas already in the GOT table. It was deliberately put in the code that no one actually reference it. It was even used to
system("echo 'not easy to see'")to indicate this fact.