A relatively new set of VulnHub CTFs came online in March 2017.  This post is about the first and easiest one, named “Quaoar“.

This post will be a walk-through of my exploitation of this system.

The first thing I like to start off with on any box is a full TCP port scan.  When you boot up the VM, it shows you the IP it gets from DHCP.

Seeing there is a web port open, a examine it first. Viewing the source code is not particularly interesting:

The next thing I typically check is the robots.txt file to see if there are any interesting entries.  In this case, there were.

For good measure, I also run Nikto and Dirbuster.

Browsing to the WordPress site shows a pretty simple page.  Now, anytime I see a WordPress site I usually run straight to WPScan, but it this case, I just tried to guess the username and password.  It was simply “admin:admin.”

As it turns out, I had built a suite of tools for WordPress post-exploitation, and this was just the time to use them.  I went and grabbed the WPForce code off of github and ran Yertle.

 

I was able to then send commands to the server and have them execute.  Wanting a full shell, I used the reverse shell option and caught the shell using netcat.

 

While my shell waited for me, I went on to enumerate the other ports.  I ran enum4linux to enumerate information about the Samba share.

 

What I found most interesting was the user accounts. I was also able to see similar information from the /etc/passwd in my shell.

I took all the usernames that had a login shell and I brute forced them against SMB with Hydra.  This quickly told me that the password for the account wpadmin, which was “wpadmin”.  I could now SSH into the system with that account, and have a real shell.

Now at this point I had spent a couple hours trying to exploit the kernel, exploit dovecot, search for setuid binaries, find passwords in log files, look for weak permissions to no avail.  What turned out to be the privilege escalation method was quite more simple than what I had been trying.

WordPress is a PHP based web application.  It also uses a SQL server on the backend to store its data.  In order to connect to the database, it must have the password to the database.  WordPress stores that data in wp-config.php.

When we cat the wp-config.php, we see the database password:

 

While this password is specifically for MySQL, it could also be the password for the root user account, and in this case it was.  At this point all I had to do was “su -” and enter the password.  Done!