A few nights ago I ran a hacking exercise for myself in my cyber security lab. It’s been over a year since I was able to run through such an exercise so I started with some low-hanging fruit to get the mental gears moving smoothly again.
I started with a VulnHub exercise called Quaoar which was rated to be easy.
My lab consists of a single VMWare ESXi 6.0 server with dual Xeon quad-core CPUs, 20 GB of RAM, and a 1 TB RAID 5 array across 8 SAS disks. I use a virtual machine running Kali linux as the primary attacker.
Loading Quaoar was easy as it downloads as a *.ova. I simply added a new VM to VMWare and uploaded the *.ova. It fired up and grabbed an IP from DHCP. After retrieving the IP reported via VMWare it was 100% hands off the target VM… I went to the Kali VM and began my attack.
There are three objectives for Quaoar:
- Get shell access.
- Get root access.
- Find 2 flags.
For the information gathering phase of the attack I started with nmap to retrieve ports open and grab headers from the services running on any open ports. I discovered a plethora of ports open but of interest to me was port 80: HTTP.
Where there is a web server there is potentially a web application full of security holes. But we need to find that web application first.
For that I went with dirbuster which is a web server directory discovery tool. It can be fed a list of probable directory names or it can do a true brute force. I happen to have a few lists that have been highly successful in the past, so I always start with those.
Of interest after the scan was a /wordpress/ and /upload/ directory. I started a scan of the /wordpress/ directory with wpscan using the following command:
sudo wpscan -u http://192.168.2.237/wordpress –wp-content-dir wp-content –enumerate u
Enumerating users was the correct decision as wpscan told me that the admin password matched the username…
Once I was logged into the wordpress installation as an administrator I had the ability to manipulate files of the wordpress installation itself. I managed this by creating a custom wordpress plugin that loaded WS0 shell – a PHP hack tool that gives the attacker shell access and a handy tool set such as upload and remote execution.
The thing to remember about WS0 Shell is that it runs as the user that the webserver itself runs as – in this case www-data. It can do whatever that account can do.
Objective #1 complete!
By default, the www-data account has access to all of the webserver content files and directories. My first stop was the wp-config.php file, which contains the wordpress username and password to access the MySQL server.
Unfortunately for the virtual server admin on this target server, the root account for the MySQL server was used to set up this wordpress installation instead of account dedicated to wordpress and only wordpress… Now I had root access to the MySQL server…
Objective #2 complete!
In a true show of curiosity, I also tried to log in via SSH using the MySQL root username and password and it worked… I now had root access to the entire server.
I quickly found the flag files in /root and /home/wpadmin and was done.
Objective #3 complete!
Lessons Learned
I enjoy running these challenges because it reinforces attack and defense strategies in my mind. In this case the huge lesson learned is to not use default username/passwords and to not share credentials between systems. In this challenge the learning points for the defense are:
- Simple account names and passwords are easily guessed. The wordpress installation had an administrator account named ‘admin’ with a password of ‘admin’. wpscan is designed specifically to look for this flaw. If the defender had used a non-system account name such as ‘george’ I wouldn’t have had this vulnerability to leverage. The same goes for the password.
- Don’t use the MySQL root account for production systems. It should be used for management ONLY. The wordpress installation used the MySQL root account. By owning the webserver using WS0 I was able to get the MySQL accounts used for wordpress and the other CMS that was installed on the webserver (I didn’t even look at that because the wordpress config file gave me all that I needed.) If the defender had used separate dedicated accounts for each CMS then I would have only had the usernames and passwords to log into each MySQL account for each of the CMS. This would have kept me locked into the webserver and the MySQL server. Root MySQL access gives me access to ALL databases and user accounts on the MySQL server.
- Credential sharing between services is bad. The MySQL root password was the same as the system root password. A huge no-no. Credential sharing makes my job, as a hacker, easier. If the MySQL password and system root password had been different, I wouldn’t have been able to easily log in via SSH and control the entire server.
Some learning points for the offense:
- Dirbuster is a very powerful tool for web server traversal. If throttled back and configured to use a crawler agent it can be made to look like just another search engine crawler making its rounds as to not alert and attentive defender. Hindsight is 20/20 and the robots.txt on the webserver would have pointed me directly to what I needed to find. (Dirbuster checks robots.txt immediately but I could have done it in less time manually.)
- WPScan has many powerful options. User enumeration can narrow down valid account names to create a list that can be used later in a hydra attack. Wordpress, by default, doesn’t alert on failed user login floods and doesn’t lock accounts, leaving low-complexity admin account passwords a vulnerability to the entire webserver.
- WS0 Shell works well but can be clunky. I actually prefer trying to pass shell via netcat over using WS0 Shell but in many cases the former doesn’t work due to firewall rules, etc. WS0 Shell is PHP-based so the server needs to have a PHP handler installed (most do) and the attacker has to remember that the command is sent and the page is reloaded with the results (if any) of the command being shown. It doesn’t have persistence so the attacker cannot change working directory. This isn’t a huge hurdle, just something to be aware of.