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
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
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
- /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 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:
- Check if the process is running: ps -fe|grep -i clip
- Kill the PID if it is (it’ll show as “/usr/bin/VBoxClient –clipboard”)
- 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:
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.