One of the things that we do to make sure our customer are getting the best protection against vulnerabilities in WordPress plugins is to do monitoring to try to spot when hackers are looking to exploit vulnerabilities in those plugins. In doing that we have found that other security companies that make extraordinary claims about protection they provide don’t do that, even one that claims to have “unmatched access to information about how hackers compromise sites”, despite their ability to provide protection being limited without knowing about vulnerabilities that are being exploited. Something else we have found is that hackers do some odd things, including trying on a large scale to exploit vulnerabilities that have never existed. When security companies are not putting in the work that particular situation can lead to situation like when Wordfence was leading people to believe that a popular plugin had a vulnerability it had never had.

One of the areas of odd activity we have been seeing a fair amount of recently has been what looks to be hackers trying to access malicious files that others hackers may have placed in modified copies of legitimate plugins. This doesn’t make a whole lot of sense since the success rate of those types of attack would be incredibly small. Looking into one recent example of that lead to us finding what looks to be attempts to exploit an unfixed vulnerability that we recently disclosed.

Last week we had a request on this website for a file that would be at /wp-content/plugins/background-image-cropper/image/ico/search.php. That would appear at first glance to be a file for the plugin Background Image Cropper, which currently has 500+ active installs. But in looking at the plugin we found that not only has there not been that file in any version of the plugin, but the plugin doesn’t contain a directory /image/ico/ or /image/ (or any directories for that matter). In looking at the small amount of code in the plugin there was nothing that could have been exploited that could have lead to another file being added to the plugin’s directory.

What looks to have happened is that for whatever reason a hacker had decided to use that particular plugin as part of getting malicious code on to websites by installing a modifed version of the plugin after they have gained access to the admin area of WordPress as Administrator level user. That possibility would match with what is mentioned in a review of the plugin. Then some other hacker was trying to in turn exploit a file added to the plugin by the first hacker. Considering that including legitimate installs the plugin has less than 600 active installs, the success rate for that type of attack is going to be incredibly small.

While reviewing logs files on a hacked WordPress website we were cleaning up over at our main business several days after that, we ran across another attempt to access a file that would ostentatiously be in that plugin, /wp-content/plugins/background-image-cropper/wp-post.php, but again it isn’t in the plugin. In looking at all the requests sent from the same IP address we could see that two other files were attempting to be accessed:

178.170.82.27 - - [23/May/2018:04:04:07 -0600] "POST /wp-uti.php HTTP/1.1" 500 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
178.170.82.27 - - [23/May/2018:04:04:06 -0600] "POST /wp-uti.php HTTP/1.1" 500 303 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
178.170.82.27 - - [23/May/2018:04:04:12 -0600] "POST /wp-content/uploads/kc_extensions/background-image-cropper/wp-post.php HTTP/1.1" 500 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
178.170.82.27 - - [23/May/2018:04:04:11 -0600] "POST /wp-content/uploads/kc_extensions/background-image-cropper/wp-post.php HTTP/1.1" 500 303 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
178.170.82.27 - - [23/May/2018:04:04:58 -0600] "POST /wp-content/plugins/background-image-cropper/wp-post.php HTTP/1.1" 500 0 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"
178.170.82.27 - - [23/May/2018:04:04:53 -0600] "POST /wp-content/plugins/background-image-cropper/wp-post.php HTTP/1.1" 500 303 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"

One of those interesting, /wp-content/uploads/kc_extensions/background-image-cropper/wp-post.php, because part of the path/file name structure was the same as the previously mentioned request. The rest of path, /wp-content/uploads/kc_extensions/, looked like it could be related to exploitation of a vulnerability in KingComposer we recently disclosed after spotting it due to proactive monitoring to catch vulnerabilities before they can be exploited, as exploitation would lead to files being placed in that location. That vulnerability has yet to be fixed by the developer despite us notifying them of it back on April 16.

Nowhere in that set of requests or the others in the logging was there an attempt to exploit the vulnerability in KingComposer, so we couldn’t be sure what was going on there.

In doing some other looking into that, we found what looks like pretty conclusive evidence that there are attempts now to exploit that vulnerability. There are various reports of abusive activity for an IP address that include trying to access a file in the directory that files would go if it was exploited, /wp-content/uploads/kc_extensions/reup/upload.php, and to access the address needed to exploit the vulnerability,
POST //wpadmin/adminpost.phpactionupload. What is also notable there is that the hacker has some understanding of things beyond just looking at our report because in our explanation we showed sending the input “action” as a POST input, but their requests do it as a GET. It is even possible that the hacking is unrelated to our disclosure, as it isn’t unreasonable to believe that hackers could be do the exact same type of monitoring that we do catch that type of thing.

If you were using our service and KingComposer you would have already been warned about the unfixed issue weeks ago and we would have been available to determine how best to handle the situation. Since we have now seen evidence it is being exploited we had the vulnerability to the free data that comes with the companion plugin for our service, so even those not using our service can be warned about. If you are relying on another data source for info WordPress plugin vulnerabilities there is a good chance you still are not being warned since most of those still have not added the vulnerability despite our public disclosure of it over two weeks ago.

If you want to get ahead of vulnerabilities like this, the same check that lead to us identifying the possibility of that vulnerability in KingComposer is included in our Plugin Security Checker tool (which is accessible through a WordPress plugin of its own), so you can identify if a plugin might have the same type of issue and is in need of further checking by using that too.