SickOS1.2 Walkthrough

I started this box with a net discover command to find it’s IP, 192.168.0.106 (102 is SickOS1.1)

I ran an nmap scan against the host:

nmap -sV -Pn -vv -T4 -A 192.168.0.106 –script=auth,brute,discovery,exploit,vuln -oN 192.168.0.106_nmap.scan

My scan found 2 open ports, ssh and port 80
OpenSSH 5.9[1 Debian


Lighttpd 1.4.28, PHP versioning and more info

Linux kernel between 3.x-4.x

I began by browsing to the webserver and was greeted by Keanu…What if???

Wasn’t able to find anything interesting on the home page, so I fired off a ZAP scan to check for additional dir’s. The scan returned /test/ and file.php

The page seems to be a directory listing with a file “file.php.” The file is 0 bytes and doesn’t contain anything. I turned back to ZAP and ran an “active scan” on the /test/ directory. Not many alerts reported back, but one interesting thing I found was the options allowed in /test/

It looks like we can put and copy files in the directory. Since the site is running php (scans and the file.php in this dir), let’s try and PUT a php reverse shell on the box. I used burp to intercept the request to the server, and changed the request to PUT “shell.php” with the appended contents. This shell should connect back to my machine on port 1234

We receive a “201 Created” response, and confirm our file’s in /test/ ( Ialso added a .htm during testing)

After trying to open the file, I wasn’t receiving a listener connection… I tried a few different ports, but apparently egress filtering is in place. I had to connect back to my machine on port 443 for the connection to be successful

With our new shell, I cat /etc/passwd. Looks like we have users root and john to attempt login

I looked around the box for any programs or applications for exploit. I also uploaded Linux Exploit Suggester which came back with the timeoutpwn exploit. I uploaded the file via the PUT method, but after compiling on the box, it wouldn’t give me root 🙁

After the failed exploit, I took another look at what apps were installed and what may be vulnerable. I listed out some programs in /usr/sbin and noticed chkrootkit, which I have some notes on from a previous scenario, let’s check it out

After knowing the chkrootkit version, I looked up any exploits online and found one

Description of what we need to do:

When I try and run chkrootkit, I don’t have the correct permissions, looks like we’ll need to rely on a cronjob. Checked our cronjobs and found chkrootkit in /etc/cron.daily. Since we know cron.daily will run chkrootkit, and the chkrootkit exploit will run /tmp/update, Let’s add a line to /tmp/update to give our user sudo permissions w/o a password

We also gave the update file all the permissions

After waiting a few minutes, I attempted “sudo su” and…We got root!

After listing the contents of the root dir and checking the flag.txt, I’ve completed the VulnVM

Leave a Reply

Your email address will not be published. Required fields are marked *