In the past few days we have seen what appear to be at least two hackers probing for usage of the WordPress plugin Download Monitor, which has 100,000+ installs. In looking into what might explain that, we found that there was a vulnerability that hackers would try to exploit that was partially fixed shortly before the probing started. Thankfully, there are some important limitations to it being exploitable.

The changelog for a recent version of the plugin had a concerning entry:

Fixed: Security issue regarding file uploading ( #1276 )

Looking at the linked Github issue raises more concern, as it in turn linked to a commit that was restricting what WordPress users could access an upload function and, more importantly, was restricting the file extensions that can be uploaded.

That involves the function upload_file(), which is AJAX accessible to anyone logged in to WordPress:

28

add_action( 'wp_ajax_dlm_upload_file', array( $this, 'upload_file' ) );

Here is the relevant code in the function, which is located in the file /src/Admin/WritePanels.php, before the changes mentioned above were done:

613
614
615
616
617
618
619
620
621
622
623
624
625
626
627

public function upload_file() {
 
	$uploadedfile = $_FILES['file'];
 
	$image_url = $uploadedfile['tmp_name'];
 
	$upload_dir = wp_upload_dir();
 
	$image_data = file_get_contents( $image_url );
 
	$filename = $uploadedfile['name'];
 
	$file = $upload_dir['basedir'] . '/dlm_uploads/' . date( 'Y/m/' ) . $filename;
 
	if ( ! file_put_contents( $file, $image_data ) ) {

That would allow an attacker logged in to WordPress to upload arbitrary files, including malicious PHP files.

There are a couple of important limitations on exploiting this.

First, this will only work if the directory the file is stored in has already been created, because of usage of the function file_put_contents(). So either someone would have to have uploaded a file through the plugin’s admin interface during the current month or an attacker would have to find some way to generate the relevant directory.

Second, the plugin creates a .htaccess file to block direct access to uploaded files. So on Apache and other web servers that utilize .htaccess files, an attacker could directly call the uploaded file and would need an additional security issue to get the code in a PHP file running. For web sites hosted on other types of web servers, the plugin warns that this protection doesn’t work for them.

We tested and confirmed that our firewall plugin for WordPress protected against the type of exploitation of this vulnerability you would see in a mass hack, even before we discovered the vulnerability, as part of its protection against zero-day vulnerabilities.

What wasn’t changed in the new version or the subsequent version, was a nonce check to prevent cross-site request forgery (CSRF), so an attacker can still cause someone logged in to WordPress that is allowed to upload files to do that without intending it. We have notified the developer of that.