I am scheduled to start the OSCP in a couple of weeks, and was considering making the most of the vacation I had booked, and the beautiful summer weather by staying indoors and gaming as much as possible.
After discussing exactly this idea with a couple of other people who had taken the OSCP, they all commented that the best games were to be found on vulnhub . I took the hint and prepared to dig into another vulnerable operating system.
After some brief searching around my scrum board for a suitable one, I saw the SickOS 1.1 machine. In the description, it even says “This reminded me of my time in the OSCP labs”, so surely this would be the best start. Let’s dive in and see what is what.
After setting up the VM, I started off the same way with most VM’s, namely using the netdiscover command to find out what is on the network. Netdiscover listens for ARP packets to find out what is broadcasting on the network.
The third ip address down was the VM, as I had not seen it previously and also the MAC address is from a very different range to those on my host machine, so off to nmap we go to find out what ports are open.
Well ssh is open at least, and there is a some kind of potentially open proxy that supports GET requests. Port 80 is not even there and port 8080 is closed. I wanted to know what we could do with the open proxy, so I configured a browser to use it as a proxy.
This meant that every single request I send would go through this host first, before being sent either to the internet, or to another address on the network. I tried out what was on the localhost first and was rewarded(?) with the following.
That probably means that we are on the right track. I started up the nikto scanner, and configured it to use the proxy. Whilst it was running, I searched for more conventional and manual information gathering, namely what is in the robots.txt, if there is one?
It seemed a lot like a blogging software, similar to wordpress. If it is anything like the wordpress ecosystem, that probably means there are a hundred different ways into this thing, so perhaps plenty to choose from! Lets start off with reading a bunch of boring documentation, aka research.
This was actually a LOT more helpful than it at first seemed. There is a note down at the bottom declaring that the write permissions to a config file have to be removed, which means that it is probably quite interesting. There is also default password generated at install, which means that it might still be set. Lets take a look at what the nikto tool’s output is that we started earlier.
Down at the bottom there, it says that this vm is probably vulnerable to the shellshock vulnerability. Having just exploited this in a class at APPsecEU, I really wanted to try this out, so added it to the list of potential holes. I through I would try accessing the admin area using some pretty basic tricks, like empty password, password is ‘ OR ‘1’=’1, or password is admin.
To my suprise, admin/admin as user and password worked, so now I had access to the cms!
Digging around for as many as 2 seconds revealed a Files tab where the user can upload a tab. I got the really good php-reverse-shell from pentestermonkey and adjusted the values to make sure it would dial back to my machine.
I also had to alter the permissions to make sure that it was executable by all users. A quick netcat listener was set up, obviously on port 31337, and then we visit the url containing the shell in another page. The cms tries to execute the shell, and then we get our dial back.
Success! At this point, it is important to gather as much data as possible. First off is going to be which user we are, and then it is going to be walking around the file system to find any other interesting data.
We are the www-data user, which comes as no big suprise. Sometimes these things are running as root, which, terrifying as it is, eliminates the need for us to move further. Next we should check out that config file from the documentation and obviously the passwd file, which will give us a great overview of all the users on the system.
Those database settings look very interesting. Noted down the user and the password for later, lets continue on to the passwd file.
There is a sickos user, which means that perhaps we could ssh into this box with some credentials. Ssh is a somewhat more robust method of looking around this box than the reverse php shell we are using. For one thing, there are certain commands that can only be run in a terminal, that the reverse shell will not allow us.
After a couple of tries, the “john@123” password turned out to be the right one. Now we have a stable ssh connection, and we can attempt some further enumeration. I thought I would try to immediately elevate my privileges to root (cant hurt to try, right?), and to my suprise, it worked! Re-use of credentials is a real problem, as demonstrated here.
A quick check of the root users home directory revealed the flag that we were looking for!
This post represents the “happy path” through this machine. Not shown are the couple of hours I spent wandering around the operating system, gathering data that was never used, or not useful. I also tried some brute forcing that did not pan out either. I may return to this machine at some point in the future though, as I would like to try out that Heartbleed vulnerability.
I hope you have an awesome week!