What to Watch For When Upgrading to Magento 1.9.1

Now that it has been a couple of months since Magento 1.9.1 was released we have had enough experience upgrading from older versions of Magento to 1.9.1 to discuss what we have found to be the important things to keep in mind when upgrading to that version. We have found that two major issues impact the upgrade:

Sending Emails Now Relies on the Magento Cron Job

One of the under the hood changes made in 1.9.1 is that most emails to be sent out are first placed in queue and then the queued emails are sent the next time the cron job for Magento is run. If you do not have a cron job configured or enabled (as was the case for one website we dealt with) then many emails, including order confirmation and transactional, will not been sent out.

If you are having a problem with emails not being sent in Magento 1.9.1 you can check if unsent queued emails are the problem by reviewing the core_email_queue table, which contains the emails that have been added to the queue. Once the cron job has run the “processed_at” value for emails will have the time that they were sent and if they have yet to be sent they will not have a value set for that.

During testing of the upgrade you will also need to make sure that the cron job is set up for the test installation as well.

PHP 5.3.0 or Newer Is Required

Up until version 1.9 the bare minimum version of PHP that Magento permitted was 5.2.0, in version 1.9.1 that has been increased to 5.3.0. For most part this isn’t an issue considering that PHP 5.3.0 was released in June of 2009 and the listed minimum PHP versions for Magento 1.9.1 is 5.4. Where it can cause an issue is if you are doing an upgrade from the very old Magento 1.3, which wasn’t designed to support PHP 5.3. If you are doing the test of the upgrade in the same server environment as the production website and you can’t use multiple versions of PHP at the same time you will need to either modify the existing Magneto installation to support at least PHP 5.3 or do the upgrade in two stages (first upgrading to 1.9, then changing the PHP version, and then doing the upgrade to 1.9.1).

Posted in Magento | Leave a comment

The Upgrade From Joomla 2.5 to 3.x Often Isn’t A One-Click Update

With support for Joomla 2.5 having concluded at the end of December more people are trying to upgrade to Joomla 3.x. With that more people are also realizing that the process isn’t quite as easy it might sound in many cases. While the Joomla documentation describes the upgrade type as “One-click to 3.x“, a number of issues can make the process more complicated. Before we get in to those issues, let’s get to the best piece advice we can provide after having done numerous upgrades from Joomla 2.5 to 3.0.x-3.3.x for clients over several years: make a copy of the website and test the upgrade on it first. This allows you to work through any issues that come up before you upgrade your production website, which makes the process easier and less stressful.

In most cases this is most easily accomplished by creating a copy the website in a new directory on the website, which you can then you would access by adding the directories  name to your websites address (for example if you website was www.example.com and the new directory was “joomla3″ then the copy would be accessible at http://www.example.com/joomla3/). You can do that through the following steps:

  1. Make a copy of your websites file and put them in the new directory on the website.
  2. Create new database and import the contents of your production websites database in to that.
  3. Update your configuration.php with the credentials for the new database and if you have the $live_site variable set, update that as well.

With that running you can then move on to doing the upgrade in that.

Extension Problems

The biggest problems when upgrading from Joomla 2.5 to 3.x comes from extensions. In the worst case a problem with an extension can cause the upgrade to fail and the website to completely be broken. This issue unfortunately is all too common occurrence and it is big part of why we suggest doing the test of the upgrade first as restoring the website after a failed upgrade is not something you want to have to do if you don’t absolutely have to. With a test copy you can just remove the broken test copy, make a new copy, and then retry the upgrade, this time making changes to make sure the extension that caused the problem does not cause the problem again by disabling it or removing it first.

While making sure that you have all of the extensions up to date and removing any that are not listed as being compatible with 3.x before the upgrade starts can help to limit problems with extensions it won’t handle everything. In one case an extension had been removed some time in the past but a plugin that was part of got left behind, the plugin then caused the Joomla search functionality to be broken in the newer version.

For some more complicated extensions you need to do multiple upgrades of the extension, some before and after the upgrade of Joomla from 2.5, which is also something you want test before doing on the production website.

Extensions Not Compatible With Your Version of 3.x

Another problem we have found is that just because an extension is listed as being compatible with Joomla 3.x, that doesn’t mean that it will work in the latest version of 3.x. For example in one case during an upgrade we dealt with an extension that was not functioning properly and traced the issue to something caused by a change in JavaScript libraries made in Joomla 3.2.x. Unfortunately the Extension Directory only lists if an extension is compatible with 3.x, so for extensions that haven’t been updated in a while you won’t know for sure if it is going to work properly until actually are trying to use it with the new version of Joomla.

Template Changes

We often find that existing templates require some minor tweaks to keep their existing styling when running on Joomla 3.x. That is much easy to do if you can see the way it looks in Joomla 2.5 while making the changes.

In small number of cases there have been more serious problems due to coding in the templates that causes broken pages to be shown when running in Joomla 3.x. It is much better to find and fix this in the test copy then having trying to fix it while customers are trying to access it.

Posted in Joomla | Leave a comment

FAQ: Should I Upgrade Magento and Change My Theme at the Same Time?

When discussing Magento upgrades with clients these days what is coming up more and more often is questions about changing the theme in use on the website and more specifically whether that should be done at the same time as the upgrade. Our current recommendation is to split up the upgrade and the theme change, for reasons we will get to in a moment, doing the upgrade first and then using the copy of the website used for testing the upgrade to test out the new theme before finally changing the theme on the production website.

Avoiding Additional Issues with the Upgrade

Upgrading Magento is almost never a process without issues, if you are lucky they are rather small, but in many cases they are rather large. To the extent possible you want to avoid making other changes at the same time as doing that as makes it harder to deal with the issues since you won’t know which change is the root of the issue when you start dealing with it. That advice applies not just to theme changes, but other major changes.

While new themes do not cause problems on the same level as an upgrade, they can sometime cause problems, with this being more likely if the new theme also adds new extensions to the website. Often times the new theme is going to go through a fair amount of customization, which can be accomplished without impacting the production website by using the copy of the website created for the upgrade to do that.

Limited Downside

The downside to splitting up the upgrade and theme change is that often themes will need some minor changes made to them to make them compatible with versions of Magento released after the theme was released, with a new theme designed for the new version that shouldn’t be necessary. If you hire a professional to do the upgrade – which we would definitely recommend based having seen the many problems that can come up during an upgrade – they shouldn’t have a problem checking if changes need to be made and making those changes, so the advantage a new theme provides is limited based on that. Further limiting the advantage is that we often find that those changes need to be made in design files that come with an extension instead of a theme, so most of the work related to this still needs to be done if a new theme is used during an upgrade.

Posted in Magento | Leave a comment

Automattic’s Responsibility for the Security of WordPress Plugins

As we have continued to refocus on the security of WordPress plugins due to our work on new plugin that warns of known vulnerabilities in WordPress plugins the question of who has a responsibility for improving the security of WordPress plugins has come up. Relying on the developers of the plugins to insure they are secure doesn’t seem to be working as many of the vulnerabilities we have reviewed are things that are not the result of complex issues, so they could have been prevented with relatively basic security precautions. Since WordPress is a volunteer effort expecting that those volunteers would be responsible for the overall security of third-party software doesn’t see right. But what about the company closely connected with WordPress, Automattic? With a valuation of over billion dollars they certainly have the financial wherewithal to bear the burden of some responsibility, but in the past we would have said no since they didn’t seem to have a direct connection with plugins, but as we recently stumbled upon they are taking advantage of them for business purposes.

Recently a reflected cross-site scripting (XSS) vulnerability was discovered in the Frontend Uploader plugin. After confirming that the vulnerability existed in the most recent version we went looking for a way to contact the developer of the plugin to alert that the vulnerability existed in their plugin. While doing that we came across a page for the plugin at Automattic’s  Wordpress.com VIP, a service where you can pay starting amounts of $5,000 a month for hosting and $1,250 for support. It turns out they offer a number of the plugins from the wordpress.org Plugin Directory to the customers of their VIP service. They tout those plugins (as partner integration) with this:

We’ve added 200+ extra features on top of WordPress for everyone on WordPress.com—and just for VIPs, we’ve added the additional plugins below, which can be integrated into your sites with a single-click, so you can take advantage of powerful partner integrations and features without touching a line of code.

Their marketing materials also touts their claimed security (which hopefully has improved after the major breach they had a few years ago):

We stay awake at night, watching over your site, so you don’t have to. Our site monitoring and secure codebase ensure an impressive uptime, and our operations team is always hands-on.

Based on all of this we certainly think that Automattic has a responsibility for improving the security of WordPress plugins since they are getting benefit from them.

If they are going to live up to that responsibility they have a lot of work to do, as can be seen in this case. After the vulnerability was disclosed in a plugin they are redistributing they don’t appear to have done anything about. As far as we can tell the vulnerability was only fixed after we reported the vulnerability to the people running the WordPress.org Plugin Directory (since we couldn’t find a direct contact for the developers of the plugin) and them pulling the plugin pending a fix. While the plugin was gone from the Plugin Directory it was still listed on the WordPress.com VIP website, though we don’t know if they continued to distribute it. It doesn’t even look as if people using WordPress.com VIP would know that the plugin had a vulnerability fixed since the changelog makes no mention of the new version, 1.9.3, or the security fix in it (which unfortunately is an all to common problem when plugins receive security fixes).

Posted in WordPress Plugins | Leave a comment

WPScan and Sucuri Put WordPress Websites at Risk

Yesterday we discussed a situation where the WPScan project didn’t bother to notify the developer of a WordPress plugin or the wordpress.org Plugin Directory about a vulnerability that they knew about. Some might excuse WPScan’s responsibility to alert them based on the fact that the vulnerability was discovered by someone else and already publicly disclosed. After running in to that situation we took a closer look at the WPScan project and found something more troubling. Back in March they started discussing a backup plugin that wasn’t properly securing backup files made by it. The issue was quite serious since some of the backup files, which can contain sensitive information, made by the plugin could be easily found with just a simple Google search. In the thread no one even brings up the idea of notifying the developer of the plugin or the Plugin Directory about the issue, which would be the way to get it fixed. Instead there is some discussion in thread on how to further exploit the poor security of the plugin in the WPScan vulnerability scanner.

We are quite sure that no one ever bothered to contact the Plugin Directory about the issue because within hours of us notifying them last week the plugin was pulled from the directory pending the security being improved. Within a few days of that, security improvements were introduced to the plugin. Based on the plugin developer’s comment at the end of the thread it doesn’t sound like WPScan had informed them either.

What makes this particular troubling is that at the same time they are at least knowingly leaving websites insecure they are selling WordPress security services.

They are not the only ones selling security services involved in this. Prominently displayed on the WPScan homepage is a banner letting you know the project is sponsored by Sucuri:

WPScan is Sponsored by Sucuri

We would ask why a security company would sponsor a project that seems more interested in exploiting security issues than fixing them, but we already know that Sucuri doesn’t have much interested in websites actually being secure. We have often been hired to re-clean websites that had previously cleaned by Sucuri. What we have found in those cases is that Sucuri didn’t do basic parts of a proper cleanup, including making sure the software on the website was up to date and determining how the website was hacked, which if done would have made it less likely that the website would be hacked again.

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

An Easy Way to Check If You Are Using Vulnerable Versions of Revolution Slider, Showbiz Pro, and Other WordPress Plugins

When it comes to the security of WordPress, despite lots of misinformation and outright fear mongering, the security is quite good. The developers of WordPress have been quite good at handling security, and when a security issue is found they promptly respond to the issue and the fully automatic update mechanism for security updates included since WordPress 3.7 means that those security updates are promptly applied for most websites. Unfortunately the handling of security of plugins isn’t as good. While most of the vulnerabilities found in plugins are unlikely to lead to your website being hacked, there are some that are easily exploitable. In most cases simply updating your plugins when WordPress notifies you of a new version will protect you (or setting them to automatically update with our Automatic Updates Plugin or another similar tool), but there are a couple of situations where that isn’t true.

The first situation is where a plugin that is in the wordpress.org Plugin Directory has a vulnerability that isn’t’ fixed. Once the people running Plugin Directory are informed of the issue they will pull the plugin. That will prevent anyone more from installing the plugin but leaves everyone already running the plugin vulnerable as they are not provided any warning. We have been pushing for that to be changed for several years, but that still hasn’t happened. If you would like to see that change then please vote for that to happen.

The second situation is where a vulnerability exists in a plugin that isn’t in the wordpress.org Plugin Directory. While it is possible for these plugins to be hooked into WordPress’s normal update mechanism that isn’t always done, leaving the admin of the website to be unaware of a new version with a security fix being available.

For the first situation, we have for some time provided a plugin that lists installed plugins that have been removed from the directory and in some cases also includes a security advisory. For the second situation, we have new plugin that can help with that by warning if versions of plugins with known vulnerabilities are installed in WordPress.

Let’s take a look at how that works. Recently the Revolution Slider and Showbiz Pro plugins have been getting a lot of attention for a couple of security issues that existed in older versions. The first vulnerability allowed the viewing of arbitrary files (that could be exploited to view the database credentials stored in the wp-config.php file), that impacts Revolution Slider versions 4.1.4 & below and Showbiz Pro versions 1.5.2 & below. The second and much more serious vulnerability allows malicious files to be uploaded on to the website, that impact Revolution Slider versions 3.0.95 & below and Showbiz Pro versions 1.7.1 & below. If you have our Plugin Vulnerabilities plugin installed and you have one of those versions of Revolution Slider or Showbiz Pro installed you will see an alert message on the Installed Plugins page like this:

alert message shown for vulnerability in Revolution Slider

In addition to the vulnerabilities in Revolution Slider and Showbiz Pro our plugin currently has data on 116 vulnerabilities. That is still a small portion of all the plugin vulnerabilities out there, but we are continuing to add additional vulnerabilities. This week we added 30 vulnerabilities to the plugin. Going back to the first situation where plugin have been removed from the wordpress.org Plugin Directory the plugin also helps with that as we have data on security vulneabilities in the most recent versions of 24 plugins, which have been removed from the Plugin Directory.

With the plugin you can also see vulnerabilities that have existed in other versions of plugins you have installed from the Plugin Vulnerabilities page in the Plugin menu.

Posted in WordPress Plugins | Leave a comment

Wordfence and WPScan Acted Irresponsibly With WordPress Plugin Vulnerability

Several years ago we noted a pretty big problem when it came to the security of WordPress plugins; many plugins with known security vulnerabilities in their most recent version were still available in the wordpress.org Plugin Directory. That was a big failure as making sure that those vulnerabilities were fixed or the plugin was pulled until it was fixed was such a low hanging fruit towards better plugin security. For a while after that we were keeping a watch for unfixed vulnerabilities to make sure that wasn’t occurring, but after a while we were simply too busy with services unrelated to security of WordPress that we didn’t have time to do this anymore. Recently we again had time to focus on the security of WordPress plugins, as part of that we started working a new plugin, Plugin Vulnerabilities, which lets you know of security vulnerabilities that exist and existed in the plugins you have installed.

When we started working on the plugin we quickly found that the issue of plugins with known vulnerabilities in their most recent versions still being available in the wordpress.org Plugin Directory hasn’t gone away. In less than a month we have helped to get known vulnerabilities in seven plugins fixed by either contacting the developers of the plugins – who in many are not notified by the person who discovered the vulnerability – or letting the people running the Plugin Directory know that a vulnerability exists in the plugin. Some of them were rather serious, one that we mentioned before involved a backup plugin that permitted any logged in user to download backups made by the plugin. In that case within a day of us passing along the issue to the Plugin Directory people the issue was resolved, that was after almost a month had gone by since the developer had been notified of the issue and two weeks after it was made public.

While looking into another vulnerability we found something more troubling. On September 10 a claimed vulnerability was disclosed in the plugin Rich Counter. In late November when we took a look at it to verify that it was real before add it to our plugin, we found that as described the exploit didn’t work. To exploit the vulnerability it said you should change your web browser’s user agent to “Mozilla<script>alert(document.cookie)</script>”. For us it didn’t work that way, but it did work if you removed “Mozilla” from the start of the user agent. We were somewhat curious as to what had happened to cause a situation where a vulnerability was correctly identified but the explanation of the exploitation of it to not work. We thought it might be case where someone else had actually discovered the issue and someone else was trying to take credit for it. We didn’t find anything to explain the situation, but while doing that we found that several WordPress related security projects had mentioned the disclosure of the vulnerability. We are rather troubled that they were aware of the vulnerability but had not made sure it was fixed or the plugin was pulled from the directory. What made this worse was that within days of us alerting the developer to the issue a partial fix was made and after further message the issue appears to be fully fixed. It would have been quite easy for them to have done the same, but they didn’t leaving website vulnerable when they didn’t have to be, so we feel it is worth highlighting their irresponsible behavior.

First up is Wordfence, which sells a WordPress security service. They mentioned the vulnerability back on October 30 in a post about plugins with vulnerabilities they wanted  “to draw your attention to”, unfortunately they were more interested in drawing your attention to their website then actually drawing the attention of the developer to the issue who would have actually fixed the issue if they had contacted them as we did (or if the developer was unwilling at that time Wordfence should have then contacted the WordPress.org Plugin Directory about it).

The other place we found it mentioned was the in WPScan Vulnerability Database, a website that lists WordPress vulnerabilities,  in an entry added on October 18. Again this came from someone selling WordPress security services and the project is also sponsored by another security company Sucuri. You have to question why security companies would be in the business of providing wider notice of security vulnerabilities in WordPress plugins but not letting the developer, who could actually fix the issue, or the people at the Plugin Directory know about the issue if their interest was truly in security versus making you more vulnerable and then selling you their security services.

Posted in Bad Security, WordPress Plugins | Leave a comment

Be Careful With Your Website’s Backup Files

When a high profile website gets hacked it always useful to see what lessons can be gleamed to insure that other websites don’t get hacked. Several days ago the technology website Ars Technica (who doesn’t have the best track record with security reporting) was breached, while the details on how they were hacked are somewhat limited, one thing stood out (emphasize ours):

At 20:00 CT on December 14, an Internet intruder gained access to one of the Ars Web servers and spent the next hour attempting to get from the Web server to a more central machine. At 20:52, the attempt was successful thanks to information gleaned from a poorly located backup file.

That is a good reminder that since backup files often store sensitive information (including database login details and user info), securely storing them is important to the security of your website. For example, you would not want to store the backup in a file named backup.zip in the root of your website since hackers will go looking for that as can be seen in the log file entries below from a recent attempt to find backup files on our website:

124.231.26.79 – – [03/Dec/2014:04:11:07 -0500] “HEAD /www.whitefirdesign.com.7z HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:07 -0500] “HEAD /www.whitefirdesign.com.xls HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:08 -0500] “HEAD /www.whitefirdesign.com.xlsx HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:09 -0500] “HEAD /www.whitefirdesign.com.sql HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:10 -0500] “HEAD /whitefirdesign.com.rar HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:12 -0500] “HEAD /whitefirdesign.com.zip HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:12 -0500] “HEAD /whitefirdesign.com.7z HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:14 -0500] “HEAD /whitefirdesign.com.xls HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:15 -0500] “HEAD /whitefirdesign.com.xlsx HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:15 -0500] “HEAD /whitefirdesign.com.sql HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:16 -0500] “HEAD /whitefirdesign.rar HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:17 -0500] “HEAD /whitefirdesign.zip HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:18 -0500] “HEAD /whitefirdesign.7z HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:19 -0500] “HEAD /whitefirdesign.xls HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:20 -0500] “HEAD /whitefirdesign.xlsx HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:20 -0500] “HEAD /whitefirdesign.sql HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:21 -0500] “HEAD /back.rar HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:22 -0500] “HEAD /back.zip HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:23 -0500] “HEAD /back.7z HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:23 -0500] “HEAD /back.xls HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:24 -0500] “HEAD /back.xlsx HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:25 -0500] “HEAD /back.sql HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:26 -0500] “HEAD /backup.rar HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:27 -0500] “HEAD /backup.zip HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:28 -0500] “HEAD /backup.7z HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:29 -0500] “HEAD /backup.xls HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:30 -0500] “HEAD /backup.xlsx HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:31 -0500] “HEAD /backup.sql HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:31 -0500] “HEAD /web.rar HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:32 -0500] “HEAD /web.zip HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:33 -0500] “HEAD /web.7z HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:34 -0500] “HEAD /web.xls HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:35 -0500] “HEAD /web.xlsx HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:35 -0500] “HEAD /web.sql HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:36 -0500] “HEAD /webroot.rar HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:37 -0500] “HEAD /webroot.zip HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:38 -0500] “HEAD /webroot.7z HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:39 -0500] “HEAD /webroot.xls HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:40 -0500] “HEAD /webroot.xlsx HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:41 -0500] “HEAD /webroot.sql HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:41 -0500] “HEAD /www.rar HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:42 -0500] “HEAD /www.zip HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:43 -0500] “HEAD /www.7z HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:44 -0500] “HEAD /www.xls HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:45 -0500] “HEAD /www.xlsx HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:46 -0500] “HEAD /www.sql HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:46 -0500] “HEAD /wwwroot.rar HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:48 -0500] “HEAD /wwwroot.zip HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:48 -0500] “HEAD /wwwroot.7z HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:49 -0500] “HEAD /wwwroot.xls HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:50 -0500] “HEAD /wwwroot.xlsx HTTP/1.1″ 404 506 “-” “-”
124.231.26.79 – – [03/Dec/2014:04:11:51 -0500] “HEAD /wwwroot.sql HTTP/1.1″ 404 506 “-” “-”

Unfortunately not every risk is that easy to spot, take for example a vulnerability in the XCloner – Backup and Restore WordPress plugin that we discussed last week that allowed any logged in user to download any backups made by the plugin.

Posted in Website Security | Leave a comment

The Joomla Extension Directory Finally Moves Off of Joomla 1.5

When it comes to the security of websites what we see is that basic security measures are often not taken and unfortunately all too often those measures are not being taken by those who should know better and have the ability to make it easier to accomplish them. Take for instance the Joomla, until yesterday the Extension Directory portion of their website, an important section of the website, was still running Joomla 1.5:

jed-joomla-15

That is despite the fact that support for that version ended back in September of 2012. It obviously doesn’t look good when the developers of software can’t even keep on a supported release of their own software.

Thankfully, the Extension Directory has now been moved to Joomla 3.3:

jed-joomla-33

Unfortunately it doesn’t appear that even their inability to get off of Joomla 1.5 for so long has lead them to provide anything to make it easier to move off that version, which many others still remain on.

Posted in Bad Security, Joomla | Leave a comment

Security Vulnerability Fixes Often Left Unmentioned In WordPress Plugin Changelogs

When it comes to security companies, we often see that they seem less interested in actually improving security than getting themselves attention. In some cases the harmful effects of this are quite obvious, like when a security companies falsely implicates a piece of software as being a common connection between a group of hacked websites leading people to believe that software is insecure when it isn’t. A less obvious situation where this attention seeking comes in to play is when a security company warns that you need to update a WordPress plugin since it has a security vulnerability. What could be the problem with that you are probably thinking? The answer is that you need to update all of your plugins in a timely manner, and not try to keep track of what ones might have a security vulnerability and therefore need to be updated immediately. The reason for this is that there is a good chance that you won’t be able to tell if an update fixes security vulnerability, even if you review the changelog for plugin (which in turn is more likely to warn you about security issue than following any security company).

Recently we started working on a new plugin, Plugin Vulnerabilities, that provides information on vulnerabilities that exist and previously existed in the plugins you have installed in WordPress. One of the places we look at when determining what versions of a plugin are susceptible to a vulnerability is the plugin’s changelog. In doing that we have found that the amount of details provided in the changelog when a security issue is fixed varies widely. In many cases the fact that a vulnerability has been fixed is disclosed (sometimes with basic details of the vulnerability include as well), but in plenty of cases there is no mention at all that a security vulnerability has been fixed.

To get a better idea how frequently security vulnerability fixes are left out of the changelog, we went through the vulnerabilities currently listed in our Plugin Vulnerabilities plugin for which the relevant plugin is currently in the wordpress.org Plugin Directory and tallied up whether the vulnerability being fixed was mentioned in the changelog or not. In our sample of 66 plugin updates, we found that in 19.7 percent of them the changelog made no mention of a vulnerability being fixed. The breakdown of the changelog mentions are as follows:

  • 43 updates listed that a vulnerability fix was included
  • 10 updates mentioned that a fix for a potential or possible vulnerability was included (in all cases the vulnerability was in fact exploitable)
  • 13 updates made no mention of a vulnerability being fixed

Jut based on the fact that you have about a 1/5 chance that a security fix isn’t mentioned in changelog, not updating plugins all the time seems like a bad idea, but what is more important is how severe the vulnerabilities fixed that are not mentioned can be. Take for instance version 5.2.91 of Special Text Boxes plugin, which had the following listed as the change made in the release:

The possibility of manipulating custom themes has been removed by request of administration of wordpress.org plugins repository.

Would you have guessed that referred to fixing an arbitrary file upload vulnerability that was being actively exploited before 5.2.91 was released? Probably not.

Posted in WordPress Plugins | Leave a comment