14 Dec

Thousands of Websites Still Using WordPress Plugin that Has Vulnerability That Started Being Exploited Over a Year Ago

One of the ways that we keep track of vulnerabilities in WordPress plugins is by monitoring our websites and some third-party data for evidence of hackers are targeting plugins. Earlier this week that lead to us to us looking into a couple of plugins and finding vulnerabilities that hackers may be interested in, we have yet to get any definitive timetable on when or if those will be fixed by the developers, despite asking for that (the only response was that they would look into the issues), so we will probably be disclosing those tomorrow since hackers may already targeting something in the plugins. In the meantime, yesterday we had a request that looked to be probing for the plugin Form Lightbox:


That plugin was removed from the Plugin Directory in July of last year after a hacker started exploiting a vulnerability in it. It used to be when that happened that the page on the Plugin Directory for the plugin would disappear. Recently things have changed so that the page remains and previously removed plugin’s pages have returned. One of the things that means is that you can see how many active installations a removed plugin still has. As of the time the plugin was removed it had 10,000+, which indicates that there were between 10,000 and 19,999 installations of the plugin.

As of today the plugin still 6,000+ active installations:

So there are still 6,000 and 7,000 websites still using it, despite having a vulnerability that hackers have exploited and still could as the vulnerability was never fixed. It’s possible that on some of those websites the vulnerabilities has been resolved by modifying the plugin, but we would guess that didn’t happen with many of them.

With that change it also easy to access the support forum for removed plugins and see what has been mentioned since they were remove. One the threads started since this plugin was removed shows the problem of not telling people why plugins have been removed, as people will still being looking to start using the plugin and not knowing that there is an issue.

It seems odd to us that WordPress would decide to display the number of active installs in this situation as it would make it easier for hackers to decide what vulnerabilities are worth targeting, while not warning people that it contains a vulnerability, which hackers appear to have been aware of before anyone else with this plugin.

Avoiding Using Vulnerable Plugins

There are a couple of obvious things that people on the WordPress side of things could do to help in situation like occurred with this plugin. 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 this plugin 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 Form Lightbox would have been warned about the issue shortly after the exploitation started.

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. One recent example of that involves an arbitrary file upload vulnerability in the most recent version of the plugin PHP Event Calendar, which we disclosed and added to the plugin’s data on November 27. More than two weeks later none of the other free sources we are aware, which are the WPScan Vulnerability Database, ThreatPress Vulnerability Database, the plugin CWIS Antivirus Scanner, or the post of the website WPCampus, have included it.

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).

17 Aug

WordPress Doesn’t Fix Severe Vulnerability in Plugin And Doesn’t Want To Have An Honest Discussion About the Issue

Recently we have been having an issue where someone (or someones) that has the ability to edit and delete post on WordPress’ support forum had been doing those things to some of our posts on their support forum. Last week discussed on such instance where that look liked an attempt to cover up the fact that WordPress has an ongoing problem where plugins they know contain a vulnerability that have been removed from the Plugin Directory due to that, then return to it without the vulnerability being fixed. Over at our main blog we discussed that it appears that whomever is doing it doesn’t want the public to know what is going, as in another instance they also deleted a reply to a post of ours that just thankedus for the information we provided, which if it remained, would have made it obvious that a post from us had existed and had been deleted. While preparing to write this post about the issue of WordPress’ handling a vulnerability in a plugin that appears to have been abandoned, we noticed that another such instance of a deletion that looks like an attempt to cover up yet another piece of WordPress’ current poor handling of vulnerabilities in plugins.

On July 17 we saw requests for a .css file from the plugin Form Lightbox across our websites. That is usually an indication that a hacker is probing for usage of the plugin before trying to exploit a vulnerability in it. Seeing as the requests hit all of our websites, that pointed to there probably being a large campaign to exploit something in the plugin. After noticing the request we started trying to figure out if there was a vulnerability so that we could add it to our data and see what we could do about getting it fixed. We quickly found an option update vulnerability in the plugin, which would allow anyone to change WordPress’ options (settings). One possible way that could be exploited is to turn on user registration and set it so that new users had the Administrator role, giving the attacker the ability to do almost anything on the website. Later in the day the plugin was removed from the Plugin Directory, so at least one other person had noticed the issue and notified the Plugin Directory before we had done so.

On July 20 a post was started on the support forum for WordPress, Plugin disappears from repo as vulnerability is revealed?. The original post was later edited, but from a cached copy here is how it read (the bolded portions were later removed by someone else with the ability to do that):

Is there any rules about triaging security vulnerabilities in plugins?

I was a fan of Form Lightbox {DEAD LINK}, a simple plugin that let you embed a form in a lightbox.

According to Google’s cache, it was still available on 16/7, 2 days before this was published:

https:// www.pluginvulnerabilities.com/2016/07/18/option-update-vulnerability-in-form-lightbox/

There’s a giant security hole in the plugin. I’ve had 4 sites exploited using it. A simple google search reveals a number of others that have been bitten.

If WordPress.org pull the plugin (in line with the disclosure practices of pluginvulnerabilities.com) , and the author fails to patch it, and make it available again, can someone else step up, take it over and issue a patch?

Otherwise, those affected are left high and dry (until they find out how their sites are being pwned, by other means).

The “WordPress.org Tech Dude” responded:

If WordPress.org pull the plugin, and the author fails to patch it, and make it available again, can someone else step up, take it over and issue a patch?

If we pull the plugin for security reasons, then the author usually patches it. If it’s severe enough, we may patch it ourselves after an author does not respond. This is handled on a case by case basis.

After noticing the thread through our monitoring of the support forum for vulnerability related issues, we saw that there were a number of problems with that reply, which we address in a reply that was deleted some time later:

Seeing as we are the people that are reporting many of the vulnerabilities to the Plugin Directory that cause plugins to be pulled, we can say that the reality is that plenty of those plugins never get fixed. In other cases they are not fixed in a timely manner. Also, in some cases you guys put the plugin back in the Plugin Directory even though the vulnerabilities have not actually been fixed, including a recent case where it looks like a hacker had been exploiting a plugin prior to it being removed from the Plugin Directory.

In the case of the plugin mentioned here, a security issue doesn’t get much more severe than this. Not only does the plugin have an easily exploitable vulnerability, but it appears that a hacker is already exploiting it. That is how we became aware of the issue in the first place.

As mentioned in the post cited above, the plugin was removed before our post was released, so the post’s release had nothing to do with the plugin being removed.

If you used our Plugin Vulnerabilities plugin you would have been warned about this vulnerability a couple of days ago, since we include data on vulnerabilities in plugins that have hacking attempts against them in the free data included with that plugin.

There was never any reply to our reply, so it seems that no one from the WordPress side wanted to dispute anything we had said in it. They then could have taken it as wake up call that things need to be improved (something we would happy to help them with). Instead at some point later our post was completed deleted without any notification to us that it in some way violated any policy on the forum. What has happened with the plugin since then, shows that, not surprisingly, trying to cover up things in this way doesn’t actually deal with the issue.

If you go to the plugin’s page on the Plugin Directory now you will see that it is still removed (the message mentioning that it has been removed in the screenshot was added to the page by the Plugin Vulnerabilities Chrome extension):


That doesn’t always mean that nothing has been done, as from what we have seen from checking on what is happening with other plugins with vulnerabilities is that there can sometimes be a significant delay between the developer submitting a new version to the underlying the Subversion repository and the plugin returning to the Plugin Directory (probably due to some review of the fix needing to occur first). In this case though, the most recent change to the plugin remains one from three years ago:


As we mentioned in our reply in that post, “In the case of the plugin mentioned here, a security issue doesn’t get much more severe than this.”, so if WordPress is going to patch severe vulnerabilities when the plugin’s author this seem to be one where that should have happened. That means that for the 10,000+ websites using the plugin (according to wordpress.org, as of the time the vulnerability started being exploited) are left without a secured version to update to. We don’t think that WordPress necessarily should be expected to fix any vulnerabilities in plugins, but what they should at least do is notify those using plugins that they are vulnerable. That is something that they could have done long ago, but they continue to refuse to do it on the basis that it would put websites at risk, which doesn’t make much sense in case like this, where a hacker is already exploiting the vulnerability on a large scale and others are able to easily identify an exploitable vulnerability in the plugin.

18 Jul

Option Update Vulnerability in Form Lightbox

Recently, what has probably been the most important way we have been finding new vulnerabilities in WordPress plugins, so that we can notify our customers and they can take appropriate measure to protect themselves, has been by monitoring our websites for what looks to be probing for the usage of plugins. That usually indicates that a hacker is looking to exploit a vulnerability. Yesterday we had requests across our websites for the file /wp-content/plugins/form-lightbox/colorbox/style-1/colorbox.css, which is part of the plugin Form Lightbox and according to wordpress.org it has 10,000+ active installs.

A quick look through the plugin’s files for what would be of interest to hackers brought us to the file /ajax.php. That file starts up WordPress and then allows the requester to update and delete WordPress options:

$root = dirname(__FILE__);
$position = strrpos($root, "wp-content");
$wp_installation = substr($root, 0 , $position );
include( $wp_installation.'wp-load.php' );
$_POST = array_map( 'stripslashes_deep', $_POST );
$action = isset( $_POST['action'] ) ? $_POST['action'] : false;
switch ( $action ) {
	case 'update_content' : 
			update_option( $_POST['update'], $_POST['value']); 
			$start = false;
			$new_options = array();
			foreach($flb->options() as $value){
					$new_options[] = $value;
				if($value['type']=='open_ajax' && $value['id'] == $_POST['ajax'])
					$start = true;
				if($value['type']=='close_ajax' && $value['id'] == $_POST['ajax'] . "_close")
	case 'update_option' :
			update_option( $_POST['id'], $_POST['value'] );
	case 'delete_option' :
			delete_option( $_POST['id'] );

The code doesn’t include any restrictions on who can make changes to the options and the plugin does not need to be activated for the code to function. With the ability to change WordPress’ options, a hacker could do a lot of things. One obvious thing they could do is to turn on user registration and set newly registered accounts role to be Administrator, so they can create an account that has full access to the admin area of WordPress.

The plugin hasn’t been updated since 2013, so the chances of it being updated by the developer now are not great.

For once we don’t seem to be the only ones that noticed that a hacker was interested in the plugin, as sometime after we started looking in to this yesterday, the plugin was removed from the Plugin Directory, which would be done after the the people running it are notified of a security issue. Our guess as to why that occurred this time and has in many other instances is that the whoever probing for usage of the plugin was doing it across more website than is usually done.

Proof of Concept

The following proof of concept will turn on user registration.

Make sure to replace “[path to WordPress]” with the location of WordPress.

<form action="http://[path to WordPress]/wp-content/plugins/form-lightbox/ajax.php" method="POST">
<input type="hidden" name="action" value="update_option" />
<input type="hidden" name="id" value="users_can_register" />
<input type="hidden" name="value" value="1" />
<input type="submit" value="Submit request" />