One of the ways that we keep track of vulnerabilities in WordPress plugins is by monitoring what look attempts at hackers request for files in plugins on our websites and in some third-party data. One of the problems we have seen recently in others looking at similar data is that they don’t do proper due diligence before making claims based on that data. A couple of weeks ago we looked at how Wordfence was falsely making people think there has been a vulnerability in very popular plugin. While looking into some possibly malicious requests recently we found something similar happening with the much less popular plugin Libravatar Replace. A couple of days ago new thread was created for the plugin on the WordPress Support Forum that reads:

Hey, I do not use this plugin but my website was scanned by a UK IP trying to locate:
http://[redacted]/wp-content/plugins/libravatar-replace/libravatar-replace.php

So, this tells me that the libravatar-replace.php file is vulnerable for hackers. Please make changes to tighten up this php for users of your plugin.

As we will get in to more detail in a second we have also had requests for that file.

If you look at the file in question you will see that the first code in the file will stop the file’s code from running if you access it directly:

16
17
18

if (!defined('WP_PLUGIN_DIR')) {
    die('There is nothing to see here!');
}

That same code exists going to back to the first version of the plugin submitted to the Plugin Directory, which was submitted four years ago.

So why would a hacker be requesting that file? One fairly obvious answer is that they are checking to see if the plugin is installed, since requesting it would cause the message in the die() function to show. So they might be checking to see if the plugin exists and then try to exploit something in the plugin. But in looking over the plugin’s code we didn’t see anything that looked like it could be a vulnerability that a hacker would be exploiting.

Taking a look at all of the requests sent by the same IP when this file was requested pointed in another direction.

In the more recent set of requests on this website you can see that there were two requests sent to the file:

97.107.133.224 - - [21/Aug/2017:05:41:18 -0400] "POST /wp-content/plugins/libravatar-replace/libravatar-replace.php HTTP/1.1" 301 595 "pluginvulnerabilities.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
 97.107.133.224 - - [21/Aug/2017:05:41:18 -0400] "GET /wp-content/plugins/libravatar-replace/libravatar-replace.php HTTP/1.1" 404 43075 "pluginvulnerabilities.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"

The first is a POST request, which indicates that some additional data was sent with the request. That wouldn’t make sense in the context of hacker checking if the file existed. The second request is probably due to our server telling the requester that they should be accessing the URL over HTTPS.

With the older set of requests things start to make more sense. You can see that for a series of files, including that file, a POST and then a GET request is sent to each file.

69.163.185.19 - - [05/Aug/2017:23:50:21 -0400] "POST /pdo.inc.php HTTP/1.1" 301 497 "pluginvulnerabilities.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
 69.163.185.19 - - [05/Aug/2017:23:50:22 -0400] "GET /pdo.inc.php HTTP/1.1" 404 42413 "pluginvulnerabilities.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
 69.163.185.19 - - [05/Aug/2017:23:51:17 -0400] "POST /viewport-compatible.php HTTP/1.1" 301 521 "pluginvulnerabilities.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
 69.163.185.19 - - [05/Aug/2017:23:51:17 -0400] "GET /viewport-compatible.php HTTP/1.1" 404 42449 "pluginvulnerabilities.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
 69.163.185.19 - - [05/Aug/2017:23:51:28 -0400] "POST /wp-content/themes/sketch/404.php HTTP/1.1" 301 539 "pluginvulnerabilities.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
 69.163.185.19 - - [05/Aug/2017:23:51:29 -0400] "GET /wp-content/themes/sketch/404.php HTTP/1.1" 404 42485 "pluginvulnerabilities.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
 69.163.185.19 - - [05/Aug/2017:23:52:14 -0400] "POST /wp-content/uploads/uploads_.php HTTP/1.1" 301 537 "pluginvulnerabilities.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
 69.163.185.19 - - [05/Aug/2017:23:52:15 -0400] "GET /wp-content/uploads/uploads_.php HTTP/1.1" 404 42479 "pluginvulnerabilities.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
 69.163.185.19 - - [05/Aug/2017:23:54:39 -0400] "POST /wp-admin/css/colors/blue/post_controller.php HTTP/1.1" 301 563 "pluginvulnerabilities.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
 69.163.185.19 - - [05/Aug/2017:23:54:40 -0400] "GET /wp-admin/css/colors/blue/post_controller.php HTTP/1.1" 404 42524 "pluginvulnerabilities.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
 69.163.185.19 - - [05/Aug/2017:23:56:13 -0400] "POST /stcchatcc.php HTTP/1.1" 301 501 "pluginvulnerabilities.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
 69.163.185.19 - - [05/Aug/2017:23:56:14 -0400] "GET /stcchatcc.php HTTP/1.1" 404 42419 "pluginvulnerabilities.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
 69.163.185.19 - - [05/Aug/2017:23:57:39 -0400] "POST /wp-temporary.php HTTP/1.1" 301 507 "pluginvulnerabilities.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
 69.163.185.19 - - [05/Aug/2017:23:57:40 -0400] "GET /wp-temporary.php HTTP/1.1" 404 42428 "pluginvulnerabilities.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
 69.163.185.19 - - [06/Aug/2017:00:00:56 -0400] "POST /wp-content/plugins/libravatar-replace/libravatar-replace.php HTTP/1.1" 301 595 "pluginvulnerabilities.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
 69.163.185.19 - - [06/Aug/2017:00:00:57 -0400] "GET /wp-content/plugins/libravatar-replace/libravatar-replace.php HTTP/1.1" 404 42569 "pluginvulnerabilities.com" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"

For other files that requests are being sent to there, they clearly shouldn’t exist. For example, there shouldn’t be a file at /wp-admin/css/colors/blue/post_controller.php. Based on that, what looks like what might have happened is that some hacker was placing a backdoor script at /wp-content/plugins/libravatar-replace/libravatar-replace.php when they hacked websites and then other hackers are trying to utilize that file as well other files that hackers would place on websites. The POST requests make sense in that context because often the commands being sent to a backdoor script are handled as POST inputs.

Giving further credence to that theory is the other thread for the plugin on the Support Forum, which seems to involve a hacker placing malicious files in the directory were the plugin would be located (but the directory was missing the rest of the files that would be there if the plugin was actually installed).