conand & marcof
on September 24, 2015
6 minute read ·
I hear bots are playing ctfs now.
Note: Aslr has now been disabled for this challenge
The challenge did not provide any binary but just a remote service.
Connecting to the remote service we got an ELF:
$ nc 18.104.22.168 8888 > binary
$ file binary
binary: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=c9977e6ab77d506a99fd04551f255e27198584db, not stripped
Decompiling we easily found out that the executable spawned another service reading our input and writing back to the socket the same input.
We noticed that the executables provided by the server were always different and ran on the remote host for about 1 second.
Downloading more binaries we noted that the only differences in the binaries were the service port, the dimension of the buffer, and the number of bytes read.
These parameters were randomly generated, leading sometimes to a buffer overflow.
Hence, the idea was to query the server until a vulnerable executable is generated.
$ checksec.sh --file binary
RELRO STACK CANARY NX PIE RPATH RUNPATH FILE
Partial RELRO No canary found NX enabled No PIE No RPATH No RUNPATH binary
NX was enabled on the binaries but there was no canary. Let’s ROP!
We grabbed libc from the server hosting Exploitables250 in the hope that it was the same also for this challenge, and it was. The challenge description stated ASLR had been disabled, so we did not need any memory leak to obtain a reference to the libc.
We wrote a bash script to download the executables, parse the output of objdump, grep the randomly generated parameters, and pass them to the python exploit.
The python exploit simply checks if the service is vulnerable and, if so, builds the ROP chain to execute system("/bin/sh").
We used ropper to find the gadgets in the libc.
Since our input was bound to the socket we called dup2 to attach the socket to stdin/stdout.
CSAW, Exploitables, ROP
Let us know what you think of this article on twitter @towerofhanoi or leave a comment below!
Brainhugger (RuCTF 2019) The brainhugger challenge at RuCTF 2019 was a simple REST API written in Go, which allowed users to register and run code written in Brainfuck. Exploiting this...