US CyberGames RE-Cruise 4

The wrong way to solve this problem

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 .

$ file princess
princess: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=43925fc945c2d6258b7ba11547fbd3236340cd62, for GNU/Linux 3.2.0, stripped

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:

get_rand_bytes() ->get_rule() -> get_signals() -> read signal_sequence -> print flag

Program vulnerabilities

First bug - Controlling /dev/urandom

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.

Second bug - Controlling rules.csv

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.

Third bug - Crashing the program

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.

checksec princess
[*] '/home/chris/ctf/cybergames/final/princess'
    Arch:     amd64-64-little
    RELRO:    Full RELRO
    Stack:    Canary found
    NX:       NX enabled
    PIE:      PIE enabled

The solve

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:

while true; do timeout 1 ./run_till_flag;done | grep uscg # only print flag
#include<unistd.h>
#include<sys/wait.h>
#include<sys/prctl.h>
#include<signal.h>
#include<stdlib.h>
#include<string.h>
#include<stdio.h>

//#define PROG "/home/chris/ctf/cybergames/final/princess"
#define PROG "/tmp/something/princess"

int get_signal(unsigned int rand_val)
{
  int sig_num[] = {0x1a,0x12,1,10,0xb,0x15,0x1d,0xd,6,0x10,0x1f,0x1e,0x14,0x17,0xb};
  int index = rand_val >> 0x18 & 0xf;
  return sig_num[index];
}

int get_cmp_val(unsigned int num)
{
  return (num >> 0x10 & 0xff) * (num >> 0x18) - (num & 0xff ^ num >> 8 & 0xff);
}

int main(int argc, char** argv)
{
  pid_t pid = 0;
  int inpipefd[2];
  int outpipefd[2];
  char buf[2048];
  char msg[256];
  int status;

  pipe(inpipefd);
  pipe(outpipefd);
  pid = fork();
  if (pid == 0)
  {
    // Child
    dup2(outpipefd[0], STDIN_FILENO);
    dup2(inpipefd[1], STDOUT_FILENO);
    dup2(inpipefd[1], STDERR_FILENO);

    //ask kernel to deliver SIGTERM in case the parent dies
    prctl(PR_SET_PDEATHSIG, SIGTERM);

    execl(PROG, "princess", (char*) NULL);
    exit(1);
  }

  //close unused pipe ends
  close(outpipefd[0]);
  close(inpipefd[1]);

  // Read until rand value is printed
  int count = read(inpipefd[0], buf, 50);
  // Since we're running fast, we might
  // SIGBUS or SIGPIPE and we might as 
  // well restart
  if(count != 50)
  {
    usleep(100);
    kill(pid, SIGKILL); //send SIGKILL signal to the child process
    waitpid(pid, &status, 0);
    return -1;
  }
  memset(buf, '\x00',sizeof(buf));
  
  // Get the rand value printed
  read(inpipefd[0], buf, 8);

  unsigned int rand_val = (unsigned int)strtol(buf, NULL, 16);
  //printf("rand_val %X\n",rand_val);

  unsigned int signal_val = get_signal(rand_val);
  unsigned int cmp_val = get_cmp_val(rand_val);

  //printf("Signal %d\ncmp_val %X\n",signal_val, cmp_val);

  read(inpipefd[0], buf, 2048);
  //printf("%s\n", buf);
  memset(buf, '\x00',sizeof(buf));

  // I was only going to kill if it's the right cmp_val
  // but it's just as fast to run all of them
  if (cmp_val == 1 || 1)
  {
    kill(pid, signal_val);

    write(outpipefd[1], "\n\n", 2);
    close(outpipefd[1]);
    read(inpipefd[0], buf, 2048);
    // Should contain the flag
    printf("%s\n", buf);
    //printf("rand_val %X\n",rand_val);
    //printf("Signal %d\ncmp_val %X\n",signal_val, cmp_val);
    return -1;
  }

  kill(pid, SIGKILL); //send SIGKILL signal to the child process
  waitpid(pid, &status, 0);
}

Speeding up the process

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.

from pwn import *
import multiprocessing

cmd = "cd /tmp/something/;while true;do timeout 1 ./run_till_flag;done | grep uscg"


def do_work(nothing):
    conn = ssh(user="challenger",host='0.cloud.chals.io',\
            port=28429,password="5f4dcc3b5aa765d61d8327deb882cf99")

    p = conn.shell(cmd)
    print(p.recv())


p = multiprocessing.Pool(32)
p.map(do_work,range(32))

The real 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:

The value argument is used to specify an accompanying item 
of data (either an integer or a pointer value) to be sent with the
signal, and has the following type:

           union sigval {
               int   sival_int;
               void *sival_ptr;
           };
uscg{a_signal_inside_a_signal__achievement_unlocked!}

Last updated