Hunting for Flags

DC-3 is a capture the flag (CTF) hacking challenge found on the vulnhub.com website. It is described as a beginner level challenge and has a single flag, located in /root of this Linux based machine.

Soooo, onto the walkthrough!

After downloading and importing the machine into my VirtualBox setup and placing the machine into my NAT network, the machine received a DHCP address of 10.0.2.23. Lets see what we have to work with:

So we have just port 80 open, which is identified as Apache httpd 2.4.18.

At this point, I like to fire up a browser and take a quick look at the site, before attempting to enumerate some more to identify what may be running on the webserver.

Ok, so seems to be some kind of CMS platform, with a login form. I also at this point, take a look at the source as many platforms give away some clues in the meta headers:

Ok, so immediately, the generator header suggests that the page is made with Joomla! So that is useful information and allows us to shortlist some tools we can use to enumerate some more.

The next step I took was to fire up Metasploit to see if there was a scanner to allow us to get the version of Joomla used to allow us to see if any vulnerabilities exist.

Metasploit search tool is a bit pants, but combining it with grep it can yield more focussed results:

So, we have an auxiliary scanner for joomla version, so let us use this and see if we get any cake.

Great, we now have some important extra information. We have the web server version and the version of Joomla in use.

A quick run of searchsploit using the terms joomla and 3.7.0 provides us with a result from ExploitDB and a CVE to research.

The vulnerability in question, allows a remote unauthenticated SQL injection attack to dump users and password hashes. Sounds perfect for our needs! It also allows an admin session to be hijacked, so if there is an active session, we may be able to exploit some more and get at least a low privileged shell this way.

The very excellent joomblah python script for this CVE is able to take care of getting this information for us, with the minimum of fuss.

https://github.com/XiphosResearch/exploits/tree/master/Joomblah

Boomshakalak! We got an admin user and a hashed password, but no sessions.

This means we will need to crack that there hash!!

Surprisingly, hash-identifier did not recognise the hash format, but a quick google of The first 3 characters ‘$2y’ indicates that the hash is using the bcrypt algorithm.

Time to break out hashcat!

I copied the hashed password into a file called hash.txt and pointed hashcat at this, along with options -m 3200 (Which is the option for bcrypt) and used my goto first pass wordlist rockyou.txt. I also had to force the run as for some reason, virtualbox complains about the virtual CPU.

Within seconds, we have our password. Not very secure!

With admin access to Joomla, we fire up the browser and login. As specified earlier, CVE-2017-8917 has two exploits. We used the first to get the admin credentials, but there is also a session hijack vulnerability. The first run of the JoomBlah script failed to locate a session, but running the script again after logging in, this time gives us a session cookie, which we should be able to exploit.

I didn’t mention before that I had initially found a Metasploit module for the second part of this CVE and tried running this against the machine. It was unsuccessful for the reason that there were not any sessions available to hijack.

It was necessary to get the Joomla admin password and login, to set up this session. In the wild, this exploit would likely be more successful for the patient or crafty hacker, who could potentially use social engineering to point out a typo to a website administrator to get the session that is needed to exploit, but in this challenge, cracking that admin password was a necessary step.

The metasploit search for 2017-8917 provided us with the exploit needed.

Using the exploit was a simple case of setting the rhosts option to our server and firing it off. I am showing the failed attempt as well as the 2nd attempt with the logged in user in place below:

As you can see, without a live administrator user logged in, the exploit failed, but with our admin user logged in, we get a meterpreter session, happy days!

Back to enumeration!

Getuid and sysinfo provides us with our current user and linux versions.

So we are logged in as the low privileged account www-data and we are looking at a 4.4.0-21 kernel.

At this stage, I like to break out to a shell and use the excellent LinEnum shell script from https://github.com/rebootuser/LinEnum/blob/master/LinEnum.sh as It saves a bunch of time gathering a set of standard enumeration information like suid bineries, cronjobs and sudo users that can all be used for privilege escalation. I highly recommend this tool as a starting point for local enumeration.

I like to place my tools into a folder in /tmp on the target machine as this location is cleared on reboot and helps cover tracks.

Next I enter the shell, chmod the script to allow execution and set it off.

The information gathered from this enumeration found some interesting things.

The /etc/passwd file contained an interactive user called ‘dc3’ and this user seemed to be an administrator with some sudo rights. This could mean that we might not need to own the root user to get our flag.

Before I looked into this a bit more, I just did a quick check to see if there were any local privilege escalation (lpa) exploits available for this operating system version.

A standard ‘cat /etc/issues; uname -a’ command on the remote shell provided me with the OS and kernel build to allow me to search for exploits.

Then back on Kali, I performed a searchsploit on the Ubuntu version.

Looking at our kernel version, there seemed to be several possible local exploits available. I decided to pause further enumeration of the dc3 user at this point and look more into these exploits as these could provide a shortcut to root.

My standard approach here is to switch to exploit-db at this point and read more about these exploits. I look at the descriptions in the code for specifics about compiling (If c code) and check to see whether the exploits have been verified by exploit-db as this provides a good indication that firstly the exploit will work, and secondly that it is safe to run (as safe as any exploit could be, that is).

After trying several of these, I finally had success with EBD ID: 39772. This exploit was named ‘Linux Kernel 4.4.x (Ubuntu 16.04) – ‘double-fdput()’ bpf(BPF_PROG_LOAD) Privilege Escalation’.

The exploit was downloaded from: https://github.com/offensive-security/exploitdb-bin-sploits/raw/master/bin-sploits/39772.zip

This was a zip file. So I unzipped it on my Kali box