I had the chance to work on another Vulnhub machine named ‘BrainPan’ the other day.
I’ll go through how I was able to achieve root on the host.
After making sure it was possible to communicate via DHCP with the host on VMWare to my kali host, I was able to begin my attack.
It started with the onetwopunch scan of the host, which identified two open TCP ports: 9999, and 10000.
The open port 9999, when connected with netcat displayed information about an application that required a username and password. After testing a few basic passwords, I moved onto the other port.
TCP port 10000 was listed as ‘A Simple Python Server’. From previous experience, I knew it was a python http webserver, so this meant it was possible to use gobuster to enumerate the webserver.
After gobuster had completed, it revealed a web folder with an executable named brainpan.exe. After copying it to my windows 10 machine and see how it worked.
It was a simple chat relay application, which I decided to fuzz it as that could lead to a vulnerable remote buffer overflow.
I opened up Immunity Debugger and attached the running application. After fuzzing the application, I was able to crash it and it was clear that this was the best attack vector I had located.
Firstly, I need to confirm how many bytes the application required before it crashed so control the EIP. It took 524 bytes, so I made 524 A’s, 4 B’s and rest of the buffer C’s.
After again fuzzing the application, it crashed and showed that EIP was BBBBCCCC… which meant there was control of the EIP and we were ready for the next phase of the attack.
Next was to identify the JMP ESP address which we can tell the application to run our shellcode when we include it into the payload. Initially I attempted the mona.py module however it was having issues with immunity debugger, so I loaded the executable and searched for the JMP ESP address as a command and located it at the address : 311712F3.
Then I created the shellcode with msfvenom to a reverse shell back to my kali host with the IP address and the port I wanted it to connect back on. I would have a netcat listener waiting to connect to any returning host on the specified in the shellcode.
Last step was to remove the C’s and make it nops, which is a no operation which is just filler for the code and will cause less interruptions than the C’s.
When tested, the netcat listener connects to the returning host and we have remote code execution on the host deadpan! We weren’t lucky enough to have a root/administrator shell, as this meant that the application was running by a low privilege user and we have to work a try harder if we root permissions.
During privilege escalation, it was identified that the user had access to run sudo on a file in another user’s folder. When the file was run with sudo, which means if we can find a way to create a new shell, it would be created as root and therefore we would have root permissions.
The application allowed for manual commands to be run. After a few trial and error attempts, running the command: !/bin/bash spawned a new shell as root. This is now a gamer over as the host was successfully compromised.