04 Nov

You Now Decide What Plugins We Will Be Doing Security Reviews Of

As part of the work we have been doing for the service we have been steadily increasing our ability to spot security vulnerabilities and lesser security issues in plugins. That is due to a variety of different activity that we do, from our reviewing reports of vulnerabilities discovered by others, when adding them to our data, to finding vulnerabilities that hackers would target in plugin that we see hackers are probing for usage of. In the past we have used some of the knowledge we have gained through that to check for specific issues vulnerabilities in wider sets of plugins and found a number of vulnerabilities. That knowledge could also be used to more thoroughly review a single plugin and check it for a number of security issues, which is something we have decided to start doing.

In doing that though the question is what plugins should we review and what we came up with was allowing our customers to decide that. This provides additional value to service, beyond letting you know what vulnerabilities exist and previously existed in the plugins you use (as well as helping you to best handle it if a vulnerability in the plugin you use hasn’t been fixed). To accomplish that we have set up a new page where customers can suggest plugins to be reviewed and they can vote in favor of plugins already suggested by others.

The process is pretty simple, log in to your account and then visit the voting page. From there you can submit any plugin currently in the Plugin Directory:

plugin-vulnerabilities-submit-wordpress-plugin-for-security-review

For plugins that others have already submitted you get a brief listing of their details and if you want that plugin reviewed, you can add your vote for that to happen:

plugin-vulnerabilities-vote-for-wordpress-plugin-for-security-review

(If you are wondering what we use to power that, it is the Idea Factory plugin, with a significant amount of fixes (due to support for being lacking at this time) and customizations.)

We are currently planning to do a review of a plugin with the highest vote count every two weeks (based on the time commitment and interest we may increase the number of reviews going forward).

What is Included in the Review?

We are referring to the reviews that we do as basic reviews, as it isn’t a line by line review of the plugin and we are not guaranteeing that the plugin is completely secure after the review. But that doesn’t mean that the review can’t find big issues. One of the items we are going to be looking for is security issues with file upload capabilities, which in some cases can lead to arbitrary file upload vulnerability. That type of vulnerability allows an attacker to upload any type of file to a website, which is frequently exploited by hackers to upload .php files that gives the hacker nearly complete access to the website.

Even in cases we don’t find major security issues, security improvements that we identify, if implemented by the developer could prevent a future security vulnerability. To give you one example of where this could have made a big difference, earlier this week a vulnerability was discovered being exploited in a plugin (the plugin is in the process of being fixed so we won’t mention its name here). In addition to a more obscure security issue that lead to this, it was situation where a recently added function that should have only accessible to Administrator level users was accessible to anyone logged in or logged out, and allowed a hacker to gain full access to the website. While that function was recently added, numerous other function had the same problem, with one of the others allowing any file on the website to be deleted. Once we notified the developer of that larger issue they quickly restricted access. As our basic review would have identified the lack of proper restrictions, it could have prevented the more serious vulnerability from being exploited by anyone other than an Administrator level user (who would normally already have the ability to do the equivalent of what the vulnerability permitted).

Here is the full list of items we are checking for at this time:

  • Insecure file upload handling (this is the cause of the most exploited type of vulnerability, arbitrary file upload)
  • Security issues with functions accessible through WordPress’ AJAX functionality (those are a common source of disclosed vulnerabilities these days)
  • Persistent cross-site scripting (XSS) vulnerabilities in publicly accessible portions of the plugin
  • Cross-site request forgery (CSRF) vulnerabilities in the admin portion of plugins
  • SQL injection vulnerabilities (the code that handles requests to the database)
  • Reflected cross-site scripting (XSS) vulnerabilities
  • Lack of protection against unintended direct access of PHP files

We also have some additional items that we will be taken a look to see if it would make sense to check during the reviews.

If you have question or comments about this new feature feel to get touch with us or leave a comment on this post.

19 Sep

We Now Let You Know How Likely It Is That a WordPress Plugin Vulnerability Will Be Exploited

Recently we have been looking at ways that we can improve the data we provide on WordPress plugin vulnerabilities through our service. Three weeks ago we started including data on false reports of vulnerabilities in the plugins you have installed. Today we have added a rating of the likelihood that a vulnerability will be exploited to the service’s data we present in the plugin and in the email alerts you receive if you the currently installed version of one of your plugins has a vulnerability. Once you have updated the service’s companion plugin to the newly released 2.0.22 you will start getting that.

Before we get into the details of that, we thought it would be useful to explain why we thought this would be a good addition the service. Something we often see is that really minor vulnerabilities, ones that have almost no chance of someone trying to exploit on a website, are instead presented by security companies and the press as being major concerns. The press often makes a big deal of minor vulnerabilities in very popular plugins, that never get exploited, while not covering vulnerabilities in lesser used plugins that leads to thousands of website being hacked. We also sometimes see people immediately removing a plugin with a minor vulnerability, when they could have safely waited for a fix to be put out.

One possible way to better present the actual threat of a vulnerability would be to use a severity score. Those seem to be popular, particularly the CVSS scorring system, but we found that the scores for WordPress for plugins are much to high with that, leading again to overemphasis on vulnerabilities that are not a large threat. That scoring system is also rather complicated, with multiple scores and multiple version of the scoring system.

So we have come with a simpler rating system for the likelihood of a vulnerability being exploited. We give each vulnerability a rating of low, medium, or high based on our estimation of the likelihood of the exploitation. Most vulnerabilities fall into either low or high, with medium being for vulnerabilities for vulnerabilities that would be exploited in more limited circumstances. Take for example this vulnerability that would allow anyone logged into WordPress to upload malicious files. For a lot of websites that only have one WordPress account or only have accounts for few trusted users it really isn’t much concern, but if you allow the public to register for account it could be a threat (hackers did try to target it).

How We Make Our Estimates

To come up with an accurate rating, which is important for them to be useful, we look to three items.

The first is the type of vulnerability. This is by the far the biggest factor as many types of vulnerabilities are either highly likely or unlikely to be exploited.

The second is the specifics of the vulnerability, which can sometimes make a big difference. For example a persistent cross-site scripting vulnerability that causes malicious JavaScript code on the frontend pages of the website is more likely to be exploited than one that places it on a single admin page.

Finally, since we are constantly monitoring what vulnerabilities hackers are targeting, we can see if a vulnerability is getting targeted out out line with what the two other criteria would suggest and change the rating to match that.

All of this depends on us having good understand of those things, so that is where we can provide unique value because we review vulnerabilities, we monitor hacking attempts, and clean up hacked WordPress website. In addition we are continue to look at ways to get a better understanding of what is going on, by doing things like seeing to what extent WordPress security plugins can protect against exploitation of vulnerabilities and seeing what influences the vulnerability that hackers choose to target.

Rating Data Still Being Added

We started including the estimate when adding new vulnerabilities a few weeks ago. In the last week we have adding ratings to a lot of the existing vulnerabilities, but it still we be some time before we include ratings for all of the vulnerabilities that have existed in the data set for some time.

 

If you have ideas for further improvements to the data we present in the plugin or any similar suggestions please get in touch with us.

29 Aug

False Reports of Vulnerabilities In Installed Plugins Are Now Listed As Well

When adding a new WordPress plugin vulnerability to the data set for our service we test out the vulnerability. That allows us to do several important things for our customers, which you won’t get with other data providers, who don’t do that.

First, we can warn you when the vulnerability hasn’t actually been fixed, despite a claim to the contrary in the advisory. Once the vulnerability has been disclosed the chances of it being exploited increases, so knowing that you are still vulnerable is important in that instance. If you are using a service that doesn’t do this, you would need to check out each vulnerability yourself to insure it has actually been fixed.

Second, we can determine which versions are vulnerable. The biggest use for that is in dealing with hacked websites, since you will actually know if the version that has been in use was vulnerable and could have been the source of the hack. Other data sources will just list that all version below a certain versions are vulnerable, despite it often being far fewer than that. For example, one widely exploited vulnerability earlier this year existed in only in one version of the plugin. Doing that also allows us to only send you a notification if you are actually using a version that is vulnerable.

Third, we are able to exclude false reports of vulnerabilities from out data. Warning you about a vulnerability that doesn’t exist obviously isn’t helpful.

While it doesn’t make sense to warn you about vulnerabilities that don’t exist as if they exist, knowing that false reports of vulnerabilities exist can be useful. One of the odd things we have noticed in monitoring hacking attempts on our websites is that hackers will sometimes try to exploit vulnerabilities that don’t exist. So if you can see that there is false report that matches hacking attempts on your website, then can stop worrying about that.

When we come across false reports of vulnerabilities in plugin we usually write up a post about the issue, that way we can let others know that it isn’t real and it also allows us to double check that we are correct in determining that the report is false. Up until now if you used our service you would have to search our website to see if there were any false reports for the vulnerabilities you use, which isn’t all that convenient. That changed today with the release of version 2.0.21 of companion plugin for the service, which now lists any false reports of vulnerabilities we have posted about in installed plugins in section below the existing sections for vulnerabilities that have and have existed in the plugins you have installed.

false-wordpress-plugin-vulnerability-listing

If you have ideas for further improvements to the data we present in the plugin or any similar suggestions please get in touch with us.

11 Mar

Get Alerted When WordPress Plugin Developers Are Not Taking Security Seriously

With our service you get alerted if any of the WordPress plugins you have installed have a vulnerability in the installed version. You can also see what vulnerabilities they have had in other versions, which is something you might use to determine if you should continue you using it. The problem with trying to do that is that isn’t always easy. If you are not dealing with this type of thing on a regular basis there is good chance you wouldn’t have the knowledge as to what security issues are of little concern and what ones are a major concern going forward. You also would have dig in to see if the developer has a pattern of not responding in a timely fashion when a vulnerability is discovered, which can have a significant impact on whether the vulnerability will get exploited. Since we already come in contact with that type of information, we thought it would be useful to start using the knowledge we are collecting to make it easier to find out if security practices of plugin developers are lacking by putting out advisories for developers that have serious issues.

The idea for this also came up because unfortunately we are seeing developers who are doing a really bad job at making sure their plugins are secure. The first advisories we released involves a company that has not been taking basic security measures, had a really serious vulnerability in one their plugins,  doesn’t respond in a timely manner when contacted about security issues, and takes weeks to fix them. The subject of the second one has repeatedly only fixed part of the security issues reported to them.

You can view all of our advisories here and follow the RSS feed of them here. Having to check our website to see if a plugin developer is the subject of a security advisory obviously isn’t very convenient, so that is why we have rolled out a couple of updates to our software to allow those notices to be seamlessly shown when you are looking at new plugins:

Advisories in WordPress

Today we released a new version of the Plugin Vulnerabilities plugin that adds a warning message with a link to these advisories to the details page of plugins in the Add New plugins section of WordPress:

developer-advisories-in-wordpress

For already install plugins you can click the “View details” link on the Installed Plugins page to see if there is an advisory as well.

This feature is built in to the plugin, so it works even if you haven’t signed up for our service (though you really should do that).

Advisories on WordPress.org

But what about if you are taking a look at plugins on the Plugin Directory on WordPress.org? If you are doing that in the Chrome web browser you are in luck. We also have released an update to our Plugin Vulnerabilities extension that adds the advisories to the website:

developer-advisories-on-wordpress-website

The extension also adds notices to the URL of plugins that have been removed from the Plugin Directory due to security issues:

plugin-removed-with-vulnerability-warning

If we see increased interest in the extension we plan to release versions for other web browser, so if you want it for ones of those, please let us know which one in the comments so that we can properly prioritize the order of which browsers to bring it to in the future.