CSAW CTF 2012: exploitation 200/300/400/500 writeups
Written by Samuel Chevet
This article regroups writeups for all exploitation challenges which did not deserve a full article.
This challenge is a linux elf32 wich listen on port 54321.
Each time a new client connect, it sends a message of welcome, and wait for receiving 512 bytes of data, those data are compared to the string : "A" * 26 + "\n", if it match the challenge will open the file "key" and send it to us.
The key is : "b3ee1f0fff06f0945d7bb018a8e85127"
This challenge is a linux elf32 which listen on port 4842. The binary will setup handler on differents signals, the most interesting one, is SIGSYS(0x1F), after a client connect and send a message of welcome, it will raise this signal, the handler will send an another message, and read 2048 bytes of data into a buffer of 326 bytes on the stack. It's clearly a simple stack based buffer overflow. And a fun thing is :
> readelf -l ./bin | grep STACK GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
The stack is executable, so let's search some fun gadgets like jmp esp :
> rasm2 "jmp esp" ffe4
This gadget can be found inside section .eh_frame_hdr (0x08048F47). So the payload is really simple and look like this :
"A" * 326 + Addr_return (JMP ESP) + Shellcode (dup2 + excve(/bin/sh))
They changed the binary before we wrote this writeup, so our exploit does not work anymore and we don't remember the key.
This challenge is a linux elf32 wich listen on port 23456.
The vulnerability is inside function sdoomsday() (There is symbol inside the binary ...), it receive 511 bytes into .bss section and use this buffer for sprintf without format for filling a buffer on the stack. It's a simply format string vulnerability.
A nice thing is that .bss section is executable, so the payload will be :
| JMP AFTER FORMAT | FORMAT | NOP | SHELLCODE
What we will have to do is replacing address of a function inside got section called just after sprintf (for exemple send wich is called inside cd() function). An another fun trick is inside ssc function, it check if inside the buffer there is the pattern :
1 2 3 4 5 6 7 8 9 10
/bin/sh /usr/bin/es /usr/bin/ksh /bin/ksh /usr/bin/rc /usr/bin/esh /bin/dash /bin/bash /bin/rbash h//shh/bin
Just xor your shellcode and add a stub at the beginning for dexoring it.
The key is : "What_a_simple_filter_that_was"
This is the last exploitation challenge, it is as usual a linux elf32 wich listen on port 12345.
The first thing the program do is receiving 124 bytes, and check if in this buffer there is the pattern :
1 2 3 4 5 6
CPE1704TKS IMSAI 8080 microcomputer WORP Galaga Pencil Tic-Tac-Toe
And then receive 1024 bytes, but the return value of recv() will be the size of a memcpy() into a buffer too small, so it is a simply stack based buffer overflows. We can overwrite easily the return address by the adress of receive and forge the stack like :
1 2 3 4 5 6
+0xBC : New Return Address : 0x08048760 # .plt recv() +0xC0 : Return Address recv : 0x0804B000 # .bss section +0xC4 : File Descriptor : 0x4 # socket client +0xC8 : Buffer : 0x0804B000 # .bss section +0xCC : Size : 0x54 # Size Shellcode +0xD0 Flags : 0x0 # who care ?
We send the same shellcode as usual dup2 + execve(/bin/sh), and enjoy our shell.
The key is "Something_different_from_strcpy"blog comments powered by Disqus