One part of penetration testing is re-testing companies to confirm that the vulnerabilities disclosed in the first round are now non-existent and properly secured.  In this machine, Raven Security, a company that was breached in an earlier attempt, brings a new challenge to the pentesting team after securing their web application. The author says that this machine is an intermediate one. This is based on it containing a rabbit hole and understanding how an exploit runs and modify the code according to the application at hand. The machine can be found on VulnHub, so go pull down a copy and lets jump right in!

Information Gathering

Starting off, netdiscover allows us to find out the IP on the internal network of the virtual network. netdiscover -i eth0 -r 192.168.56.0/24 where -i stands for the interface and -r stands for the network range that we want to scan.

After identifying its location, knowing what's running on it comes next. In addition to NMAP, unicornscan will be used to confirm the results. Unicorn is super fast in scanning for the ports, whereas NMAP can be awesomely used to discover the services running on the ports and provide enough information.

Following the generated results, 22, 80 and 111 are open. Knowing the services, port 22 can't be easily exploited, the only possibility is to brute force it. Port 80 is the hottest one to be tackled. Port 111 is the rpcbind service which tells that there is a RPC application program running. Not that interesting.

Web Busting

After prioritizing our services, web directory busting begins using gobuster:

Looking at those findings, another gobuster process is ran on the wordpress directory, which is in general, a juicy spot.

Without noticing, I was slowly sliding down a rabbit hole. I ran 2-3 bruteforcing attacks on the login process for the users with different password lists. While doing the last attack, I stepped back, and remembered that there is way more to this than the wordpress section.

Looking around in the web directories, /vendor came out to be crucial to this box.

This was the vendor directory for PHPMailer. Looking closely into those files:

Lookie there! Flag 1. This is a clear sign that we are on the right track. Looking at the VERSION next:

This could lead to something! Using the infamous searchsploit:

This service is pretty vulnerable! Using the python exploit from exploit-db, a couple of parameters needed modification. That was identified by checking where the PHPMailer was being used, in comparison to where it was used in the PoC. In our scenario, it was under /contact.php as opposed to the PoC, /.

target = 'http://raven.local/contact.php'
The reverse shell needs to point to the current machine IP and port.
And last, the path to the backdoor script:
'email': '"7hunder\\\" -OQueueDirectory=/tmp -X/var/www/html/backdoor.php son\" @twitter.com',

If it wasn't clear, the fields set are the POST parameters to be sent. Running the exploit, a reverse shell is received:

Privilege Escalation

In the normal privilege escalation process, the privilege checker is ran to try and identify issues in the installation and setup of the system. One crucial process shines out. Mysql is ran with the root user!

After checking its version, an exploit was found for it!

This exploit was missing a user and a password to access that DB. Nonetheless, a WordPress application exist, and with it comes to life the wp-config.php file which is always interesting to grab.

After logging in, Steven and Michael credentials were gathered and stored locally in order to try and break them later on.

As for the exploit, we are ready to attack the vulnerable application. Following that exploit-db guide, and combining it with the following blog, we get a functioning shell.

One last step for us to wrap up. Get the flags!

Attempting to grab the passwords for steven and michael for later usage, neither the MySQL credentials nor the /shadow hashes were decrypted using multiple wordlists.

Conclusion

The machine contained some known issues, such us having an application running as root, or using a vulnerable application version, and these are dangerous liabilities on the application owner! Being offensive while building an application can bring up to the table lots of benefits, from building up the application, to setting it up. The author can be found on the following: https://wjmccann.github.io/

If you enjoyed my writing you can find me on Twitter as @7hunderson.