Don’t Get Caught With Plugin VulnerabililitesWith our Plugin Vulnerabilities service you are alerted if you any of the WordPress plugins you use contain a security vulnerability.
Search This Blog
- SiteGuarding.com’s WordPress Security Plugin Touts Its Use For Those That Pirate Software, While Charging For Its Services
- The Fact That Wordfence Couldn’t Clean Up a Hacked Website Doesn’t Stop People From Suggesting That It Will Clean It
- Google Needs to Improve the Review Process for Websites Labeled “This site may be hacked”
- iThemes Security Plugin Has “One-Click Secure” Button That Does Nothing Except Claim The Website Has Been “Secured”
- WordPress Leaks Potentially Sensitive Information From Private Posts and Pages
Web Software Updates
WordPress VersionWe are running WordPress 4.5.1 and despite what many supposed "security experts" claim letting you know what version we are running does not make us less secure.
Did We Make a Mistake?While it seems to be acceptable for blogs discussing web security to contain numerous factual mistakes, we hold ourselves to a higher standard. We only write about things that we actually understand and only after we have double checked the information. So if you see a mistake in one of our posts please leave a comment on the post or contact us so that we can add a correction.
Category Archives: Joomla
Joomla has put out an announcement that a new version, 3.4.5, will be released at 10 AM Eastern on Thursday that will contain a “very important security fix”. No details of what is the issue being fixed is have been released, but this is the first time that they have put out announcement like this as far back as we can remember, so it appears to be something that would be a major concern.
The last release that fixed a vulnerability that was exploitable in a non-targeted fashion was version 2.5.3, which came out in March of 2012.
For those still running 2.5.x, it would be a good time for you to upgrade as support for that version ended back in December. That upgrade often isn’t a one-click upgrade.
When it comes to keeping websites secure, keeping the software on them up to date is one of the basic measures that needs to be taken. We know that web hosts are aware of this because they will often tell people when their websites have been hacked that it was due to outdated software (since this usually isn’t based on any actually evidence, it often is wrong). Unfortunately we continue to find that web hosts don’t bother to make sure that they are not distributing outdated software to their customers.
Recently while doing some work on a web site hosted with InMotion Hosting, we noticed that in the website’s cPanel control panel that the option to install Joomla 2.5 was being prominently displayed:
That should not be happening since support for Joomla 2.5 ended back on December 31. Not only does that put websites at risk if a security issues is found in Joomla 2.5, but it can cause unnecessary trouble down the road because upgrading from Joomla 2.5 to 3.x is not always the one-click upgrade it is a promoted as.
On the installation page they do provide the option to install the currently supported version of Joomla, 3.4.1, as well. But you would have to select that version from a drop down box:
The problems don’t stop there. On the main page for their software installing service the ninth slot is Moodle 2.0:
Support for Moodle 2.0 ended nearly three years ago, in June 2012.
As with Joomla, they do also offer supported versions, but you would have to select those from a dropdown where 2.0 is the default:
Installing this version now will lead to otherwise unnecessary work down the road because Moodle will have to be upgraded to version 2.2 before it can be upgraded to a version 2.3 of higher.
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:
- Make a copy of your websites file and put them in the new directory on the website.
- Create new database and import the contents of your production websites database in to that.
- 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.
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
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.
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:
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:
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.
We were recently checking something in our analytics and noticed that a rather odd URL had been accessed. The URL, http://www.whitefirdesign.com/blog/?option=com_user&view=reset&layout=confirm, was for a section of our website running WordPress but the URL parameter, ?option=com_user&view=reset&layout=confirm, was for something Joomla related based on the “com_user” portion. A quick search identified that this was an attempt to exploit a vulnerability in older versions of Joomla. What is interesting about this is that the vulnerability was fixed in Joomla 1.5.6, which was released in August of 2008. Since most hacking attempt will not show up in analytics – due to them not requesting the tracking code – we were curious to see if there had been other attempts to exploit this that would show up in our access logs. We found that in the last six months there were attempts to exploit the vulnerability on 48 days. So hackers still feel there are enough Joomla website that haven’t been updated in six years to try to exploit it regularly.
There are a couple of quick takeaways from this. One is that is that if you still have websites running Joomla 1.5, for which support ended in September of 2012, you should make sure they have been upgraded to the last version, 1.5.26, and had the additional security fix applied so that they are protected against attempts to exploit any vulnerabilities in older versions. The other is that you don’t need concerned just because there has been an attempt to exploit a vulnerability on your website, considering that in this case a hacker tried to a vulnerability in very old versions of Joomla on a website running WordPress.
When it comes to IT security companies, what we see over and over is that they have little to no concern for security (and also often have little to no understanding of proper security practices). So it isn’t surprising that despite billions being spent on IT security, IT security continues to be in such poor shape. This leads to situation like the massive breach of Target’s systems last year. While that was big news, what didn’t get much attention was the company who declared Target compliant with standards for handling credit card transactions shortly before the breach, Trustwave. Trustwave has a history of declaring companies compliant shortly before they suffer major breaches and for being lax in their assessments.
We recently spotted another example of their highly questionable practices of Trustwave. We were contacted about doing a migration of a Joomla-based website still running version 1.5, for which support ended in September 2012. While taking a look at the website, we noticed a seal for Trustwave Trusted Commerce:
Considering that the website is running software that is no longer supported and therefore cannot be considered secure, we were curious to see if Trustwave was claiming it was secure. It would be quite easy for them to find that the website is running Joomla 1.5 if they wanted to as the source code of every page on the website the following line is included:
<meta name=”generator” content=”Joomla! 1.5 – Open Source Content Management” />
If you click on the seal you get this page:
At the top of the page Trustwave proclaims that “Your credit card and identity information are secure.”, which they shouldn’t be saying for a website that is running unsupported software.
As we looked closer we noticed the small text disclaimer at the bottom of the page were they say “Trustwave Holdings, Inc. makes no representation or warranty as to whether [redacted] systems are secure from either an internal or external attack or whether cardholder data is at risk of being compromised.”. So they are basically telling you that despite saying “your credit card and identity information are secure”, there not actually saying that at all.
It is highly inappropriate for them to mislead the public like they are doing with this seal, but unfortunately our experience is that this kind of thing is considered acceptable in the security industry.
Recently we have had a lot of blog posts highlighting major organizations running outdated and insecure versions of Drupal, but we don’t want to give the impression that it is only with Drupal based websites that major organizations are failing to keep the software up to date on. So we wanted to find an example of a website running Joomla to highlight as well and we quickly found a very concerning example. The third website listed on Joomla’s showcase of websites running Joomla is the website of Guaranty Trust bank, which is Nigeria’s largest bank and has assets of over 12 billion USD. As you can see with our Joomla Version Check web browser extension, available for Firefox and Chrome, their websites is running a fairly out of date version of Joomla:
That version is over two years out of date and there have been twelve subsequent updates with security fixes. One of the security vulnerabilities fixed in a subsequent version is of particular concern. The vulnerability, which we discussed before, allows a new user account to be created with “Administrator” privileges through privilege escalation. If user registration is disabled this will not work, but in this case it does appear that user registration is enabled. It is important to note that account access portions of Guaranty Trust Banks’ website are separate from the main website, so they are not directly impacted by the lax security of the main website. But it does raise the question of how well they secure the other portions of their website if they are not doing something this basic. Also, if someone could exploit one of the vulnerabilities in the version of Joomla on the main website they could change the links directing people to the account access portion of the website to another location and use that to gather login credentials.
Due to how potentially serious the security issue with their website is we attempted to contact Guaranty Trust Bank as soon as we saw the version they are running, but we were unable to get far. For one of their listed email addresses we got back message that the mail box was full. For the other we were told to “liaise with our Corporate Affairs Unit at the head office”, but our reply asking how to do that was met with a message that the email address we were replying to did not exist.
Fairly often we have people contacting us about doing an upgrade of software on a website, which they are hoping will resolve a hacking or other security issue. Unfortunately in most instances they don’t tell us that is why they want an upgrade done. In the worst case this could cause the upgrade to get messed up if the hack has made modifications to things that are affected by the upgrade. In many cases the upgrade isn’t going to fully resolve the issue and may not have any impact at all. For example, if a website was running Joomla 1.6, 1.7, or 2.5.0-2.5.2 and it got hacked due to the privilege escalation vulnerability in those versions, which allows someone registering a new account to escalate their account to “Administrator” level, upgrading would prevent new accounts with those privileges from being created but the existing accounts would still exist. Those accounts can be deleted, but you have to know they exist to do that. The upgrade also might overwrite other modifications the hacker(s) made to the website, but it might not.
For website still running Joomla 1.5 the website cannot be upgraded to a newer version. Instead a more complicated migration, which move content from the Joomla 1.5 installation to a new install of Joomla 2.5 or 3. Despite support for that version ending in September of 2012, the version is still widely used and we recently have been contacted about a lot of hacked website that are still running Joomla 1.5. Since the migration leaves a lot of the website behind it would reasonable to wonder if a migration will resolve the hack. A website we were just dealing is reminder that isn’t the case.
There are three major areas where parts of the hack could move over during the migration. First a common place for placing malicious files is in a website’s images folder, which is something that will move over to new website. Another common area where malicious code is placed is in theme files. While Joomla 1.5 themes are not directly compatible with newer versions of Joomla, some can be easily converted to the new version either by hand or with automated tools. The third area, which is where malicious code was in this situation, is the in the database. In this case the malicious HTML code had been added to the content of a number of articles, which was moved over during the migration.
Last month we spotlighted at the fact that 31 percent of Joomla websites checked with our Joomla Version Check tool during January were still running Joomla 1.5, for which supported ended September 2012. This month we decided to take a look at if websites that were running a supported Joomla series, either 2.5.x or 3.x, were being kept up to date based on last month’s data from the tool. Unlike websites still running Joomla 1.5 that need a more complicated migration to be brought up to a supported version, the upgrade process for websites running 2.5.x or 3.x is relatively simple. Keeping software running on a website up to date is a basic security measure, so if websites are not being kept up to date when it is relatively easy it shows that website security is in bad shape.
Joomla 2.5.18 was released during the month so Joomla 2.5.x websites would have been up to date if they running 2.5.17 or 2.5.18. Unfortunately 58 percent of the Joomla 2.5 websites were detected as running older versions (for some installations the tool only could tell they were using Joomla 2.5 and those listed as 2.5.x in the chart).
54 percent of the Joomla 2.5 websites checked contain known security vulnerabilities, as they are running versions below 2.5.15, the most recent release with security fixes.
For Joomla 3.x the results are slightly better as only 48 percent were detected running versions prior 3.2.1 or 3.2.2 (3.2.2 was release during the month alongside 2.5.18).
41 percent of the Joomla 3.x websites checked contain known security vulnerabilities, as they are running versions below 3.1.6, the most recent release with security fixes.
Outdated WordPress and MediaWiki Versions Heavily Used Too
The results for the WordPress and MediaWiki websites checked during February using our tools for those pieces software were also not good.
For WordPress, 60 percent of the websites checked were running a version below the current series, 3.8.
For MediaWiki, 47 percent of the websites checked were running a series no longer supported. The currently supported versions are 1.19.x, 1.21.x, and 1.22.x.
We are frequently hired to clean up websites that another company was previously hired to clean up but then has been hacked again (or wasn’t actually cleaned up in the first place). In some cases we wouldn’t lay the blame on the company, sometimes hacks are well hidden and getting them cleaned up can take more than one cleanup (which you shouldn’t be charge extra for) and in other cases there are security issues that the company doing the cleanup can’t handle. For example, if your web host has a security issues then they are going to only ones who can fix that. What we find in most instances though is that company doing the hack cleanup has not done the basic elements of the hack cleanup.
When someone contact us about cleaning up a website that was previously cleaned the first question we asked is if the first company determined how the website was hacked. Determining how the website was hacked is important part of the cleanup as if you don’t know how it was hacked you won’t know if the security issue that allowed the website has been fixed. Considering that the websites have been hacked again it isn’t surprising that the answer we hear over and over is that they didn’t. But isn’t just that they didn’t determine how the website got hacked, the companies didn’t even try to determine how the website was hacked. Either these companies are knowingly cutting corners or they don’t care enough about the service they providing to know what work they should be doing. In either case what they are doing is highly unethical.
We don’t ask our clients who they previously hired, but they do bring it up from time to time. During recent cleanup of a Joomla website the previous company was mentioned and when we went to their website we noticed that they were running an outdated version of Joomla. Keeping the software running on a website is a basic security measure, so any company that doesn’t bother to do that really shouldn’t have anything to do with the security of other people’s website. We took a look around at companies advertising to clean up Joomla websites and we found that all of the companies were running out of date software. As warning to the public and as a reminder of how bad the current state of companies providing security services is we have highlighted them below:
Dean Marshall Consultancy (http://www.deanmarshall.co.uk/)
Support for Joomla 1.5 ended in September 2012, so a websites shouldn’t be running it anymore (though many, including joomla.org, are still using it as we mentioned yesterday). As part of cleaning up a hacked website still running Joomla 1.5 you will eventually want to migrate it to a newer version, which doesn’t seem like a task for a company that still hasn’t done it for their own website.
Joomla Help Live (http://joomla.cmshelplive.com/)
Joomla 1.7 is over two years out of date and more importantly it has a serious security vulnerability that we have seen being exploited.