US CyberGames RE-Cruise 4
The wrong way to solve this problem
Last updated
The wrong way to solve this problem
Last updated
This reverse engineering problem was the capstone problem for the "Cruise" set of reverse engineering problems for the US Cyber games final CTF. I've been messaged by a bunch of people asking how I solved it, so I've put together this walk through describing the vulnerabilities in the program and I how used them to solve it without sigqueue .
The problem set contains a number of challenges that rely on using signals to interact with the challenge problem. The problem on the server is a setuid program that when in the correct program state will print the flag. This binary has striped symbols, but otherwise follows the same format as the previous cruise problems of:
The first issue within this challenge lies in the getRandBytes function. Where the returned fd from the open call is not checked and is instead directly read from. This is a classic ulimit -n exploitation case. The ulimit command will enable us to set program limits and restrict the number of open file descriptors, enabling us to force this call to open to fail. Since the return value from read isn't checked either, we can ensure that 0 bytes are read in the returned unsigned int.
The second issue is in the open call for the rules.csv file, where the given path is relative. Because of this we can run the princess binary in a /tmp/something directory and supply our own rules.csv file. There is a similar bug to flag.txt, and so in that /tmp/something directory we need to symlink flag.txt to ~/flag.txt.
Creating this custom rule enabled me to just set a single short blast as the rule every single time the program ran.
This bug ultimately wasn't useable, however in the get_rule() function, there is a loop that adds bytes from the file into a buffer until it reaches a new line character. Since this is a stack address that is passed into the function, this enables us to overflow the rule_buffer variable and clobber everything after it.
Unfortunately, the program ends with a call to exit(2) instead of returning, meaning any saved registers that are clobbered don't give us execution. The program would have also had full protections too, making exploitation incredibly difficult. One positive note though it that the execution environment is vulnerable to CVE-2016-3672 which would let us effectively turn off ASLR, so no leak would be needed to exploit the program.
The first trick is pretty cool for taking all randomness out of the program, however there is a value that gets checked based off those random bytes that needs to equal 1 and not 0, and the check producing the value from the random bytes uses shifts and can never produce a 1.
This leaves us with a brute-force approach toward solving the problem with the second bug. There is no python on the server, so we need to write in C a method for invoking the princess program and sending a signal calculated based off the rand value.
The task becomes pretty straight forward as we need to fork a process, read and send data through a pipe, and send a signal to the process before it terminates.
We're relying on the randomness of /dev/urandom since it will occasionally provide a value from the getCompareValue function that passes the check. So we just need to run this program until it produces the flag with a bash one-liner of:
Since we're running this over a remote connection and the remote server has two cores, I opted to write a script that would run 32 separate instances of the program concurrently to minimize the chance of another player seeing my run folder or process running in memory and speed up the solve.
The real solve follows the escalating process of how to use signals and wants you to pass some data with the signal to the signal hander.
The intended solution uses sigqueue to add data to the signal to be processed.
The value argument can be set in a struct and passed in the sigqueue command, which enables us to set the compared value. From the man page:
