When it comes to improving the security of WordPress it often times seems that security companies more interested in promoting themselves than actually improving security. One company that comes to mind is Wordfence, so it wasn’t surprising to see when they discussed the recent malicious takeover of the Display Widgets plugin it was devoid of any discussion of the real problems this situation highlighted and that need to be fixed, instead it was largely a rather explicit ad for people being reliant on their plugin, when the average WordPress website shouldn’t even need any security plugin if security was being handled right.

Advertising over Proper Security of WordPress

It only takes getting to third paragraph to get to them promoting their plugin:

Wordfence warns you if you are using a plugin that has been removed from the repository. During the past months you would have been warned several times that this plugin has been removed with a ‘critical’ level warning that looks like this:

Further in the post is a whole section promoting how they warn:

The last part of that stands out:

I’m incredibly proud that our team took the initiative and got this feature released in June of this year, just in time to save many of our free and paid customers from being affected by this malicious plugin.

What is striking is while they believe that is so important, they don’t even suggest that this capability should be in WordPress itself. That is something that we have been trying to get to happen for over 5 years. It would be great if Wordfence would get behind that effort instead trying to get people reliant on their plugin. If a security feature is truly needed for the average website, it shouldn’t require an additional plugin or service since that will leave a lot of websites insecure. Of course if your plugin already has 2+ million active installs, you probably don’t have an incentive to make sure WordPress is properly secured since it would negate a lot of the people needing your plugin.

You don’t have to take our word that they want people reliant on their plugin, here is another part of the post where they explicitly say this:

As I mentioned in the introduction, Wordfence would have warned you each time this plugin was removed from the repository. It is important that you have Wordfence installed and have your email alerts configured.

In another section they say knowing that plugins have been removed is part of being “on top of security”:

I would also ask you to not start any witch hunts. I’m sure some folks are angry about what transpired here, but things happen and if you were on top of security, you would have been notified that the plugin was removed from the repository and you would have removed it from your site.

Getting back to that previous section, not surprisingly coming from Wordfence, the rest of what they are saying isn’t really true. The users of their plugin were only warned that the plugin had been removed after it was removed from the Plugin Directory, which means even if they removed it immediately they would have still been affected. But it you look at the second quote there, that person had kept the plugin installed after Wordfence warned about it being removed multiple times.

Seeing as plugins are removed from the Plugin Directory for various reasons, removing a plugin from a website immediately just because it was removed from the Plugin Directory is less than ideal. For example, if a plugin is removed because the developer is no longer supporting it, while you would probably want to move away from it, you wouldn’t have need to do that immediately. This would be another reason for having WordPress notify people, as they would know why it was removed.

Any protection that Wordfence provided was not based on anything they did beyond adding a feature (years after they should have), which brings us to what else is missing from their post.

Those Who Don’t Learn From History are Doomed to Repeat it

One constant in security is change; you have to continually review what is happening and adjust. For example, with our service that has meant an increasing focus of PHP objection vulnerabilities as those became a popular target for hackers. That has lead to us identifying and helping to get many of those fixed before they are exploited on a large scale (and hopefully before they were ever exploited).

When it comes to this situation, Wordfence doesn’t take anything close to a critical look as to what happened on the WordPress side of things. That is particularity striking since they are claiming that how you would have protected yourself from this would be by removing the plugin after it was removed from the Plugin Directory, which has to be done by someone on the WordPress side of things.

The reality here is things did not go right and there isn’t good reason to believe that they will get corrected when they involve issues that have been known for some time and when those in the security industry are more interested in promoting their products and services over even touching on them.

The start of the problems with this plugin are not something we would fault anyone other than the person that took it over. Unlike Wordfence we never mentioned who previously owned it, because that seemed rather irrelevant to what happened after they sold it.

Depending on how ownership is transferred it isn’t necessarily possible to determine if it has been transferred without someone involved publicly disclosing it. It might make sense to provide a process where people could indicate they are transferring ownership, which could provide better insight if something goes wrong, but it would be limited, since someone with malicious intentions would probably try to avoid that happening.

It also is would be very difficult to spot someone first adding malicious code to a plugin if they want to hide what they are doing. The proactive monitoring of changes made to plugins that we do uses checks based in part on previous instances of intentionally (and possibly intentionally) malicious code, but so far we haven’t found anything added this time that we think it would make sense to look for.

Where the fault starts is after the first version by the new owner, which would request a zip file from a remote location and loads code from it on the website. That not only violated the developer guidelines for WordPress plugins, but should have raised serious red flags because even what was presented as the legitimate usage of the files added, which was tracking anyone accessing a website using the plugin, has been the kind of thing that has been done with other software when it has been taken over by bad actors.

Let’s go the timeline included in the Wordfence post for what happened with the next release of the plugin following that occurring:

Then on June 30th, 7 days later, the developer released version 2.6.1 of the plugin. This release contained a file called geolocation.php which, no one realized at the time, contained malicious code. 

The last part is in red in original, so it is really being highlighted. What is never addressed in the Wordfence post is if someone should realized that it contained malicious code. In our looking over the code in that version, based on what was in the previous version it seems like it should have at least raised questions about what is going on. We believe if those questions were asked of the developer the plugin would not have returned. This incident seems like it should be a wakeup call that how things have been has not been working, but if security companies won’t say that, it is less likely to happen.

Changes don’t have to just rely on people on the WordPress side of things. One idea we had mentioned in that post, is that when a vulnerability is fixed in a plugin that there should be a capability for others outside of the WordPress team to be provided information needed to look over what happened and what the fix was, which could also apply for other security issues. That would provide a better chance of things like what happened here being caught. That seems like a really good idea especially when you consider that not only do we frequently find that vulnerability that were supposed to have been fixed haven’t been, but we have specifically found that has occurred with plugins that have been removed from the Plugin Directory.

On July 23rd, Calvin Ngan opened a Trac ticket reporting that Display Widgets was injecting spammy content into his website. He included a link to Google results that had indexed the spam and said the malicious code is in geolocation.php.

On the 24th of July the WordPress.org plugin team removed Display Widgets from the plugin repository for a third time.

On the 2nd of September version 2.6.3 of the plugin was released and it included the same malicious code. Line 117 of geolocation.php in version 2.6.3 even contains a minor bug fix to the malicious code, which makes it clear that the authors themselves are maintaining the malicious code and understand its operation.

On September 7th a forum user on WordPress.org reports that spam has been injected into their website on the Display Widgets plugin support forum.

There is something missing in the timeline that seems important. As we mentioned in one of our posts the information provided in what is linked to for July 23 shows what the malicious code in the plugin was being used for, but also where the malicious code was. Yet the plugin returned at some point before September 7th (Google caching shows it had been returned by at least September 5, but it could have occurred long before that). How did the plugin get returned when it should have been clear that there was malicious code in it?

Accuracy Issues

One of the other problems we often see with things put out by Wordfence is they make claims that are not accurate, which hasn’t so far caused others to have the level of scrutiny of their claims they should receive. The claims are sometimes rather serious, such as a recent claim that a plugin was under attack. There is a glaring one in the timeline, though less serious one, in this post, which we mention, because, as we just said, people should be much more careful before believing or repeating claims made by Wordfence. Here is the first mention of it:

On the 2nd of September version 2.6.3 of the plugin was released and it included the same malicious code. Line 117 of geolocation.php in version 2.6.3 even contains a minor bug fix to the malicious code, which makes it clear that the authors themselves are maintaining the malicious code and understand its operation.

That links doesn’t work anymore; here is a link to the same thing that still works.

They make it again here:

The 2.6.3 release of their plugin makes a minor modification to the malicious code in geolocation.php to fix a bug in the code that lets the plugin author list the malicious posts they have published on your site.

The change they are referring to occurred in version 2.6.2.1, not 2.6.3. The only change made in version 2.6.3 was to fix a supposed vulnerability, which didn’t exist. That seems like it could be an important element to what happened here, but goes unmentioned in Wordfence’s post for some reason.

Update 9/18: After looking at an article at the Threatpost that sourced most of its information from Wordfence’s post, we noticed a more problematic issue related to this inaccuracy. Wordfence inaccurately stated the that versions up to 2.6.3 were contained malicious code:

Actually, the backdoor exists on any site running versions 2.6.1 to version 2.6.3 of the plugin.

Version 2.6.3.1, which Worfdence never mentioned, also contained malicious code.