No One Bothers to Report Security Issue in WordPress Theme Either

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:

fusion-theme-download-graph

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.

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

Is it Time to Upgrade to Zen Cart 1.5.4?

It has now been a couple of months since Zen Cart 1.5.4 was released and we have now handled enough upgrades to the new version to provide our insights on whether it is time to upgrade Zen Cart 1.5.4.

Let’s start with what is new in Zen Cart 1.5.4. The new version doesn’t include any major changes. Instead it includes bug fixes, minor improvements, and security improvements. You can find the full list of changes in the release announcement.

The only issue we have found so far during upgrades is that many addon modules don’t officially support Zen Cart 1.5.4 yet. For some modules they may not need any changes and their maintainer just hasn’t bumped the Zen Cart version supported. Others that modify core Zen Cart files will need to have updated versions of those files included, until they do that you can use those with 1.5.4 if you apply the changes they make to those files to the versions of the file include with 1.5.4. The lack of official support is more of an issue if the modules don’t yet support at least Zen Cart 1.5.3 since that version made some changes that can have significant impact for modules.

With the basics set out, below we provide on advice on whether it is time to upgrade depending on your current situation:

Running Zen 1.3.9, 1.3.8, or older

If you are still running Zen Cart 1.3.9, 1.3.8, or and even older version you are overdue for an upgrade at this point so you should probably go ahead with the upgrade now. While issues with modules and 1.5.4 could cause some issues, you are going to probably run into module issues that will have to be dealt during testing when upgrading from those versions to any version of Zen Cart 1.5.

Need to Be Using a PA-DSS Certified Version of Zen Cart

Prior to Zen Cart 1.5.4 the only version of Zen Cart to be PA-DSS certified was 1.5.0, so you were stuck on that version if you needed PA-DSS certified software for PCI compliance. That wasn’t ideal obviously, but now you can now upgrade and you might need to since the “certification spec expired at the end of 2013″ for 1.5.0.

Web Hosting Account Switching to PHP 5.4, 5.5, or 5.6

The number one reason we are hired do Zen Cart upgrades is that version currently being used is not compatible the version of PHP that the web server the website hosted on is being upgraded to. With the support for PHP 5.3 ending back in August web hosts should be moving to at least PHP 5.4 soon (though many web host are only now transitioning off of PHP 5.2 despite support ending in January of 2011). Zen Cart 1.5.4 is the second release to support PHP 5.4, 5.5, and 5.6 so anyone who is not using Zen Cart 1.5.3 and is moving to those versions of PHP should upgrade.

Running 1.5.0, 1.5.1, or 1.5.3

If you don’t need to upgrade for the new versions of PHP, don’t have an urgent need for an of the bug fixes or improvements, and use a lot of modules you may to want hold off until more modules are updated for Zen Cart 1.5.4. Otherwise, it would be a good idea to do upgrade now.

Posted in Zen Cart | Leave a comment

Google’s Bad Answers

Recently we wrote a post on how Google was placing bad instruction for upgrading Zen Cart directly in the search results. We have run across another example of where Google isn’t providing a good answer. If you do a search for “Magento PHP 5.5″ currently you get the following answer above the normal search results:

This link says that Magento is compatible with PHP 5.2.13 - 5.3.24, but when you run the PHP script to check server requirements, it says that is okay to run on 5.4 and even 5.5. But I've seen some issues with 5.4 over the internet.Aug 23, 2013

Unlike the Zen Cart upgrade example, the information isn’t wrong, it just out of date. If you following the link referenced in that answer you are taken to the Magento System Requirements page which now lists the latest version of Magento, 1.9.1, as being compatible PHP 5.4 and 5.5 (as we mentioned in a previous post, as of Magento 1.9.1 the bare minimum it will allow being run on is 5.3.0).

The Magento System Requirements page was the first result when we did the search:

magento-php-5-5-google-first-result

So excluding a direct answer would have produced a better result in this case (by comparison the page Google took their answer from was ranked 7th).

Posted in Google, Magento | Leave a comment

WordPress Leaves Very Vulnerable Plugin In Plugin Directory

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();

to

$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.

79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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″
79.143.187.194 – – [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.

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

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 2.5.1.1 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.

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

Google’s Bad Instructions for Upgrading Zen Cart

Google started out just providing text snippets and links to other websites in their search results and then overtime started adding more information directly in to the search results. For example, you can get sports scores right on the search results page. Sports scores are simple factual data so it hard to get those wrong, but more complex information is easier to get wrong. We recently made aware example where they are providing quite bad information.

Currently if you do a search related to upgrading Zen Cart you will get shown the following instructions above the results:

Google Zen Cart Upgrade Instrutctions

The instructions are taken from a page on GoDaddy’s website.

What sticks out to us is that not only are the instructions wrong, but they seem to have been written by some who doesn’t have any actual familiarity with Zen Cart.

Let’s start with the note above the instructions on GoDaddy’s page:

NOTE: If you are using Zen Cart schema 1.3.8a, you need to upgrade to 1.3.9 before upgrading to version 1.5. Otherwise, you will get errors.

This just doesn’t make any sense as the Zen Cart installer, which is used to upgrade the database schema, doesn’t have a problem doing an upgrade from 1.3.8a to the latest version, 1.5.4, without going to 1.3.9 first. Below is screenshot when doing that, you can see that not only does it allow you upgrade going back to that version, but it allows you to start from version 1.2.7:

Zen Cart Database Upgrade Selections

The next thing that stands out is step 5, “Disable all plugins and set your theme to the default.” The way Zen Cart handles addons is different than a lot of other software. With WordPress for example, plugins are stored separately from the core software and you have the ability to enable and disable them from a central location. With Zen Cart addons they are more tightly connected to Zen Cart. In some cases the addons are modification to core Zen Cart files, which cannot be disabled short of removing the code. For other addons the addon itself would have to provide a mechanism for disabling, which many do not. We get the sense that the person writing took this advice from some other software, without understanding that it wasn’t applicable to Zen Cart.

Finally, the biggest problem with the instructions is the lack of any actual instructions on doing the upgrade. The entirety of GoDaddy’s instruction is “Upgrade Zen Cart to 1.5.0. For more information, see this Zen Cart help article.” The “more information” implies that “Upgrade Zen Cart to 1.5.0.” actually provided some information, which it didn’t. If you follow the link you land on Zen Cart’s 1,200+ word upgrade instructions that are nothing like GoDaddy’s. The whole thing comes across as attempt to write something around the link to the actual instructions, which they filled with incorrect information. Google’s inclusion directly in the search results then compounds this.

When we do Zen Cart upgrades we use the patch files we have created, which can make it easier to do the upgrade than using the official Zen Cart method.

Posted in Zen Cart | Leave a comment

SiteLock Still Failing To Do Basic Security Check

Back in September we looked at the fact that a website we were doing an upgrade of Magento on had a security seal from SiteLock claiming that the website was secure, despite the fact that it wasn’t since the website was running outdated software with known security issues. Fast forward six months and SiteLock is still labeling websites as secure when they are running outdated and insecure software.

Today’s case involves a website that we are doing an upgrade from Zen Cart 1.3.8a. That version is nearly five years out of date and there have been numerous releases with security improvements since then (due to its age, it isn’t clear exactly how many of those fix issues that existed in 1.3.8a). Despite that the website is labeled as being secure by SiteLock:

Sitelock Security Seal

Not only does falsely claiming the website is secure mislead those visiting the website, but it also gives webmaster a false sense of security, which a security service shouldn’t do.

If SiteLock was actually interested in security it would quite easy for them to make sure the software on websites is up to date. Our Zen Cart Version Check extension for chrome is able to correctly detect the version in use from outside the website in this case:

Zen Cart Version Check

With access to the website’s file, as Sitelock does, it is even easier to do and more accurate. For Zen Cart the version number is listed in the file /includes/version.php, so all you would need to do is to check files matching that for the following lines and you would know whether an outdated version of Zen Cart is in use:

define(‘PROJECT_VERSION_NAME’, ‘Zen Cart’);
define(‘PROJECT_VERSION_MAJOR’, ‘1’);
define(‘PROJECT_VERSION_MINOR’, ‘3.8a’);

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

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 | Leave a 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 5.6.3.2 was released in September and 5.6.3.3 was released in February.

MOJO Marketplace is providing concrete 5.6.3.1

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