Sunday, February 14, 2016

Vulnhub SickOs walkthrough

This is the highlights of my exploitation of SickOs from Vulnhub. It wasn't the most difficult hack as it only took an hour or less to get root and the flag. Well, at least I didn't think it was difficult.

From the nmap scan results, you can see that only ports 22 and 3128 were opened.


Since port 3128 is Squid proxy, I used it in my Nikto scan to see what was behind the proxy.


Note that /cgi-bin/status appears to be vulnerable to Shellshock.


How to exploit it via the proxy? Normally I would have used a Python Shellshock exploit that's quick and easy. I didn't know off the top of my head how to run a Python exploit through an http proxy, so I googled curl options for specifying proxy, and user agent for the exploit.

First start a netcat listener: "nc -nlvp 443"

Now let's use curl to exploit Shellshock via the proxy on port 3128.


Our low privilege shell:


I remember from PWK/OSCP a lesson I learned was always look for the low hanging fruit first. Always check the webserver directories for secrets in configuration files. I found config.php with a password in the /var/www/wolfcms directory.


Before trying to ssh in using the password in config.php, I checked out the contents of /etc/passwd and noticed the sickos user. Users, even sysadmins are notorious for re-using passwords, so even if the password in config.php doesn't work for root, there may be a good chance it works for another account.


First I tried to ssh in as root:john@123 but was unsuccessful. Next I tried sickos:john@123 and got in! After running the command "id" and seeing admin and sudo groups, all it took to get root was a quick "sudo -i". Always check to see if the unprivileged user in your shell can sudo by entering the command "sudo -l" before resorting to trying exploits for priv escalation.




There may have been other ways to exploit SickOs. I never checked to see if Wolf CMS was using default admin credentials. I also didn't check to see if it was vulnerable to the Wolf CMS arbitrary file upload exploit. Knowing the database username and password, I may have been able to write a file shell or exploit. I didn't see the need since I was able to get in fast and easy without it. This wasn't meant to be a thorough pentest, I was simply having fun with it.

Update: Another way to exploit the host once I found the Nikto results that stated the host was vulnerable to shellshock was to use Metasploit's exploit/unix/dhcp/bash_environment. Setup the exploit options and restart the SickOs host and receive a root shell! Even easier than using curl and then looking for a local privilege escalation exploit.