The module can be selected in the Metasploit console by using the following command:

use exploit/multi/http/wp_crop_rce

The following screenshot shows the output of the preceding command:

We set the required options as shown in the following screenshot. We will need a low privilege account on the WordPress blog, as this vulnerability requires authentication as well as the privilege of uploading and editing media:

The exploitation happens in several steps. The first step that the Metasploit module does is check whether the targeturi provided is correct or not:

On getting a 200 HTTP response code, it confirms the targeturi path:

The module continues to the next step—authentication. The username and password used for the module will get used in this step. While authenticating with the WordPress site, the module also requests for redirection to a non-existent page:

The HTTP response will be a redirection (302) to a page that doesn't exist. This is done just to get the session cookies from the server. Everything after this step is accomplished using these cookies:

Let's confirm the database status:

Now that the session is retrieved from the server, in the next step, the module requests the media-new.php page. This page is responsible for media uploads to the WordPress site:

The objective here is to upload an image with our payload embedded in it:

The module then uploads the image embedded with our payload in it:

As we can see in the preceding screenshot, the payload embedded in the image is <?=`$_GET[0]`;?>. The reason we used such a compressed payload is that we don't have much space left for our payload to get executed. Also, notice that the payload is embedded in two different places—just after the scan header and in the EXIF metadata. The reason it's embedded twice is to make sure the payload gets executed.

WordPress supports two image editing extensions for PHP: GD Library and Imagick. GD Library compresses the image and strips all EXIF metadata. Imagick won't strip off any EXIF metadata. That is the reason the module embeds the payload twice.

The path and the post metadata at the time of upload are stored in the database:

Once the malicious image is uploaded, an ID is allotted to the image with its full path in the response:

The module checks whether the WordPress site is vulnerable to CVE-2019-8942 and CVE-2019-8943 or not. It does this in the following steps:

1. It confirms whether the image is uploaded or not by querying all of the attachments.
2. It makes sure that the malicious image is saved with a size of 400 x 300. (This will help when the fake crop is done.)

3. It gets the updated wp_nonce and updated filename when editing the malicious image.
4. It checks whether the POST metadata entry for the image can be overwritten from .jpg to .jpg?/x or not. If it's changed, it shows that the WordPress site is vulnerable to CVE-2019-8942.
5. It crops the image (a fake crop here) to check whether the WordPress site is vulnerable to CVE-2019-8943, a path traversal vulnerability.
6. Once the module confirms the vulnerability, it exploits CVE-2019-8942 by overwriting the POST metadata from .jpg to .jpg?/../../../../themes/#{@current_theme}/#{@shell_name}:

The following screenshot shows the updated value of the meta_value column:

We can also see in the following screenshot that the default template has been changed to cropped-zAdFmXvBCk.jpg:

The module then requests the default template with the post ID and appends the 0 parameter with the command to execute for RCE:

The output for the command is in the following response:

Next, the module does the following:

1. It confirms whether the Base64 program exists in the system or not.
2. It converts the PHP meterpreter into Base64 and uploads it to the server using echo <base64_of _PHP_meterpreter> | base64 -d > shell.php.
3. It requests the uploaded PHP shell to get meterpreter access.
4. The following screenshot shows the Base64 encoded meterpreter code being written into the PHP file:

The following screenshot shows a successful meterpreter connection from the server:

In the next section, we will customize the Metasploit exploit.