Are Your Websites Up to Date?You can keep track of what versions of concrete5, Drupal, Joomla, Magento, MediaWiki, Moodle, PrestaShop, Revive Adserver, TYPO3, SPIP, WordPress, and Zen Cart are running on all of the websites you manage with our Up to Date? Chrome app.
Search This Blog
- 44.7 Percent of Plugins in the WordPress.org Plugin Directory Haven’t Been Updated in Over Two Years
- CloudAccess.net Stores Non-Hashed FTP/SFTP/SSH Passwords
- Does the Vulnerability Fixed in WordPress 4.2.1 Also Impact WordPress 3.7, 3.8, and 3.9?
- InMotion Hosting Prominently Promoting Installation of EOL’d Joomla Version
- Most Website Hackers Are Not Sophisticated
Web Software Updates
WordPress VersionWe are running WordPress 4.2.2 and despite what many supposed "security experts" claim letting you know what version we are running does not make us less secure.
Did We Make a Mistake?While it seems to be acceptable for blogs discussing web security to contain numerous factual mistakes, we hold ourselves to a higher standard. We only write about things that we actually understand and only after we have double checked the information. So if you see a mistake in one of our posts please leave a comment on the post or contact us so that we can add a correction.
Category Archives: WordPress
44.7 Percent of Plugins in the WordPress.org Plugin Directory Haven’t Been Updated in Over Two Years
Plugins play an important part in the success of WordPress, but they also introduce their own issues. Security issues obviously get a lot of attention, but there are other issues like the fact that not all plugins continue to be supported long term. One measure of how many plugins continue to be supported is to look at when plugins were last updated, as even plugins that have not needed any changes should have been updated periodically to indicate that they are compatible with new versions of WordPress. On the WordPress.org Plugin Directory, plugins that have not been updated in over two years have a banner at the top of the page that states “This plugin hasn’t been updated in over 2 years. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.”:
Last year, following a suggestion for our No Longer in Directory plugin, we added the functionality to list installed plugins that had not been updated in over two years in addition to its listing of plugins that have been removed from the Plugin Directory. We also put up a post looking at how many plugins that met that criteria at the time. Now, a little over year later we thought it would be a good time see again how many plugins haven’t been updated in over two years.
As of earlier today a total of 16,935 listed plugins had not been updated in over two years. That is 44.7 percent of all 37,905 of listed plugins. (Last year’s percentage isn’t equivalent since we included all plugins that entries in the Subversion Repository for the Plugin Directory, even if the plugin wasn’t currently or possibly ever in the Plugin Directory.)
Below we have charted what year these plugins were last updated. The number for 2013 is lower as plugins last updated after May 18 of 2013 would still be under two years out of date.
Warnings Missing in WordPress
While the WordPress.org Plugin Directory website displays a warning banner at the top of a plugin’s pages, inside WordPress a similar warning is not provided. Here is what is shown on the Add Plugins page in WordPress for the same plugin shown in the screenshot above:
Also if you have one of these plugins installed you don’t get shown any notice on the Installed Plugins page:
Last week a vulnerability in WordPress was disclosed and fixed in version 4.2.1. While WordPress only officials supports one version at a time, since the introduction of automatic updates in WordPress 3.7 they have been releasing security updates for all older releases that include the automatic updates feature. This time though only updates for 4.0 and 4.1 were released.
An update for 3.9 has a Codex entry, which indicates that the version, 3.9.6, was released to deal with this. But that version doesn’t appear to exist. Updates for 3.7 and 3.8 also had Codex entries, but those entries were deleted last Friday.
We were curious as to what was going on (as are others) since knowing the full implications of vulnerabilities that impact WordPress is important when we are cleaning up hacked WordPress websites. So we decided to do some testing to see if the vulnerabilities actually impacted versions 3.7-3.9 and they haven’t been fixed or if those versions are not vulnerable.
When using the sample exploit code provided for the vulnerability we found that vulnerability is not exploitable in versions 3.7-3.9 in the form given. The reason for this is that in WordPress 4.0-4.2 a character near the beginning of the malicious comment is encoded:
<a title=’x onmouseover=alert(unescape(/hello%20world/.source))
That allows the malicious code that begins “onmouseover” to be executed. In 3.7-3.9 that encoding doesn’t occur:
<a title='x onmouseover=alert(unescape(/hello%20world/.source))
So the “onmouseover” is treated as part of the title attribute instead of as code that should be executed, so no malicious code is run.
The underlying problem that leads to all of this, that WordPress didn’t properly check to make sure that comments longer then could be stored are properly handled also does exist in these versions, so it is possible somebody could figure out another way to exploit this in versions 3.7-3.9. If you are still running 3.7-3.9 we would recommend you upgrade to at least 4.0.4 as soon as possible. Though, it would be best that anyone still running a version below 4.2.1 to upgrade to that version.
While taking a look into a reported vulnerability in a WordPress plugin recently we noticed a rather glaring example of the use of fake reviews. First and foremost there were almost as many reviews as active installations of the plugin:
Unless the very few people using it really liked the plugin, the number of reviews is way out of line with other plugins (where there usually is one review per one hundred or more active installs).
The other big tip-off was that all the reviews occurred on one day (two days after the plugin was released):
One of those reviews was from someone who was supposed to have used it while running WordPress 1, which seems quite unlikely, to say the least.
The WPScan tool is “black box WordPress Security Scanner written in Ruby which attempts to find known security weaknesses within WordPress installations”, which is described as being intended “for security professionals or WordPress administrators to asses the security posture of their WordPress installations.” We find that claim somewhat odd since it scans a WordPress website from the outside of the website, which not only isn’t necessary if you have admin access to the website (which anyone involved with the security of website should have), but is also an inefficient way of doing a security scan when you have that access. While doing some research for another post we identified another problem that makes the tool bad for use by a security professional: their data indicates that plugin vulnerabilities have been fixed as of versions of the plugin that still in fact contain the vulnerabilities. Since this gets to a larger problem we have been seeing, we though it would make sense to take a look at this.
In WPScan’s vulnerability data for a a vulnerability in a plugin named Ajax Search Lite it says that the vulnerability impacted versions at or below 3.1 and that the vulnerability was “fixed in version 3.11″. The first claim is wrong and the second claim was wrong as of the date their data was last updated, March 21. We know this because we help to get the plugin fixed after that.
As part of the process of adding WordPress plugin vulnerabilities to our Plugin Vulnerabilities plugin, we check to make sure the claimed vulnerabilities actually exist (which they sometimes don’t) and we try to determine all of the version that are vulnerable. Knowing what versions are vulnerable is important when trying to determine how a WordPress website was hacked (as we do when cleaning up Hacked WordPress websites), as you can rule out a plugin’s vulnerability if the installed versions is not vulnerable. In adding data for over 225 vulnerabilities to our plugin so far, we have found that while some vulnerabilities have existed in every version of a plugin, many impact less versions, in some cases only one version has been impacted. What has been more surprising in working on the plugin is how often we find that even though a vulnerability has been listed as fixed, it hasn’t been. That was the case with Ajax Search Lite.
When we starting looking into the security advisory for Ajax Search Lite we figured that the vulnerability had probably been fixed in version 3.11 of the plugin based on the changelog entry for that version, “A possible security issue fix”, and the release date. After confirming that vulnerability existed in the prior version, 3.1, we checked to make sure it was fixed in 3.11, but it wasn’t. Looking at the changes between 3.1 and 3.11 we didn’t see anything that looked like the security fix. We then took a look at another plugin from the same developer Related Posts Lite that was reported to have the same issue. In that case the vulnerability had been fixed, so it looked to as if the developer simply forgot to include the fix in Ajax Search Lite. We notified the developer on March 26 of the issue; they then promptly responded and fixed the vulnerability. They still haven’t increased the version number so that anyone who got version 3.11 before that happened is still vulnerable. Because WPScan doesn’t do what we do, with their tool you wouldn’t know that you could still be running an insecure version.
What has made the issue of unfixed vulnerabilities even more surprising to us is that organizations that would think would be careful about this sort of thing, haven’t been. Take for instance another vulnerability we looked at recently. High-Tech Bridge, a security services provider, put out a security advisory for a vulnerability in the Easing Slider plugin. In it they stated that the vulnerability was “Fixed by Vendor” and indicated that the fix occurred in version 184.108.40.206. When we went to check on the vulnerability we found that it still existed in that version. In the changelog for that version it was listed that “Fixed some $_GET input validation security issues.”, which would appear to relate to the security issue identified, but they had not in fact done that to inputs that were the root of this vulnerability. It appears that High Tech Bridge didn’t actually test out their sample exploit in the new version, since it was obvious that it wasn’t fixed if you did that. We alerted the developer to the issue and the locations of the vulnerable code, which lead to the vulnerability actually being fixed in version 2.2.1. Once again if you are relying on WPScan you would be in trouble since they indicate the vulnerability impacted versions at or below 220.127.116.11 and that the vulnerability was “fixed in version 18.104.22.168″.
While this highlights the problem of relying on WPScan for security purposes, it also points to any area where the security of WordPress plugin could be improved. If WordPress provided a process where a plugin is reviewed after a security vulnerability is supposed to have been fixed then these types of issues could be quickly caught and fixed. As to who would provide the funding for this, we already have a good idea.
For years we have discussed the fact that in many cases with publicly disclosed security vulnerabilities in WordPress plugins, no one bothers to notify the developer or WordPress.org about them (that includes organizations selling WordPress security services like WordFence and WPScan). In many cases if this was done that would be enough to get them fixed. In other cases, when the vulnerability does not get fixed, the plugin will be pulled from the WordPress.org Plugin Directory and that will prevent more websites from adding the vulnerable plugins (alerting people that they are using plugins that have been removed from the directory is something we have been pushing for for years).
We have more than enough time taken up looking into to security issues in plugins, so we rarely look into security issues with themes, but we happened upon one last week that shows the lack of reporting extends to theme issues. Back on February 13 an authenticated arbitrary file upload vulnerability was disclosed in the current version of the Fusion theme, which was available on the WordPress.org Theme Directory. After confirming that the vulnerability existed we reported it to WordPress.org and then within an hour it was pulled from the directory.
What was troubling is that we don’t appear to have been the only people that had taken a look. Here is a screenshot of the graph of downloads from right before the theme was taken down from the Theme Directory:
We are pretty sure that spike in downloads shortly after the disclosure is related to people looking into the vulnerability and yet no one else looking at the issue bothered to report it. That includes the people at WPScan, who again included a vulnerability in their vulnerability database, but didn’t report it.
On March 8 an arbitrary file upload vulnerability, which would allow anyone to upload any kind of files to a website, was disclosed in the Reflex Gallery plugin. This type of vulnerability is probably the most serious vulnerability for a website since, unlike many types of vulnerabilities that rarely get exploited, it is question of when, not if, it will be exploited on websites. This is due to the fact that a hacker can use the vulnerability to upload a .php backdoor script, which will give them remote access to the website without having to interact with the software already running on the website. The only good news in this case it that the plugin is not very popular, the WordPress Plugin Directory lists as having 2,000+ active installs.
When we started to take a look at the vulnerability report to include it in our plugin that notifies of known security vulnerabilities in WordPress plugins we noticed that this plugin had previously had another arbitrary file upload vulnerability that existed in versions 1.0-3.0. The proof of concept for the previous vulnerability looked similar to the new one, both of them targeted the file /admin/scripts/FileUploader/php.php in the plugin. The main difference between them was that second included a couple of URLS parameters in the request, ?Year=2015&Month=03. Our first thought was that new vulnerability might somehow be related those URL parameters, though as we dug in we found what was really going on.
In version 3.0.1 the first vulnerability was fixed by changing the line
$allowedExtensions = array();
$allowedExtensions = array(“jpeg”, “gif”, “png”);
in the file /admin/scripts/FileUploader/php.php.
That restricted what file extensions could be uploaded, so that .php files could not be uploaded. While this provided basic protection, it was less than should have been done. Since the front-end of the plugin’s upload functionality is only accessible admin users the underlying upload function should have also been restricted to admin users. That way if there were some other vulnerability in it only admins would be able to exploit it, which really isn’t much of a problem. There are a couple of other potential issues that come from allowing anyone to upload files. First, you have the chance for denial of service (DOS) attack from someone filling up all of the websites disk space with uploaded files. Second, since only the file extension is limited, it is still possible to upload files with PHP code, which could be combined with a local file inclusion (LFI) vulnerability to exploit a website.
We then looked at what changes were made in the most recent version, 3.1.3, and that showed what happened with the second vulnerability. In the file /admin/scripts/FileUploader/php.php the line
$allowedExtensions = array(“jpeg”, “gif”, “png”);
was changed to
$allowedExtensions = array();
So for some reason the fix that was put in place before was removed, which re-opened the vulnerability. What makes this seems odder is that the changelog for 3.1.3 list only two changes made:
- Fixed issue of gallery info not updating on Edit Gallery page
- Additional security fixes
Last Monday, after looking into the vulnerability we attempted to notify the developer of the plugin about the disclosure of the vulnerability and the underlying cause. Were not sure if they got because when we submitted a message on their website’s contact form it didn’t provide any indication that message had been successfully sent. If we can’t reach a developer or they don’t respond our next step with a vulnerability that exist in a plugin that is available in the WordPress Plugin Directory is to report to the people running it. We originally planned to do that on Friday as that would have give the developer four days to deal with it first, but then on Thursday while reviewing our log files to see what WordPress plugin vulnerabilities there had been recent exploit attempts for we saw that there was attempt to exploit this vulnerability. It was done during a series of requests (shown below) that included trying to exploit some rather old vulnerabilities so it is likely that was not an attempt based on the recent disclosure, but the previous one.
22.214.171.124 – – [12/Mar/2015:02:07:37 -0400] “GET /blog/2010/11/19/oscommerce-2-3-includes-fixes-for-security-vulnerabilities-and-security-enhancements//xmlrpc.php HTTP/1.1″ 301 567 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
126.96.36.199 – – [12/Mar/2015:02:07:38 -0400] “GET /blog/2010/11/19/oscommerce-2-3-includes-fixes-for-security-vulnerabilities-and-security-enhancements/xmlrpc.php HTTP/1.1″ 404 6349 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
188.8.131.52 – – [12/Mar/2015:02:07:41 -0400] “GET //xmlrpc.php HTTP/1.1″ 200 439 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
184.108.40.206 – – [12/Mar/2015:02:07:42 -0400] “GET / HTTP/1.1″ 200 11041 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
220.127.116.11 – – [12/Mar/2015:02:07:52 -0400] “GET //wp-content/themes/vip/includes/uploadify/upload_settings_image.php HTTP/1.1″ 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
18.104.22.168 – – [12/Mar/2015:02:07:58 -0400] “GET / HTTP/1.1″ 200 11041 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
22.214.171.124 – – [12/Mar/2015:02:08:07 -0400] “GET /wp-content/themes//timthumb.php HTTP/1.1″ 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
126.96.36.199 – – [12/Mar/2015:02:08:10 -0400] “GET / HTTP/1.1″ 200 11041 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
188.8.131.52 – – [12/Mar/2015:02:08:19 -0400] “GET /wp-content/themes//thumb.php HTTP/1.1″ 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
184.108.40.206 – – [12/Mar/2015:02:08:23 -0400] “GET /wp-content/plugins/woopra/inc/php-ofc-library/ofc_upload_image.php?name=joss.php HTTP/1.1″ 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
220.127.116.11 – – [12/Mar/2015:02:08:25 -0400] “GET /wp-content/plugins/wp-seo-spy-google/ofc/php-ofc-library/ofc_upload_image.php?name=joss.php HTTP/1.1″ 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
18.104.22.168 – – [12/Mar/2015:02:08:27 -0400] “GET /wp-content/plugins/invit0r/lib/php-ofc-library/ofc_upload_image.php?name=joss.php HTTP/1.1″ 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
22.214.171.124 – – [12/Mar/2015:02:08:29 -0400] “GET /wp-content/plugins/chart/php-ofc-library/ofc_upload_image.php?name=joss.php HTTP/1.1″ 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
126.96.36.199 – – [12/Mar/2015:02:08:31 -0400] “GET /wp-content/plugins/wp-slimstat-ex/lib/ofc/php-ofc-library/ofc_upload_image.php?name=joss.php HTTP/1.1″ 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
188.8.131.52 – – [12/Mar/2015:02:08:33 -0400] “GET /wp-content/themes/cameleon/includes/fileuploader/upload_handler.php HTTP/1.1″ 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
184.108.40.206 – – [12/Mar/2015:02:08:36 -0400] “GET /wp-content/themes/switchblade/framework/_scripts/valums_uploader/php.php HTTP/1.1″ 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
220.127.116.11 – – [12/Mar/2015:02:08:41 -0400] “GET /wp-content/plugins/reflex-gallery/admin/scripts/FileUploader/php.php HTTP/1.1″ 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
18.104.22.168 – – [12/Mar/2015:02:08:45 -0400] “GET /wp-content/themes/elemin/themify/themify-ajax.php HTTP/1.1″ 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
22.214.171.124 – – [12/Mar/2015:02:08:49 -0400] “GET /wp-content/plugins/front-file-manager/upload.php HTTP/1.1″ 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
126.96.36.199 – – [12/Mar/2015:02:08:52 -0400] “GET /wp-content/plugins/complete-gallery-manager/frames/upload-images.php HTTP/1.1″ 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
188.8.131.52 – – [12/Mar/2015:02:08:56 -0400] “GET /wp-content/plugins/is-human/engine.php?action=log-reset&type=ih_options();eval(base64_decode(JHM9cGhwX3VuYW1lKCk7CmVjaG8gJzxicj4nLiRzOwoKZWNobyAnPGJyPic7CnBhc3N0aHJ1KGlkKTsK));error HTTP/1.1″ 404 5838 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6″
184.108.40.206 – – [12/Mar/2015:02:09:00 -0400] “POST /wp-content/plugins/radykal-fancy-gallery/admin/image-upload.php HTTP/1.1″ 404 5864 “-” “libwww-perl/6.08″
220.127.116.11 – – [12/Mar/2015:02:09:02 -0400] “POST /wp-content/plugins/mm-forms-community/includes/doajaxfileupload.php HTTP/1.1″ 404 5864 “-” “libwww-perl/6.08″
18.104.22.168 – – [12/Mar/2015:02:09:05 -0400] “POST /wp-content/plugins/html5avmanager/lib/uploadify/custom.php HTTP/1.1″ 404 5864 “-” “libwww-perl/6.08″
At that point we immediately sent an email to the people running the Plugin Directory alerting to the vulnerability and the fact that it was currently being exploited (along with details on three other vulnerabilities). In most cases in the past when we having reported vulnerabilities to them in this way they have quickly responding by taken the plugin down until a fix was released, so that no additional websites would made vulnerable. Unfortunately, as of posting this on Monday morning the plugin has not been updated or pulled from the plugin directory.
Improving The Handling of Plugin Vulnerabilities
This situation highlights a couple of serious problem that come with the current handling vulnerabilities in WordPress plugins, but also points to where improvements can be made.
Making it Easier to Report Vulnerabilities
The current methods for reporting security vulnerabilities are lacking. You can try to contact the developer through their website, but isn’t also easy to find an email address or contact to do that. Some plugins have email addresses they specifically suggest you use to contact them about security issues, but they also can be hard to locate on their websites. You can try contacting the developer through the plugin’s support forum in the Plugin Directory, but not every developer monitors that closely and it is public so that can limit ability to safely disclose information. From what we have seen it appears that many people that are discovering vulnerabilities don’t know that the can also contact the Plugin Directory about the issue, which isn’t too surprising since it isn’t prominent displayed.
One possible solution for this would be to provide a mechanism on the plugin’s page on the Plugin Directory for security vulnerabilities to be reported, which would then send it along to the developer and the people running the Plugin Directory.
Checking on Fixes
What we see fairly often is that when developers attempt to fix publicly disclosed vulnerabilities they either only partially fix it or don’t fix it at all. In other cases the disclosed vulnerability is only part of a wider security issue. Putting a place a process where a review by someone with a better understanding of security is done after the developer thinks they have fixed the vulnerability could go a long way to improving the security of plugins. We already have a good idea of who could provide the financial supports this (in the meantime our checks during the process of adding the vulnerability to our Plugin Vulnerabilities plugin have lead to a number of these situation getting resolved).
In this case if the file uploading had been restricted to admins, then even with the undoing of the file extension restriction the security vulnerability would not have opened back up.
Auttomattic Sponsored WordPress Plugin Pods Still Hasn’t Fixed Publicly Known Security Vulnerability After Two Months
In discussing how the security of WordPress plugins could be improved we have put forward that Automattic, the company closely connected with WordPress, should have some responsibility for that. With a valuation of over billion dollars they certainly have the financial wherewithal to bear the burden of some responsibility. Shortly after putting forward that idea that we came across a security advisory for multiple vulnerabilities in Pods, a plugin that Automattic sponsors.
When we checked on the vulnerabilities to add them to Plugin Vulnerabilities plugin we found that despite the advisory saying that they were fixed in version 2.5, that in fact two reflective cross-site scripting (XSS) vulnerabilities listed still existed. Three days after the advisory was put out, January 15, we notified the Pods developers that vulnerabilities still existed. We promptly received a reply from them, but it didn’t seem like they really understood the situation.
A week later versions 2.5.1 and 22.214.171.124 were released, neither of which addressed the security vulnerabilities.
On February 5 and 9 we received emails from the developers that the vulnerabilities would be fixed in version 2.5.2. That version has yet to be released and it has now been two months that they have knowingly left the vulnerabilities in the plugin. Maybe this will be a wake-up call to Automattic that plugin security needs to be taken more seriously and that they can start playing a constructive role by improving the security of plugins they sponsor.
It has now been a little over three months since we introduced our Plugin Vulnerabilities plugin amid our renewed effort to improve the security of WordPress plugin and it seems like a good time to provide on what we have accomplished so far. For years we have discussing the problem that many publicly disclosed vulnerabilities existed in the current version of WordPress plugins and that those plugins were still available on the WordPress.org Plugin Directory. That obviously is bad sign for the overall security of WordPress plugins since making sure that known vulnerabilities get fixed is a low rung of making sure that plugins are secure. In the past we hadn’t kept track of how many of these vulnerabilities we had some part in getting fixed, but when we started working on the new plugin we started tracking that. This week two more of the plugins got fixes bringing the total to 16 vulnerabilities fixed in as many plugins. Developers of two more plugins have indicated that vulnerabilities in their plugin will be fixed in upcoming releases.
One of the vulnerabilities fixed this week gives an indication of how poor the situation still is years after we first noticed it. Back on September 1 a vulnerability was publicly disclosed in the Easy Media Gallery plugin, which has 10,000+ active installs. The person disclosing the vulnerability decided not to inform the developers beforehand and it would appear no one else bothered to either considering that a fix was released within two day of us informing them on Monday. It wasn’t a case that no one else saw the post as there are several comments and two follow up posts have comments from people complaining the discoverer is not informing developers of the vulnerabilities.
The first comment on that post ties into another troubling issue that we have seen in the vulnerabilities fixed. The commentor mentions that they would inform the developers of WPScan, which they describe as a ” black box WordPress vulnerability scanner”, of the vulnerabilities. The commentor did in fact do that. It would appear that WPScan folks didn’t inform the developer of the vulnerability either. That certainly wouldn’t be the first time, as previously discussed in another situation they disclosed a serious vulnerability in a plugin but didn’t bother to inform the developer, which meant that like this vulnerability, it wasn’t fixed. We also found that they put vulnerabilities in their database, but don’t inform the developers of them, so that people with malicious intent are aware of vulnerabilities but everyone else is left vulnerable.
While just informing the developers of the vulnerabilities can in many cases get the vulnerability fixed quickly we have found that in other cases that isn’t enough. For example, in the case of the Xcloner plugin it required the Plugin Directory having removed the plugin, after we reported it to them, for the developer to finally fix the vulnerability. In other cases we have found that despite discoverer of the vulnerability and the developer of the plugin saying the vulnerability had been fixed, it actually wasn’t. But our checking, done while determining what versions are vulnerable when adding the vulnerability to the Plugin Vulnerabilities plugin, have led to the vulnerabilities actually getting fixed.
If you run across a report of a vulnerability in the current version of a WordPress plugin please make sure to inform the developer of the plugin and or the people running the Plugin Directory. You can also let us know by leaving a message in the support forum for Plugin Vulnerabilities or sending an email to email@example.com, which will allow us to add the vulnerability to our plugin and make sure that the vulnerability is handled properly.
In a previous post we looked at the fact that MOJO Marketplace distributes outdated software with known security vulnerabilities. Their lack of concern for security doesn’t end there; they have not kept their WordPress installation up to date:
If they actually used their own service they could be up to date, because unlike other software they offer they actually provide the latest version of WordPress:
Not only have they not updated to the latest major release of WordPress, 4.1, they haven’t applied the “critical security release” for 4.0 that was released on November 20. That would have normally have happened automatically, so either they disabled automatic updates, which is bad idea if you are not going to be on top of updating WordPress, or they have some problem blocking that from happening. If there was a problem and they actually cared about WordPress security getting to the bottom problem would have been the right thing to do as it could possible help others as well. Their lack of concern for the security of WordPress on their own website hasn’t stopped them from feeling it is appropriate for them to sell a WordPress security service to others though.
If you are looking to improve the security of your WordPress website you should check out our free Plugin Vulnerabilities plugin, which warns if you are using WordPress plugins with known security vulnerabilities.
As of today’s release, our Plugin Vulnerabilities plugin includes entries for 200 security vulnerabilities that have existed in WordPress plugins. While that is far from all of the vulnerabilities out there, it does include a good mix of vulnerabilities. So far we have focused on adding newly discovered vulnerabilities, vulnerabilities that we are seeing exploit attempts for, and vulnerabilities from the archives of security researchers. We have included some stats we collected on those vulnerabilities below.
One stat stands out, over a quarter of the vulnerabilities – 54 of 200 – have not been fixed. A few of these were only recently discovered or the developer was only recently informed of them (all too often no one bothers to inform the developer and this is something that our work on the plugin has been rectifying), but for the vast majority there has been ample time and notice to the developer so they should have been fixed by now. This is a big problem because simply keeping plugins up to date won’t protect you if the latest version of the plugin has a known security vulnerability that can be exploited.
Right now what happens when a vulnerability isn’t fixed is that the plugin will be removed from the WordPress.org Plugin Directory until it is fixed, assuming the people running the Plugin Directory are informed of the issue. That does nothing for any websites that already have the plugin installed though. It is a problem we have been highlighting for three years now, without getting a solution. It also has been over two years since there was indication that a solution was being worked on. We hope that it won’t take another year to finally get fixed. In the meantime you can use our Plugin Vulnerabilities plugin to get alerted to known vulnerabilities in installed plugins and our No Longer in Directory plugin to find out what installed plugins have been removed from the WordPress.org Plugin Directory.
Plugin Vulnerability Stats As of March 2, 2015
- 200 vulnerabilities included
- 54 included vulnerabilities are in the most recent version of plugins (49 of these plugins have been removed from the Plugin Directory)
- 14 vulnerabilities have been fixed in part due to our work on this plugin
- 5 included vulnerabilities in security plugins
- Top vulnerability types:
- cross-site request forgery (CSRF)/cross-site scripting (XSS): 49 vulnerabilities
- reflected cross-site scripting (XSS): 39 vulnerabilities
- unrestricted file upload: 31 vulnerabilities
- arbitrary file viewing: 16 vulnerabilities
- SQL injection: 15 vulnerabilities
- Top vulnerability discoverers: