Welcome to my write-up for the Sumo machine from VulnHub. This is a beginner-level, intentionally vulnerable virtual machine created for the purposes of testing and strengthening one’s abilities. I hope you enjoy reading this as much as I enjoyed rooting and writing!
The download page is here. Always read the description to see if there’s anything the author shared that they think is important. It mentions that this machine was tested with VMware Workstation, but I did not have any issues with VirtualBox. DHCP is also enabled, so we will need to discover the host’s address after it boots.
We download the .vdi file and import it into VirtualBox as usual. I then like to go in and ensure the network setting is set to “host-only” so that it is not exposed to anyone except my attacking machine. [CLICK IMAGES TO ENLARGE]
With that out of the way, we are ready to start scanning this machine!
I like to start off with an nmap ping scan to find the vulnerable host. If that doesn’t work, I’ll try netdiscover. This machine is located at 192.168.1.8, and with that information, we can scan for some open ports.
Only SSH and a web server are exposed at the moment, which is common with a CTF-style box such as this. The searchsploit command allows us to search Exploit-DB for known vulnerabilities in software, but it didn’t report anything useful for either the SSH or HTTP server versions.
Browsing the website shows a default “It works!” page, and there’s nothing interesting in the page’s source code, nor is there a robots.txt file. Let’s see if our friend Nikto can find anything for us.
There is an unusual header with a CVE number in it in the scan output. CVE stands for Common Vulnerabilities and Exposures, and it is a list of publicly known vulnerabilities. (There are other vulnerability databases as well, such as the OSVDB also referenced in the screenshot.)
When a vulnerability is discovered, it can be assigned a CVE number such as “CVE-2014-6278” (the header in the screenshot above). Just below that finding, Nikto also identifies the site as being vulnerable to the “Shellshock” vulnerability. Both CVE numbers are related to Shellshock, and if exploitable, this is a very valuable finding, so let’s find out. The answer might “shock” you! (Sorry, I’m caffeinated.)
Let’s launch Metasploit with the msfconsole command and then search for Shellshock exploits with Metasploit’s appropriately-named search command. It returns multiple results, but we will want the “exploit/multi/http/apache_mod_cgi_bash_env_exec” exploit. We know this because the other options are either auxiliary modules for scanning for the vulnerability or because the other options are specific to other services (DHCP, FTP, CUPS, etc.).
We’ll need to specify our RHOST(S) and TARGETURI appropriately, and the TARGETURI value here is just the path to the vulnerable file on the web server that Nikto identified. Once all required settings are configured, exploit the machine with your choice of the run or exploit commands. (Today I chose exploit so I can feel like a 1337 h4x0r.)
Now we have a Meterpreter shell! We can gather a little information here. We find that we are not running as root (we are currently the www-data user, though Meterpreter doesn’t know it), as well as seeing what kind of machine we are on. The Ubuntu and kernel versions here are quite old, and in fact, searchsploit shows us that there is a known local privilege escalation exploit available for this machine.
In the previous screenshot you can see me running the gcc -v command. This is to verify the GCC program is available on that machine, as it is necessary to compile the exploit we want to use.
The searchsploit -m command we run “mirrors” or copies the exploit code to our current directory so we can edit and use it. Always read through unfamiliar code before running it!
This C file has comments in the beginning that show how to compile the code, and now we can copy it over to our friend Sumo using Meterpreter’s upload command.
We compile the code according to the comments and run the exploit using the appropriate argument (also learned by reading the code). And we have root!
The id command shows our level of access, and we find a “root.txt” file in root’s home directory.
As usual, I won’t reveal its secrets here, so go ahead and try this machine out for yourself!
This machine taught me the value of performing basic reconnaissance when looking for privilege escalation methods. I originally jumped right into running linpeas.sh as soon as I got onto the box, only to scroll to the very top of its output and see the old OS/kernel finding listed. Not a big deal, but it’s important to know how to get by when you don’t have the tools that make it easy for you.
Did you attempt this machine as well? Did this guide help you if you got stuck? Let me know in the comments — I’d love to hear about it!