We Have Now Helped Get 16 WordPress Plugin Vulnerabilities Fixed

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 pluginvulnerabilities@whitefirdesign.com, which will allow us to add the vulnerability to our plugin and make sure that the vulnerability is handled properly.

Posted in WordPress Plugins | 1 Comment

MOJO Marketplace Sells WordPress Security Service While Using Insecure WordPress Version

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:

The MOJO Marketplace blog is running WordPress 4.0


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:

MOJO Marketplace is providing WordPress 4.1.1

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.

Posted in Bad Security, WordPress | Tagged | Leave a comment

MOJO Marketplace Distributing Software With Known Security Vulnerabilities

Last week we noted that web hosts should stop providing the SimpleScripts software installation service to their users since it hasn’t been supported for some time, leaving people with outdated and insecure software on their websites. As part of that we noted that it looks like their service was replaced with the MOJO Marketplace. We decided to take a quick look at that service to see if they were keeping the software provided though it up to date and the results show that they have some problems, though nowhere near as bad as we found with GoDaddy last November.

To start with, they are still offering Joomla 2.5, despite support for that version having ended in December:

MOJO Marketplace is providing Joomla 2.5.28

Somewhat oddly they provide the latest version of Drupal 7, but they don’t provide the latest version Drupal 6, despite those being released together in November. That version of Drupal 6, 6.34, fixed a session hijacking vulnerability.

MOJO Marketplace is providing Drupal 6.33

For MediaWiki they have missed the last two updates to MediaWiki 1.23, both of which included multiple security updates. Version 1.23.7 was released in November and 1.23.8 was released in December.

MOJO Marketplace is providing MediaWiki 1.23.6

For Zen Cart they have missed version 1.5.3, which includes security improvements and was released last July, and 1.5.4, which was released at the end of last year.

MOJO Marketplace is providing Zen Cart 1.5.1

For concrete5 they have missed the last two updates to MediaWiki 5.6, both of which included multiple security updates. Version was released in September and was released in February.

MOJO Marketplace is providing concrete

Posted in Bad Security, Outdated Web Software | Tagged | Leave a comment

Many WordPress Plugin Vulnerabilities Have Not Been Fixed

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:
Posted in WordPress Plugins | Leave a comment

WordPress.org Makes It Harder For Security Journalists to Hype WordPress Plugin Vulnerabilities

Last Wednesday we discussed an ongoing issues where security journalist conflate WordPress plugin’s download count at WordPress.org with how many websites are using the plugin, making a vulnerability seem like it has much larger impact than it actual it does. In the case last week the headlines proclaimed things like “More than 1 million WordPress websites imperiled by critical plugin bug” about a security vulnerability that existed in older versions of WP Slimstat, beyond explaining the fact that the security vulnerability in question was unlikely to be widely exploited, we pointed out that the website count used was way off base. The journalist were taking the 1.3 million downloads the plugin had and using that to back up their claim on over 1 million websites impacted, which they shouldn’t have since it isn’t close to being appropriate substitute for an actual count of use.

Over the weekend WordPress.org made a change that should stop this, as they started displaying a count of Active Installs in addition to download counts for WordPress plugins. In the case of the WP Slimstat plugin the actual number of websites using it is much less than a million, with the Active Installs listed at 100,000+:


Hopefully this will be a wake-up call to some of those journalist that they need to stop taking so many liberties when reporting on WordPress plugin security issues, since this isn’t the only problem that there has been with their coverage of the issue (which could use more quality coverage).

Posted in Bad Security, WordPress Plugins | Leave a comment

Note to Web Hosts: SimpleScripts is No Longer Being Updated

When it comes to what needs to be done to improve the security of websites there are so many things that could and should be done, but certain of them stand out for various reasons. One of the issues that stands out for us is web hosts who are distributing outdated web software. Web hosts are quick to blame many hacks on outdated web software – usually without evidence to support the claim – so you would think they would be careful about making sure that when they distribute web software through one-click installers and other similar mechanism that they are keeping the version available up to date. Too often that isn’t the case, back in November we looked at GoDaddy’s distribution of quite old versions of various software. The other day we ran across another example worth highlighting involving the one-click installer SimpleScripts.

While doing a cleanup of a hacked WordPress website we logged into the web host’s control panel for the website and got a pop up that the WordPress installation needed to be updated. Following the link in that brought up the SimpleScripts upgrade page and on that there was obvious problem, it listed the current version of WordPress as 3.9:

SimpleScripts Web Page Screenshot

Version 3.9 hasn’t been the current version since 3.9.1 was released on May 8, 2014. A quick look at the list of the software versions provided by SimpleScripts showed that WordPress wasn’t alone in having a very out of date version provided. As best we can tell SimpleScripts is not being supported anymore. The SimpleScripts website makes no mention of it, but it appears that the service might have been replaced with another one-click installer MOJO Marketplace.

If you use a web host that is still using SimpleScripts please let know that it is no longer being updated and should be replaced.

Posted in Bad Security, Outdated Web Software | Leave a comment

One Easy Step To Hype A WordPress Plugin’s Security Vulnerabilty

We would love to see more quality press attention to the issue of WordPress plugin security because there certainly is much discuss, unfortunately, as with security journalism in general, when it does get discussed these days the reporting is mostly awful. Take for instance the Ars Technica article More than 1 million WordPress websites imperiled by critical plugin bug (written by the same person who last year wrote an article that we found to be completely baseless).

The words imperiled and critical are probably not appropriate, considering that the vulnerability in WP Slimstat was fixed in an update last week (you can turn of WordPress ability to automatically updates plugins with one of our plugins) and due to the type of vulnerability. The vulnerability is a blind SQL injection vulnerability, which can allow data to be read out of the database. While this has the potential to be rather serious if you store sensitive data on the website, this type of vulnerability isn’t often exploited by hackers that are not targeting specific websites (most hacks are not targeted). So the chances of it being exploited are rather small in comparison to say a vulnerability that allows PHP files to be uploaded to a website, which we can almost guarantee is going to be exploited, most likely sooner rather than later. The chances of this plugins vulnerability being exploited are even slimmer because it requires a fair amount computing being done before you can exploit it, unlike plenty of other blind SQL injections that have been found in WordPress plugins.

The big problem with the article comes from the claim in the title that “more than 1 million WordPress websites imperiled”. Over a million websites impacted make this sounds like a major issue, the problem is that it isn’t close to being true. If you read through the article nothing is provided that backs that number up, instead only the download count of the plugin is mentioned:

WP-Slimstat is an analytics tool. Its listing on WordPress shows it has been downloaded more than 1.3 million times. People who operate websites that use the plugin should update immediately.

Downloads of software obviously are not the same as how many websites are using software, so treating them the same is something a journalist concerned about accuracy wouldn’t be doing. But what makes it so bad for WordPress plugins is that each time a plugin gets updated through the WordPress admin area that counts as new download, so the actual user count is going to be much smaller than the download count, especially if the plugin is updated frequently. The download graph for one of our plugins dramatically shows how updates impact the download count:


You see that huge spike that on the graph, that is when we updated the plugin. On that day there were 148 downloads and the next day there 47 the next day. That compares to 9 downloads a day we averaged over the last week. Those two days work out to 13 percent of total downloads so far.

WP Slimstat is updated more often so there are lots of spikes on the graph, of which, most if not all are due to updates:


Ars Technica isn’t alone in this, a quick search pulled up more articles on this vulnerability with the same highly inflated website use count:

It also worth mentioning that this type of article has the potential to be somewhat harmful to security since you need to being keeping your WordPress plugins update to date all the time instead of trying to be on the lookout for mentions of fixed security issues since security fixes often are not even mentioned in plugins’ changelogs.

Posted in Bad Security, WordPress Plugins | Leave a comment

WordFence Really Doesn’t Know What They Are Talking About

One of the biggest problems we see with improving the security of websites is the amount of bad information out there, as it is hard to start to address the underlying problems when so much of what is being said is wrong. What surprised us when we started dealing with security issues is how much of that bad information comes from security companies. We don’t have the time to go through every instance of this since it is so widespread, but it is worth looking at an example of a company putting out bad information from time to time when a larger security issue is also raised.

On February 11, security researcher Claudio Viviani publicly disclosed a SQL injection vulnerability in the WordPress plugin WORDPRESS VIDEO GALLERY. According to his advisory he had notified the developer of the plugin about the issue two days before that. The next Tuesday we added the vulnerability to our Plugin Vulnerabilities plugin and on Friday, after waiting a few days to give time to the developer to release the fix, we notified the people running the WordPress.org Plugin Directory of that the vulnerability existed and had not been fixed. Following that the plugin was pulled from the directory. Earlier today they let us know the plugin had been removed and that the fixed version should be available soon. While checking to confirm that issue was fixed in the new version, which it was, we came across a forum thread that linked to a WordFence, which sells a WordPress security service, blog post entitled Zero Day SQL Injection Vulnerability in WordPress Video Gallery.

The problems with their blog post start with the title. This vulnerability wasn’t a zero day vulnerability since that involves a vulnerability being exploited before the developer or the public knows about the vulnerability. That wasn’t the case here as the vulnerability was publicly disclosed a week before and it appears the developer knew about it before that. The implications of a zero day vulnerability are much different than what this actually is, so the distinction is important. Zero day vulnerabilities do get more press coverage, so you might ask if they characterized it that way to try to get them attention.

That wasn’t the end of the problems, it continues into the content of the post:

There is currently a zero day SQL injection vulnerability in the WordPress Video Gallery plugin. Our researchers are seeing exploits in the wild for this and the exploits claim the vendor has been notified on the 9th of February.

If you click the “exploits in the wild” link what you get is not anything to do with exploits of the vulnerability in the wild, instead it is a copy of Claudio Viviani’s advisory on the Exploit Database website. The advisory itself doesn’t provide any code to exploit vulnerability. The proof of concept (POC) given simply shows where the SQL injection code would go:


It doesn’t include any malicious SQL code and providing the POC doesn’t really make much difference in exploiting the vulnerability since with the details of the vulnerability someone should be able to recreated the provided POC quite easily.

You really have to wonder about the competency of the WordFence researchers when they are claiming that a security advisory is somehow evidence of “exploits in the wild”.

Also in that section they half acknowledge the developer was notified of the vulnerability ahead of the exploitation, which would mean that this isn’t a zero day vulnerability as they are claiming.

The plugin still has not been updated by the vendor. Because this is being exploited actively and the vendor has been notified, we are now publicly disclosing the existence of this vulnerability.

WordFence isn’t actually publicly disclosing anything since the person that discovered the vulnerability already did that, it isn’t clear if they don’t know what public disclosure actually is or if they are intentionally trying to take credit for something they didn’t do.

A ‘googledork’ is also available in the exploit which allows attackers to use Google to find sites which suffer from this vulnerability in order to exploit them.

While this might sound ominous it doesn’t really mean much, the “googledork” in this case is simply a search query that shows URLs in Google’s index that are from RSS feature of this plugin. Here it is from the advisory:

# Dork Google: inurl:/wp-admin/admin-ajax.php?action=rss

Again this doesn’t actually matter much since all the search query does is show indexed URLs that contain the start of the path that is exploited:


Protecting Against Unfixed Vulnerabilities in WordPress Plugins

The situation with this plugin does get to a real problem, how do we protect against websites being hacked when known vulnerabilities in WordPress plugins are not fixed. WordFence’s solution beyond reporting the issue to the Plugin Directory, seems to be more effective at promoting their website then dealing with this type of situation:

Please share/tweet/mail this to your fellow WordPress administrators to help create awareness about this serious issue.

We have been pushing for a better approach to handling than this type of situation for years, which would involve WordPress warning admins when an installed plugin has been removed from the Plugin Directory (if you would like to see that happen please vote for it on the WordPress Ideas website). Until that happens you can use our No Longer in Directory plugin that provides a more limited version of that functionality. For this type of situation though one of our other plugins, Plugin Vulnerabilities, is more useful. This plugin warns when installed plugins have known security issue and also provides information on vulnerabilities that existed in other versions, which is useful when cleaning up a hacked WordPress website. Last Tuesday we updated the plugin to warn about this security vulnerability, so if you had our plugin installed and you had version 2.7 of the WORDPRESS VIDEO GALLERY plugin installed you would have then seen the following warning on the Installed Plugins page:

Plugin Vulnerabilities Screenshot

Posted in Bad Security, WordPress Plugins | Tagged | Leave a comment

Preparing to Have Your Magento Website Upgraded

Upgrading is Magento is no small task. It is something that we recommend you hire someone do for you, not because we provide Magento upgrades, but because we know from plenty of experience how much trouble it can be. Whether you hire us or someone else do your upgrade there are a number of things we have found are important to do and consider when preparing for the upgrade:

Upgrading Usually Won’t Fix an Existing Problem

One thing that comes up often with upgrades of Magento, as well as other software, is clients hoping that the upgrade will fix some problem with the website. In most cases the upgrade won’t fix the problem and in some cases the problem can instead cause additional problems during or after the upgrade. Your best bet is to ask the person you are contacting about doing the upgrade if the upgrade will fix the issue and if it won’t, finding out what else they suggest should be done to resolve the issue. In many cases we have dealt with, the fix for the problem requires doing much less work than doing an upgrade.

A Test of The Upgrade is a Must

Almost no Magento upgrade is going to be without issues, this is the biggest reason to hire someone who does Magento upgrade regularly to handle the upgrade as they should be aware of how to handle most issues that come up and will be better equipped to work through issues they haven’t seen before. What is key to making sure the issues that will occur don’t impact the normal function of your website is doing a test of the upgrade first. This allows the issues to be spotted before the production website is upgraded and while you can compare how things were working in the old version.

In addition to dealing with the issues that come up, the test will also allow you to adjust to any changes that have been made between the version of Magento you use now and the version you are upgrading to. We find that many of the things that clients bring up to us during the testing relate to these types of changes.

Test in a Matching Server Environment

To insure you don’t run in to any unexpected problems when the upgrade is applied to the production website you should make sure to do the testing in a server environment that matches the production environment. This can usually be best accomplished by placing the test version of the upgrade in a directory on the website or by using a staging server configured the same as the production server. If you don’t do this you may run into problems. For example, one time we found during the testing that the shipping module that was in use wasn’t working in the new version of Magento due to a PHP module not being enabled on the server. When our client contacted their web host to see about getting it enabled the web host first claimed that the modules was enabled and it ultimately took several days of back and forth for them to finally get it enabled. If this had only been discovered after the production website was upgraded it would have been a big problem.

Test, Test, Test

We can’t emphasize enough the importance of checking over everything in the test before upgrading the production website as it much easier to resolve any issues at this stage of the process than once the production website has been upgraded.

Mention Any Failed Upgrade Attempts

If there has previously been a failed attempt to upgrade Magento it is important to mention that when discussing the upgrade as this can create complications during the upgrade. The biggest of these being that sometimes after the failed upgrade the database is restored over the upgraded database, which then causes the database upgrade portion of the second upgrade attempt to fail when it tries to add new tables to the database that already exist because they were added during the previous upgrade attempt.

Changing Your Theme

When discussing upgrades we are often asked about changing the theme in use along with the Magento upgrade. Our suggestion is to split up the upgrade and the theme change as that makes it easier to deal with any issues that come up during either one. We also suggest doing the upgrade first and then using the test of the upgrade to test out the new theme.

Handling PHP Changes

One of the big changes that came with Magento 1.9.1 is that Magento will not function on versions of PHP below 5.3 (the listed minimum PHP is even higher, PHP 5.4). Some hosting environments making switching PHP versions quite easy, but in some cases it can require moving to a different server so this will be something you will want to discuss with the person handling the upgrade ahead of time. Also, if you are still running Magento 1.3 the process for handling this will be more involved since that version of Magento was not designed for PHP 5.3 or higher.

Clean Up the Database

The Magento database can grow rather large in size due to long term storage of data that doesn’t actually need to be stored on a long term basis. This can negatively impact website performance when interacting with the database and can cause the website to go over its disk usage quota. During the upgrade process is a perfect time to check out if this is the case with your website as cleaning out the excess data can significantly speed up the database upgrade portion of the upgrade and people that handle upgrades are usually familiar with this issue due to that. Due to a change in Magento 1.9.1 that makes sending most emails reliant on the Magento cron job being set and enabled, the person handling the upgrade will need to insure the cron job is set correctly, so most of the work to enable automated log cleaning that takes care of much of the excess data problem going forward is already being done as well.

Posted in Magento | Leave a comment

Lessons from the FancyBox for WordPress Plugin Vulnerability

Last week a vulnerability in the WordPress plugin Fancybox for WordPress was exploited causing many websites to serve malware. A week later we thought it would be a good time to look at what went wrong and what lessons can be taken from the incident to hopefully improve WordPress plugin security going forward.

WordPress Plugin Security is in Bad Shape

When we started to look in to this, what we were most interested to see was what was the underlying vulnerability that allowed the websites to be hacked. Was it some obscure corner case that allowed a hacker access they shouldn’t have or was it some very fundamental failure? Since the developer stated they fixed the vulnerability in version 3.0.3 looking at the changes in that version was the starting place for understanding that. What the changes made show is that anyone could change the plugin’s settings. By anyone we truly me anyone, you didn’t have to be logged in to WordPress to change the settings. This wasn’t the intention of the developer, as can be see by the fact that only logged in users who are Administrators can access the plugin’s settings page.

The problematic code is the code for saving the settings, which did not check to make sure that the settings change came from the setting’s page. In 3.0.2 the code simply checked if a request for a setting updates was sent and then went on to save the settings:

if ( isset($_REQUEST[‘action’]) && ‘update’ == $_REQUEST[‘action’] ) {

The changed code in 3.0.3 checks to see where the request came from as well:

if ( isset($_REQUEST[‘action’]) && ‘reset’ == $_REQUEST[‘action’] && check_admin_referer( ‘mfbfw-options-options’ ) ) {

In many cases being able to change a plugin’s settings would not allow it to be used to serve malware. What allowed it in this cases is that the plugin has settings that allow additional code to be added to pages in which FancyBox for WordPress is present:

Fancybox for WordPress Extra Calls Settings Page

All the hacker had to do was to update the settings to turn on that feature and have it use their malicious code.

The fact that a plugin that now has over 600,000 downloads (each time an installed plugin is updated in WordPress that gets included in the download count, so the amount of websites using it is much lower) allowed anyone to change it’s settings and a hacker was the first person to discover this isn’t a good sign for the security of WordPress plugins. We think that Automattic has at least some responsibility for improving this situation.

The response after the fact was much better. The vulnerability was quickly fixed and WordPress automatically pushed the updated version for those running at least WordPress 3.7 (which introduced automatic updates)

Understanding the Scope of Vulnerability

When dealing with a hacked website an important element in the cleanup process is understanding the scope of the exploitation, so that appropriate cleanup action is taken. While it doesn’t hurt to do more than what is needed, it can take more time and increase expenses, which can be a major hardship depending on the website.

In this case the direct impact of the vulnerability is somewhat limited. The hacker is able to add code to the setting and that is loaded on pages on the website but because the setting is stored in the database safely using the update_option function they can not otherwise gain access the database through the vulnerability. It is possible for malicious JavaScript to provide the hacker additional access to the website if an admin was to have visited a page that has the code on it while logged in.

Once a website upgraded to at least version 3.0.4, any malicious code currently stored in the setting is disabled and the vulnerability is patched, so the website should be secure at that point, but you may want take the precautionary measures of changing the passwords associated with the website and checking over the website for malicious code or reverting the website to a backup made before the website was originally hacked.

The Settings API

When looking at how to improve code security, hoping that people will start writing secure code on their own isn’t a good bet. Some combination of making it easier to do things securely and making it harder to write insecure code seems to be an important element to improving the situation.

So could be something be done to deal with this type of situation? There already is a way to handle saving settings securely, the Settings API, which was introduced in WordPress 2.7. This API handles managing settings and only allows settings to be saved by users with manage_options capability, which is normally only given to Administrators (and Super Admins when using MultiSite). The problem with it is that it doesn’t appear to be used in many plugins (that includes our plugin with a settings page, which we are looking to rectify). It would be worth looking in to how to make it so that it is more widely used going forward.

Security Journalism is in Bad Shape

You don’t have to follow IT security closely to know that it isn’t in good shape these days, with major company after company revealing that sensitive customer data has been breached. Good IT security journalism could be an important piece of shining a light on bad practices (which are abundant) and ultimately getting security where it should be. Unfortunately, what we have found is that security journalism is in as bad or worse shape than the security they cover. Take for instance The Register’s article on the situation with this plugin. It misses many important details, like the fact the plugin was being automatically updated for many and that the update would take care of much of the issue. It then follows that up with some truly bad reporting:

The vulnerability followed what was described as the “most serious” hole in five years, disclosed last November, that affected what was then estimated to be 86 per cent of WordPress websites. That cross-site scripting hole was found in the hugely-popular WP-Statistics plugin.

First off we have yet to see any impact from the vulnerability that is mentioned as being the “most serious” hole in five years, its limited impact would be something to mention several months after it was fixed in outdated installs (the current version at the time was not vunerable, which would have been worth mentioning as well). The bigger mistake is that the author of the article is conflating a vulnerability in WordPress itself with an unrelated vulnerability in the the WP-Statistics plugin, despite having also written the article they are citing about the previous vulnerability.

Posted in Bad Security, Website Hacked, WordPress Plugins | Leave a comment