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
- Sucuri Makes A Persuasive Case That You Should Avoid Using Their Services
- SiteLock Promotes The Idea That Protecting Websites Involves Leaving Them Vulnerable to Being Hacked
- HostGator Is Actively Hiding the True Nature of Their Partnership With SiteLock
- Cyber Security Company’s Poor Website Security Reminder of Industry’s Lack of Focus On Actually Improving Security
- ZDNet’s Zero Day Blog Doesn’t Understand What A Zero-Day Vulnerability Is
Web Software Updates
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
When it comes to the security of websites what we often see is that a lot of focus is add-on security products instead of focusing on doing the basics. The reality is doing the basics is going to do a lot more to protect you than any security products. As an example, over at our Plugin Vulnerabilities service we recently tested 11 WordPress security plugin against a very exploitable vulnerability in a plugin and found that only 2 of the plugins provided any protection and for those two we easily found a way to bypass them. By comparison, simply updating the plugin after the vulnerability was fixed would protect you from the vulnerability.
This type of wisdom recently came up in the context of a hacked Joomla website we brought in to clean up. We were originally contacted by someone involved with the website about the following warning they were receiving on the website from Chrome warning that “The site ahead contains malware”:
We explained them what was going on (if you have a question related to a possible hacked website we are always available for free consultation to discuss it) and then we were brought in to clean up the website.
One of the next steps in the cleanup was determining how the code got on the website. While determining how a website is hacked is one of three important pieces of a proper hack cleanup, many, maybe most, companies doing hack cleanups don’t do this. Not to surprisingly the website where that doesn’t happen often get hacked again, and we are often brought in at that point to re-clean it.
That was not the only malicious file on the website. One of the easiest to spot was one in the root directory of the installation, due to the filename, ee79bb.php, not being something you would expect to see there. There were also several malicious files that had been renamed so that could be executed. At that point we found out that website had been hacked before, but it not been cleaned in a professional manner before.
Firewall Extensions Didn’t Stop The Hacking
While the website had not been fully cleaned before, two firewalls had been added, RSFirewall! and the firewall that is part of Admin Tools. Neither of those protected against the request sent to the general24.php file or based on their logging look to have had any impact as a number of other malicious look to have been added on the website over a period of months. That isn’t necessarily their fault, as once a hacker has some access it is much harder to detect that the requests are malicious in nature, but it is a reminder that security add-ons are not a replacement for proper security practices.
It is worth noting that with both RSFirewall! and the firewall that is part of Admin Tools, bold claims are made to their security capability with being backed up by and evidence. For RSFirewall! is describe thusly:
RSFirewall! is the most advanced Joomla! security service that you can use to protect your Joomla! website from intrusions and hacker attacks. RSFirewall! is backed up by a team of experts that are trained to be always up to date with the latest known vulnerabilities and security updates.
Nowhere is there anything that actually backs up those claims. Also troubling is the fact that it boasts protection against brute force attacks, despite those not actually happening.
Admin Tools firewall is describe in somewhat less bold way:
Our Web Application Firewall protects your site against the vast majority of common attacks. You won’t find any security tool more feature-complete than this.
But again, nowhere is there anything that actually backs up those claims.
We often say that most security companies don’t know and or care much about security, as quick example let’s take a look at a company named CMSHelplive.com that advertises to clean up hacked Joomla website on Google. Considering that keeping the software up to date is a basic element of security and when doing a proper hack cleanup you should make sure the website is secure as possible (so the software on the website should be brought up to date) you would expect that their website is running an update to version of their CMS. But it isn’t:
Joomla 1.7 reached it end of life back in February of 2012. So this company has not updated their software in over four and half years and have missed over 30 subsequent updates that included security fixes. When they are not even keeping their website secure, what are the chances that they are going make sure the website they cleaned up are actually secured after their work?
And of course they are also peddling the falsehood that brute force attacks against WordPress admin passwords are happening:
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.