Security isn’t in great shape these days and that certainly applies to WordPress plugins as some recent issues we have run across have reminded us. As we see it, one of the causes of this is that real problems with security rarely get discussed. There are probably many factors at play to cause that, but one that we see is that people will criticize you if you say anything they interpret to be negative when it comes to security (the irony of that seems lost on them). That seems to lead to a lack of honesty about what is going on and instead a focus on happy talk that doesn’t resolve the problems, even though many could be fixed without much effort if there was an interest in doing that.
An example of not discussing the real problems comes up with a post we ran across from the blog of WordPress web hosting company Pagely. The post discusses the increasing issue with PHP object injection vulnerabilities in plugins, but hidden below the surface of the post is a couple of problems that writer clearly is aware of, but doesn’t disclose. The relevant section of the post is the following: [Read more]
Yesterday we announced we have temporarily ended our notifications to the WordPress Plugin Directory when there are plugins with disclosed vulnerabilities in the current version of the plugin that is in the directory, until they put forward concrete plans to resolve two issues. One of those is finally warning people when they are using plugins that have been removed from the Plugin Directory for security issues. While years ago they claimed they were working on doing this, more recently they have claimed that doing so would put people at more risk. It is truly bizarre position to take just considering that many of these vulnerabilities have been publicly disclosed, so hackers would already have easy access to as much or more information than anyone has proposed including when warning webmasters of the issue. Then you have the fact that plenty of these vulnerabilities are not only known to hackers, but being actively exploited before the plugins were removed from the Plugin Directory (we know this because we have reported many of those to the Plugin Directory).
While that is really a black and white issue, when it comes to security many things are not like that. And in many cases actions do have serious unintended consequences that are not obvious. For example, we wouldn’t have though that the Plugin Directory doing a security review of a plugin after it has been removed for a security vulnerability could lead to putting the public at more risk, but that turned out to be the case as we recently found. [Read more]
While WordPress handles security fairly well, there are plenty of problems that we have seen in the work have done that ultimately lead to this service and then in doing the work for to this service, including ones that are leading to websites being hacked that shouldn’t be and that make our work to actually get the security of plugins improved unnecessarily harder. Some of these problems are getting worse, so we have decided to stop doing work that people on the WordPress side should have been doing themselves all along until they present concretes plans to fix two of the many issues. In the short term this will leave those not using our service with worse security, but if WordPress chooses to start moving in the right direction then security can be improved from where it is now. We would then love to work with them to improve other issues, as there are lots of areas were small changes would likely lead to significant improvement.
Poor Handling of Security
One of the most glaring recent examples of the poor handling of security is a refusal so far to fix a vulnerability in WordPress that was disclosed to the security team in July 2016 and publicly disclosed a month ago. The explanation for not having fixed it in all that time is underwhelming: [Read more]
Since 2012 we have been trying to get WordPress to start warning webmasters when their websites are using plugins that have been removed from the Plugin Directory due to security issues (and notify people in general that they are using plugins that have been removed from it). In the past WordPress’ position was that they were working on implementing this, but as of the last year the position has changed that they can’t do this because it would cause people to be “MORE at risk“. Not only does this not make sense, as we will come back to in a moment, but they don’t want to even honestly discuss the issue. For example, last July they even deleted a reply of ours on the Support forum pointing out that the handling of vulnerable plugins was not in as good shape as they were portraying it.
With that background it probably shouldn’t be surprising to see what happened to a recent thread on the wordpress.org Support Forum, which we previously mentioned, that was discussing the lack of notification when plugins are removed from the Plugin Directory. The head of the Plugin Directory decided to close that thread due to it being “non-productive”. It seemed plenty productive to us, as people were discussing better ways to handle things. The closing seems to us to be part of a continued lack of professionalism on part of people on the WordPress side, which really isn’t acceptable considering the widespread and high profile use of the software. Seeing as the person doing the closing is intimately involved in the issue being discussed, it doesn’t seem like they should be making the call to close the thread. [Read more]
Due to how bad the security industry is we rarely have the ability to point to a situation where the a security company has done the right thing, but today we have one to discuss.
Yesterday, we discussed how security companies rarely do one of the three basic components of a proper hack cleanup, which is to try to determine how the website was hacked. As we mentioned in that post, in instances where that isn’t done we are frequently brought in to re-clean the websites after they get hacked again. The problem of not determining how the websites are hacked doesn’t always just impact that website, if the vulnerability exploited exists in the current version of software on the website then spotting an early exploitation has the possibility of limiting the amount of additional websites that get hacked due to it. That possibility occurred with an arbitrary file upload vulnerability that exists in the WordPress plugin Delete All Comments. On November 20 the security company NinTechNet was looking into a hacked website and found the website was hacked due to that vulnerability. It wasn’t all that hard to spot with the combination of the logging and the code in the plugin, but since so many security companies don’t even try to determine how the websites they are cleaning up have been hacked, something like that can easily get missed. [Read more]
When it comes making sure that vulnerabilities in WordPress plugins get fixed we play important role in making that happen, but we are having to play an outsized role because others are not doing their part, which has once again lead to websites remaining vulnerable to being hacked for much longer than they should have been.
One of things that we do to provide the best data on vulnerabilities in WordPress plugins to our customers is that we monitor our websites and some outside data sources for evidence that hackers are targeting plugins. In many case the evidence doesn’t itself give any indication of what the vulnerability the hacker is targeting, just that the hacker is looking for usage of the plugin by requesting a .css or .js files in the plugin’s directory. From there we try to determine if the hackers is targeting a previously known vulnerability or there is a vulnerability that exists in the current version that hacker could be targeting. Through that work we have found numerous vulnerabilities included many that it looks like hackers have known and been exploiting for months and sometimes longer. What we found fairly troubling about this is that we look to be the only security company doing, even though at least one other would certainly like you to think they are. [Read more]
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. [Read more]
One of the key pieces of advice for keeping your WordPress website secure is to keep your plugins up to date, since that prevents the possibility of the website from being exploited through a security vulnerability that has been fixed in a newer version of the plugin. There is a limitation to that though, that it only protects you from vulnerabilities that the developer has fixed. So what happens if a vulnerability is discovered in a plugin available in the Plugin Directory and it doesn’t get fixed by the developer? Once the Plugin Directory is notified of the vulnerability the plugin is removed pending a fix, unless the vulnerability is really minor. That protects anyone who is not yet using the plugin, since they won’t be able to install it through normal means, but what about those who already have it installed? For them nothing happens. That is something that has concerned us for years.
As part of our effort to improve the situation, four years ago we put a suggestion up on the Ideas section of the wordpress.org website suggesting that webmasters should be alerted when they are using a plugin that has been removed from the Plugin Directory. Not to long after that idea was marked as “Good idea! We’re working on it”. [Read more]
Recently we have been finding that someone on the WordPress team has been deleting and editing some of our post on their support forum and because they don’t want others to know that, in one instance they even deleted someone else’s post that simply thanked us for one of our posts. While it has been rather troubling in general, one other instance that stuck out to us in the most recent purge, was a case where they removed a single sentence from a post, that sentence was “(including when the people running the Plugin Directory have failed to notice that)”, which was in reference to the fact that we often find that vulnerabilities that are claimed to have been fixed have not actually been fixed. The linked post, from the end of March, discussed the fact that plugins that had been removed from the Plugin Directory due to security issues were returning without the vulnerabilities actually being fixed.
While it would be close to impossible to insure that all of the plugins in the Plugin Directory are free of vulnerabilities, making sure that plugins that you are aware have had a vulnerability are not restored before they are actually fixed shouldn’t be, since it could be prevented by simply testing out to make sure the vulnerability has been fixed before restoring the plugin. [Read more]