Disclaimer: This post demonstrates hacking techniques and could be considered dangerous. I’m doing this for my own personal research using freely available tools and information, and testing against a vulnerable machine specifically designed for security assessments that has been installed in my own personal lab isolated from the public Internet. Please do not use these techniques against any computer system that you either do not own or do not have permission to work on.
Keeping with the spirit of hacking into things, I wanted to do another walkthrough of a vulnerable box from VulnHub called WebDeveloper 1. Mainly because it’s fun, and it’s good practice.
Using netdiscover in Kali, I’ve determined the target IP address is 10.0.2.30, with the Kali Linux box itself being 10.0.2.29.
Proceeding with an nmap scan. Looks like the only ports that are open are ports 80 and 22 for HTTP and SSH.
Opening up a browser I can see a WordPress site with not much else going on.
Using Gobuster to scan for directories I only discover a few standard WordPress directories.
Navigating to /wp-content/uploads shows that directory listings are enabled. This is a server misconfiguration with information disclosure, so I’ll make a note of that.
A Nikto scan doesn’t appear to show any super juicy vulnerabilities, nothing really jumps out at me like with Kioptrix.
I’ll use wpscan to scan for WordPress vulnerabilities, with the enumerate users option to discover any WordPress user accounts.
The output from wpscan is too long for a screenshot, but we found the WordPress core and theme version numbers, both of which are out of date, and discovered the user ‘webdeveloper’.
After spending a bit of time looking around and not really finding much, I ran another scan with dirb and noticed something that I almost missed.
A directory called ipdata. Opening that in a browser shows a directory listing with a single file analyze.cap. This is a network traffic capture file. Let’s download that.
After digging through the file with Wireshark for a bit, I found a HTTP POST request to the /wp-login.php page, and in the form data of the request is the WordPress username and password.
Copy and pasting the username and password into the WordPress login form gives us access to the /wp-admin area. We’re in.
I’m going to try and get a reverse shell on the server by modifying one of the WordPress theme files. Navigate to the WordPress theme Editor, Select the TwentyFifteen theme from the dropdown, and select the 404.php. I’ve got the browser extension called ‘Hack-Tools’ installed which lets us create a reverse shell in different programming languages. Selecting PHP and filling in the details of theattack machine IP and a port number. I’ll also need to create a listening server on the attack machine before we can execute this.
Copy the PHP code that’s generated by Hack-Tools, paste it in the theme Editor and click save.
Navigating to the Theme page to activate TwentyFifteen. I’ll also need to start a listening server on Kali. I’ll use Netcat and listen on port 1234.
If I navigate the browser to a rubbish page I should trigger the 404 , which if I set it up correctly, should connect out to the Kali machine and establish a reverse shell, meaning I can now interact with the target machines command line.
I’ll grab the /etc/passwd file while I’m here, because I like to collect things. The shell I have is for www-data user, so it’s a pretty low-privileged system account, there’s not much I can do. The www-data user is setup specifically for apache and only has access to the things apache needs to serve web content, but this does mean I have access to the website files so before I do anything else I also want to grab the wp-config.php file with the database credentials.
The database user is also the same user as the WordPress user and the Linux user that’s in /etc/passwd. Although the database password is different than the password we used to log into WordPress with, I might try both passwords I have for the webdeveloper user and try to login with ssh.
The password for the WordPress account doesn’t work. But the database password does, giving me access to the server.
This webdeveloper is a normal user account compared to the limited www-data account, I wonder what they can do with sudo? As it turns out, this user can run tcpdump with root permissions.
A quick check of GTFOBins for tcpdump gives some instructions on how to escalate privileges. I’ll give it a try.
Following the instructions on GTFOBin and with a little bit of experimentation, I can execute the id command as root. The privilege escalation worked, but lets try something more exciting than id.
I changed the COMMAND to cat the /etc/shadow file, again because I like collecting things. Now I have the password hashes too.
I played around with a few different commands trying to get a root shell. The tcpdump privilege escalation will only allow non-interactive commands to run as root, so trying to get it to log in as the root user or anything like that kept failing.
I had a look in the webdeveloper’s home folder and there was no ssh key, but using ‘ls -la /root/.ssh’ with the tcpdump command showed that there was an authorized_keys file. As the webdeveloper user I generated an ssh key, and then modified the tcpdump command to cat the public key to root’s authorized_keys file. I wasn’t sure if it would work but I wanted to try.
It worked perfectly. I have a root shell!
Maybe not the most elegant privilege escalation, but this box is now pwned.