[pwnable_tw - pwn] start (100 pts)

This pwn challenge is quite easy. got nervous at first but eventually got it. challenge provides a netcat IP and port to connect to, to run the exploit script against as well as the 32 bit binary that's running on that port for local debugging. so, let's look at the binary.

Challenge has every protection disabled which just indicates any shellcode injection into the challenge process will work as the stack is executable. Running the binary just asks for user input and simply exits after input is given. Let's look at what's happening under the hood.

The binary is stripped so the symbols are not present for us to see. However a entry function is present in the disassembly.

entry0() function does a few things:

- pushes esp and _exit onto the stack

- performs xor operations on eax, ebx, ecx and edx (which basically zeroes out these registers)

- pushes a total of 20 bytes onto the stack (which turns out to be the "Let's start the CTF:" string the binary outputs when it executes)

- calls write() syscall (represented by mov bl, 1 instruction)

- calls read() syscall (represented by mov al, 4 instruction) and recieves input of 60 bytes in length

- Adds 20 bytes of address in esp

- finally a 'ret' instruction is called, with eip pointing to _exit() function (0x804809d = _exit() address)

To exploit the challenge, a couple of things need to be done. Firstly, we need to utilise the buffer overflow vuln to have eip control to eventually leak the stack address. since NX bit is disabled, shellcode injection into challenge process is viable, with a twist. usually a 'jmp esp, instruction would be used to have program execution jump to the injected shellcode as its located on the stack when its injected. However, the 'jmp esp' gadget is not in the binary so another gadget has to be used to perform the same thing, to leak the stack address.

The gadget above is actually similar to the instructions within the entry binary, specifically from the ret instruction, backwards to the mov ecx, esp. If analyzed carefully, this sets up eip to point to the state in the program before sys_read syscall is invoked (state of program before sys_read = 0x08048086 approx., sys_read call invokation = 0x08048087)

the payload = padding (input buffer to eip_control offset) + stack address + length of the padding + shellcode. As seen above, padding, which is user input starts at esp + 0 which is the offset pointing to the top of the stack. shellcode was extracted from shellstorm website.

Normally the padding would be a bunch of 0x41(A) until eip control but utilising a NOP sled (bunch of 0x90 instructions that do nothing) yielded a more successful result.

Final exploit script

pwned.