kibilogic

Sickos 1.1 – vulnhub challenge

After reading quite a few OSCP reviews, I have decided that I should take some time and start plugging away at some challenges. OSCP is a hands-on certification unlike the other certs out there, and I feel like I should immerse myself into preparing as much as I can before I sign on for it.

I’m setting a goal of a minimum of 10 vulnhub challenges before I make the plunge with the expectation that I will do considerably more than the minimum.

The OSCP does not necessarily make any assumptions or require any experience but I’ve read enough and heard first hand that it is not a “walk in the park” and with a mantra of “try harder” when you hit a bump in the road, I want to at least start off with some challenges beforehand.

I start things off with sickos 1.1 and these are my notes. The final part of OSCP is a writeup, so for each challenge I do, I plan to conclude with a writeup.

This is all about preparing for the OSCP.

Here goes.

————–

The first thing I do is find the machine on my network.

nmap -sS -O 192.168.1.0/24

Found the machine, now I need to know more about the software and versions.

nmap -A -T4 -p- 192.168.1.4

At this point, I use nikto to see if it can help with identifying known vulnerabilities.

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

Great, I know that OpenSSH (port 22) and Squid HTTP Proxy (port 3128) are running and the OS is a version of linux (3.2 -4.4)

There is also a robots.txt file and a possible shellshock vulnerability in /cgi-bin/status.

First thing I look at is the robots.txt file

I configure the browser (ice weasel) to use manual proxy 192.168.1.4 port 3128

Then navigate to 192.168.1.4/robots.txt in the browser.

I see there is a reference to wolfcms and I navigate to 192.168.1.4/wolfcms in the browser.

I have no idea what wolfcms is or does but I see things are posted by the Administrator.

I do a google search “wolf cms admin” and the first thing to pop up is this:

I immediately find that there are a couple of suggestions related to getting the admin link, /admin and /?admin.

I try both and turns out that the /?admin worked.

I now have the admin login page

The username and password default password was admin/admin…this was a guess based on the information and multiple warnings about changing the admin password.

The admin:admin works and I browse through all four tabs.

I notice that in the final “files” tab (green tab) it allows for uploading files.

Wolfcms runs php and I have upload access. Let’s see if I can some how get a reverse shell.

Using metasploit is my first thought but from what I read the OSCP cert provides limitation for using it.

I need to do as much without metasploit. I don’t want to handicap myself.

So, a script it is.

I go with php-reverse-shell, a script that can be uploaded to a web server running php. 

The script opens an outbound TCP connection from the webserver to a host and port of your choice and bounds to the TCP connection for an interactive shell.

Using Pentestmonkey’s php-reverse-shell, I upload the file and make the necessary changes as indicated (“CHANGE THIS”).

I only changed the ip address to my (attacker) machine, I left the port as 1234.

I changed the permissions on the php file from 644 to 777 for everyone.

On my machine, I set up netcat to listen for a connection

nc -lvp 1234

I searched to see where the php file was uploaded.

find . -name php-reverse-shell.php

I run the reverse-shell script by navigating to its location in the browser

That works.

I’m in, now I start looking into how I might escalate the privileges

I check for other user accounts on the machine

cat /etc/passwd

I check to see if there are any interesting files (configuration, php, etc) related to wolfcms.

Generally, the root directory for web servers is located in the /var/www directory.

ls -l /var/www
ls -l /var/www/wolfcms

I check to see what services are running as root

ps aux | grep root

I check to see what applications are installed.

ls -alh /usr/bin

I check to see if there are any cron jobs scheduled

crontab -l
ls -al /etc/ | grep cron

After enumerating these things, I focus on the users “root” and “sickos”.

From listing the services I know that ssh is available.

One of the interesting files in the /var/www/wolfcms directory ended up being a config.php with what appeared to be login information

Armed with this information, I tried to ssh in from my machine.

ssh root@192.168.1.4 didn’t work

But ssh sickos@192.168.1.4 did with the password john@123

I quickly check to see if the user “sickos” has sudo privileges

sudo -l

Yep, feeling excited. I logged in as root.

sudo -s

And with that, I navigated to the /root directory and viola!

I went with the lowest hanging fruit but considering that there is a shellshock vulnerability, I’m guessing that is another path. I also found a connect.py file that could be yet another option. But this worked first. I will plan to revisit this again at some time to see where the others lead.