Joomla

Transferring Joomla to a New Web Hosting Account

If you need to transfer a Joomla website to a new hosting account, either at a new web host or another account at the same web host, the process usually isn’t too hard. But there are things that can go wrong, so below we go through the important things to do as you are working to accomplish that in way that leads to a smooth transfer.

Test Before You Switch

When doing a transfer like this, the best advice is to do a test of the transfer before you make the final switch over. That way, if any problems come up, you can work on resolving them without having to rush the process.

Transfer the Files

You will need to transfer the files from the old hosting account to the new one. That is usually most easily done using FTP or SFTP to copy the files from the old hosting account to a computer and then copying them from there to the new hosting. That also provides you with a backup of the files.

Transfer the Database

You will need to copy the database from the old hosting account to the new hosting. That is usually done through phpMyAdmin, to export a copy of the database from the old hosting account, and using it to import that copy of the database to a database on the new hosting. Though there may be other options depending on the hosting setup. You will need to create a database on the new server to import the existing database.

Update The Configuration File

Once you have copied the files and the database, you will need to update the Joomla configuration file, /configuration.php, in the new hosting to have the credentials for the new database and the new file system location.

Plan for a Switch Over

After you have tested out everything and confirmed that it works, plan for a time to switch over to the new hosting. You will need to allocate time for recopying the database and if the files have changed, the files as well. You also need to allocate for the time it will take for the website’s domain name to point to the new web hosting.

You will also want to make sure that access at the old hosting is blocked, so no more changes are being made once you start the final transfer process.

Redo The Transfer and Point The Website’s Domain to New Hosting

Once you have made a final transfer of the database and possibly the files, you need to update the records for the website’s domain name to point to the new server.

Getting Help

If you need help with Joomla, we offer support and we offer a service specifically to handle transfers like this.

Joomla 3 Doesn’t Contain Unfixed Critical Remote Code Execution Vulnerability

Last week, the developers of Joomla released fixes for a number of vulnerabilities that have existed in the software. As is often the case, journalists (or at least people claiming to be journalists) and security researchers made overstated claims about those. Those claims included that the vulnerabilities were critical in nature and that one of them leads to remote code execution (RCE). Neither of those things is true.

With the claim of a RCE vulnerability, which would be serious, the reality is that this involved a reflected cross-site scripting (XSS) vulnerability that Joomla rated as of moderate severity. That is a type of vulnerability that causes malicious JavaScript code to be output if access a specially crafted URL. And is a type of vulnerability that you don’t see exploit attempts on any large-scale basis. It isn’t a big concern, which might explain why you have journalists and security researchers often hyping up the worst-case scenario with it and not clearly noting the lack of real risk.

That vulnerability also actually involves an issue with PHP, which has been addressed, but only in supported versions of PHP. Joomla’s update addresses it for those running unsupported versions of PHP.

This vulnerability and the others being fixed exist in Joomla 3. Support for Joomla 3 ended in August of last year, meaning that there isn’t generally available official update for those running Joomla 3. There are several options for getting security fixes for it, but you would be better off upgrading to a supported version as soon as possible. That is something that we can help you with.

Sample Data Included with Joomla Templates from Template Monster Lead to Website Being Hacked

When it comes to cleaning up hacked websites one of the three basic pieces of doing a proper cleanup is trying to determine how the website was hacked. Without doing that you leave open the possibility that the vulnerability still exists and can be exploited again. Not surprisingly then when people come to us re-clean a hacked website after another company has done that and the website got hacked again there has almost never was an attempt to determine how the website was hacked during the previous cleanup.

Another reason for trying to determine how the website was hacked is so that you can possibly prevent other websites from being hacked through the same vulnerability. We say possibly, because as a hack we recently traced back to a template from Template Monster, trying to work with the party responsible for the vulnerability may not get you anywhere.

Before we get to the vulnerability let’s do a quick walk through how we came to find out it had been exploited.

We were recently brought in to clean up hacked Joomla website where the person already dealing with it was removing malicious code from .htaccess files and the index.php files of the installed template, but it kept returning. In situation like that our first step is to review any available log files to see what they show about how the hacker is making the changes. In this case we found suspect requests being sent to a file in the /modules/ directory.

That file was highly obfuscated and due to that, it was fairly obvious that it was malicious without needing to deobfuscate it. What was more important at the moment was figuring out how it got on the website. In looking over the other files in the directory it was pretty clear that the whole directory it was in was not legitimate and had been created by installing an intentionally malicious extension. One of the items that pointed to that was the manifest file for the extension:

<?xml version="1.0" encoding="utf-8"?><install version="1.5" type="module"><?xml version="1.0" encoding="utf-8"?><install version="1.5" type="module">
 <name>System</name>
 <author>Joomla</author>
 <creationDate>08 Jan 2010</creationDate>
 <copyright>Copyright (C)  Profexor Liberty</copyright>
 <license>http://www.gnu.org/copyleft/gpl.html GNU/GPL</license>
 <authorEmail>profexor@hell.com</authorEmail>
 <authorUrl>http://profexor.hell/</authorUrl>
 <version>1.0.0</version>
 <description>ͮ崫��殨��鲯ﲲ橼/description>
 <files>
 <filename module="mod-favicon-image">mod-favicon-image.php</filename>
        <filename module="mod-favicon-image">mod-favicon-image.xml</filename>
 </files>
    <params description="this module has no parameteres" >
    </params>
</install>

The installation of a malicious extension would most likely be done through a hacker’s access to a Joomla admin account. So we then reviewed the database table that stores user accounts and found there were numerous accounts that didn’t look legitimate. Only one of those was recorded as having been used to log in to the website recently.

For that account the email address was “demo@demoolink.org”. We then did a Google search on that address and found a thread on the Joomla Forum where someone had a template that was trying to create exactly the same user using a SQL statement. By exactly the same, the registration time specified for both was exactly the same, down to the second.

What didn’t make much sense to us is why a template would be trying to create a user. Considering that the template in use on the website we were cleaning was a commercial template from Template Monster, we first thought the explanation might be that it had been obtained from a warez website and the template was modified to allow website installing it to be exploited.

When we reviewed the installer file for the template though we found that there was no code to create the user. At that point we thought we had hit a dead end, but after doing some more investigating we found more evidence to connect the account to the template. After that we got access to another file that had come from Template Monster. This file was named fullpackage.zip and in addition to the template, it included a copy of Joomla and a sample data file created by Template Monster. When installing Joomla you have the option to install various sample data files, so when using this file to set up Joomla you could install the sample data provided by Template Monster

In that sample data file was the following SQL statement that created the user:

INSERT INTO `#__users` (`id`, `name`, `username`, `email`, `password`, `block`, `sendEmail`, `registerDate`, `lastvisitDate`, `activation`, `params`, `lastResetTime`, `resetCount`) VALUES
(846, 'Demo User', 'demo', 'demo@demoolink.org', 'ad358a48fb2891854aa8b547c7b151be:jGftU2FbdRXUNikAQrKKeAQl9Is104QE', 0, 0, '2012-10-17 10:56:12', '0000-00-00 00:00:00', '', '{"admin_style":"","admin_language":"","language":"","editor":"none","helpsite":"","timezone":""}', '0000-00-00 00:00:00', 0);

INSERT INTO `#__user_usergroup_map` (`user_id`, `group_id`) VALUES
(846, 8);

Any website that installed that sample data would have a Super User (the highest level user in Joomla) with the same username/password combo. Unless one of those was changed then someone that could figure out the password could log in to the websites where this sample data has been installed. At that point it looked to us that the user might have been installed across multiple Template Monster templates.

At that point we also contacted Template Monster informed them of the issue and suggested that they notify anyone that had purchased the impacted templates about the potential issue. We also suggested that they register the domain name demoolink.org seeing as that isn’t registered and someone could register and use it to gain access to the impacted website without even knowing the password (by resetting the password).

The first response we received was as follows:

Thank you for reaching the Technical Department of Template-Help.com!

Take our apologies for the delayed reply.

We are sorry for inconvenience caused by this. Usually clients change demo email address. We are happy that you managed to resolve it yourself.

Let us know if you are having any other issues with the template.

We responded trying to explain the issue wasn’t just related to the email address and we received the following response:

Take our apologies for the delayed reply.

demo@demoolink.org is added in admin panel as example of demo link, you can easily change it. Please specify with some screenshot what issue exactly you are having so we will be able to check it for you.

At this point we asked if there was a security department we would be transferred to we received the following response:

We appreciate the information you’ve provided. We will forward it to our development department. They will check it more carefully.

Thank you. Have a nice weekend.

While we waited for another response (none has come in two weeks) we wondered if the password might be something really easy to guess. It turned out that we didn’t need to guess it, as we entered the password hash, “ad358a48fb2891854aa8b547c7b151be:jGftU2FbdRXUNikAQrKKeAQl9Is104QE” in to Google and on got this page as one of the results. From that we then knew that the password was “demo123”. Not only is that not strong password, but with that in hand we found a page on the Template Monster website that told everyone what the username and password was for website using this sample data:

Right below that is a message that indicates that they were aware of there being a risk from providing this user account:

You can delete sample user though the Joomla administration panel in the “Users > Users Manager”. In case you are planning to use sample data we recommend you to change Sample Author user login and password.

We still don’t understand what the purpose of creating a sample Super User like this, since another one is created when installing Joomla.

Joomla 3.7 is Not Hack-Proof

When it comes to bad information on the security of websites, far too often that information is coming from companies offering security services. A recent example we came across, while dealing with a hacked website, involved a Joomla focused web development company that in their marketing their service for upgrading or migrating to Joomla 3.7 claimed that Joomla 3.7 is “hack-proof”:

That certainly isn’t a claim that is made by Joomla (nor would you expect it to be a claim that is likely ever made by someone trying to be taken seriously).

Already a “high” priority SQL injection has been fixed since 3.7.0 was released, which was considered serious enough for Joomla to pre-announce that a security update was coming.

The same company offers to clean up hacked Joomla websites, so they should know better than to make that sort of claim and in fact they seem to understand that vulnerabilities continue to be found in Joomla based part of how they advertise that service:

We will identify possible loop hole in security and install required updates and patches. Because of consent Joomla and component upgrades, this is a critical step to prevent hacking.

In describing their service there was also this troubling claim:

As soon as we are engaged to fix your hacking issues or to prevent your website from hacking, we will do a thorough analysis and prepare an action plan to recover your website at the earliest. Mostly a Joomla upgrade should fix it, but it depends on the kind of website and problem you have.

We deal with lots of hacked Joomla websites and upgrading would not normally fix them. Perpetuating that idea is decidedly not helpful, as if our experience is any indication people with hacked website will often come to that conclusion and then hire someone to upgrade it without mentioning that they are doing that to clean up hack. Trying to upgrade a hacked website could actually make the situation worse, as it might cause the upgrade to go wrong and it could erase important evidence needed to determine how the website hacked, which may be needed to prevent it from being hacked again.

Update For Critical Security Issue in Joomla Being Released Tomorrow Morning

Joomla has announced that an update to fix a critical security issue is going to be released tomorrow morning, 8am MDT. They haven’t released any details on the issue, but have said that “Since this is a very important security fix, please be prepared to update your Joomla! installations next Tuesday.”. That sounds like good advice to us.

Joomla Firewalls Are Not a Replacement For Properly Cleaning Up a Hacked Website

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”:

The warning referred to another website, so they were not sure if it was due to their website being hacked or if maybe the other website was hosted on the same server and being on the same server was causing the warning. The reason the warning mentioned another website was that it was a cross-site warning, which is shown when content is loaded from another website that is being flagged by Google for malware. In this case it was caused by the following malicious JavaScript code that was being included on the website’s pages:

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.

The JavaScript code shown before was easy to find because it stored in the index.php of the various templates on the website, without any obfuscation.

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.

What looked to be the cause of the malicious JavaScript code being added to the template files was a POST request to the file /libraries/fof/integration/joomla/general24.php. While that directory is one for core Joomla files, that file isn’t. Instead it was file a hacker had placed on the website at some point before, based on the last modified date it would appear it was placed there three months before. The logging doesn’t go back that far so we were unable to see how that file had been added to the website.

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.

Joomla Hack Cleanup Provider Still Using Joomla Version EOL’d Over Four and Half Years Ago

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:

“Very Important Security Fix” Coming For Joomla On Thursday

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.

InMotion Hosting Prominently Promoting Installation of EOL’d Joomla Version

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:

inmotion-hosting-cpanel-joomla-25

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:

inmotion-hosting-joomla-25-installation-page

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:

inmotion-hosting-moodle-20-installation-page

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.

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:

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.

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.