According to the WordPress website, a staggering 42 percent of the World Wide Web runs on WordPress software. It is not difficult to see why the huge number of WordPress websites around the world is a major draw for attackers. Discovering a WordPress bug allows the attacker to repeat the process hundreds of times. In some cases, they can even automate the process for a rinse-and-repeat attack which could be a real danger for millions of website owners.

This article looks at some of the techniques an attacker can use to gain shell access to a server that is running WordPress. Once they've attained shell access, the attacker can use standard privilege escalation techniques to take full control of the machine.

Pen testers have many ways to describe the structure of an Internet attack (sometimes with seven phases or more), but I prefer to keep things simple. The process starts with an Enumeration phase, where the attacker learns about the components of the target system. Next is an Exploitation phase, which is focused on gaining shell access. I think of the last phase as the Post Exploitation phase, where attackers set up persistence for future access and then start enumerating other resources that the compromised target has access to in order to move around the infrastructure.

Enumerate, Enumerate

To get things started, I'll employ a mind-blowing security tool called WPScan, which the developers refer to as "The WordPress Security Scanner" [1]. You have several options for how to install WPScan. I'll use the Ruby gem installation method. The commands to use on Debian Linux derivatives are

$ apt install ruby-rubygems
$ gem instal wpscan

Once WPScan is installed (Figure 1), I'll point it at the AWS instance, which I will call target.local (by setting the hostname in the /etc/hosts), and then I'll run a scan, as follows:

$ wpscan --url http://target.local --enumerate vp,vt --api-token XXXXXXXXXXXX

Figure 1: The scan begins, following a threat intel update.

The vp switch asks WPScan to look for vulnerable WordPress plugins and report back. The other switch that I usually use is vt, which stands for vulnerable themes. To get as much data as possible, I'm also adding an API token (which is free and has a limit of 25 API accesses a day if you register first at wpscan.com).

The output from WPScan is eye-watering. It's lengthy and really detailed, with lots of reference URLs. Sections in red text indicate the WordPress build is likely to be vulnerable. In this case, I will focus on a vulnerability that I discovered in a Capture the Flag (CTF) challenge on the TryHackMe website [2]. The highly recommended TryHackMe (THM) is ideal for getting started and then moving from beginner levels of knowledge to advanced. Needless to say, there are very good reasons why the TryHackMe site is so popular (over a year ago they had a million users and seem to have doubled that number since [3]).

The vulnerability relates to a bug in the WordPress Core 5.0. In the first example, I will make use of a frankly frighteningly easy-to-use penetration testing tool called Metasploit [4]. The alarming thing about Metasploit is the level of automation it provides. The user only needs to add a few pieces of information and type run. The success rate, once a vulnerability has been correctly identified, is remarkably high. Metasploit is used by users with low-to-moderate levels of experience. That doesn't mean elite users don't turn to it for some easy automation at times. Understanding precisely how and why the tool interacts with target systems tends to require more advanced knowledge, although the tool pulls together information from all over the web, including the Exploit Database [5]. If you haven't used it before, you should take a moment to appreciate the power of the Exploit Database. Check out the Exploit Database entry for the exploit described in this article [6].

Taking Advantage

To save time and simplify, I will look at this particular exploit after completing the first phase, i.e., after I have already enumerated the target and managed to glean a (non-admin) username and password for WordPress.

In this case, I found a bug courtesy of WPScan. The scan identified a vulnerability that allows Remote Command Execution (RCE). The goal is to open a remote shell on the WordPress server and then move from a low-level, non-root user to the superuser root account. Figure 2 shows what a successful Metasploit search of the built-in modules reveals when looking for the Crop-image vulnerability. According to some of the online documentation, the Crop-image attack relates to CVE-2019-8943 [7], which states that an authenticated attacker who has permissions to crop an image can then save the resulting image to an arbitrary directory and use the output file to their advantage. This type of issue is referred to as "Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')."

Figure 2: We have a match for Crop-image in Metasploit.

The next steps are to offer Metasploit some options for the attack. In this case, I will offer the target's IP Address (set as target.local on my system). Then I'll offer the username and password that I have gleaned from WordPress already. (Imagine that you found a username from a user's posts on the website and then ran 100,000 passwords against the user in a brute-force attack on the WordPress login screen to discover the credentials.)

Finally, I need to add the local IP address of my laptop and an open TCP port so that, if the exploit is successful, the WordPress server will phone home back to my laptop. This process is known as a reverse shell (see the article on reverse shells elsewhere in this issue). With the handful of options fed into Metasploit, type run and you will see the process underway in Metasploit.

As you can see in Figure 3, the mighty Metasploit is crafting a payload and then uploading it as an image before using the image in WordPress's active website theme.

Figure 3: Running the code in the Exploit Database to exploit the RCE bug.

If the attack is successful, the attacker is welcomed by the server that is running WordPress with a shell. In this case, I have access as the www-data user. The www-data account is a non-root user and is typically used to run the Apache web server. I can now type commands to stabilize the shell and then begin Privilege Escalation techniques remotely, just as if I were logged into one of my own servers over SSH.

Another Route to Root

Now that you've seen Metasploit weaving its magic, I'll show you how to get a reverse shell to work using a more manual process. A common way that (usually authenticated) attacks of WordPress gain access to a shell is via the UI itself. Once you authenticate with WordPress, you are presented with a dashboard. The permissions are usually limited in some way. In this example, you will need a user who can edit website template content, as part of a (usually running) WordPress theme. I will use the admin user I have created for this example. Incidentally, I need to navigate to the login page using the following address:

https://target.local/wp-login.php

Following the big welcome banner, I click the Appearance link on the left-hand navigation menu. I am then presented with the dashboard displayed in Figure 4.

Figure 4: The WordPress Themes page.

In Figure 4, you can see the blue Customize button for the Twenty Twenty-Three theme. Now look at the Appearance | Themes | Editor link on the left-hand side. I use the following URL to reach the file I am after:

https://target.local/wp-admin/theme-editor.php?file=patterns%2Fhidden-404.php&theme=twentytwentythree

I'm aiming to adjust the hidden-404.php page, but you can update other pages and test with them too. In previous WordPress versions, the 404.php page is used commonly for this purpose.

A different-looking page opens up under Tools | Theme File Editor, showing lots of website code, as you can see in Figure 5. Now I need to scroll down the files listed on the right-hand side of the screen. When it comes to some filenames, you can see the names of the files, ending with the .php extension, under each of the more human-readable titles of each page. I'm looking for a file called hidden-404.php (or you can use the full link that I used previously and adjust target.local to your needs).

You might well ask, why are you looking for a 404 file? It's a reasonable question. What you might not fully appreciate is how servers configured to run the PHP language treat files ending with the .php extension. They essentially execute them, running them just like a script might run.

As an authenticated user with access to the WordPress UI, my aim is to alter the code in the 404 template file and then either visit a website page that doesn't exist (to trigger a Page Not Found 404 error) or, in this case, visit the URL directly and load that template page directly. WordPress will then phone home via a reverse shell.

The PHP code for a reverse shell comes from the PenTestMonkey website [8]. If you want the code directly (because you've practiced this before), go to the GitHub repository [9] and find the file php-reverse-shell.php. Click Raw on the right-hand side for a clean cut-and-paste method. This is one of the most popular reverse shell snippets, and it hasn't been edited in GitHub since 2015, so it must be good!