10 Tips to Prevent Your Joomla Website from Being Hacked

We recently discovered that a client’s website had some mysterious traffic spikes in their Google Analytics account. We quickly began investigating and realized that a hacker had somehow placed a bit of code in the site that created some unauthorized redirect URL’s within the site. These URL’s contained keyword-rich meta data which allowed these newly created redirect pages to get ranked high on Google for a few pharmaceutical-related keywords. When a user clicked on the result in Google they would hit our client’s site and then be automatically redirected to the pharmaceutical site. So, we went into detective mode and started to investigate the cause and devise a solution.

The Cause

A small block of code was inserted into one of the PHP files that was causing the URL redirects. Allegedly, there had been a vulnerability in some of the most recent versions of Joomla 1.5 that allowed hackers to gain access to the site via the lost password process. It’s pretty much a non-issue for sites running off of PHP 5.3. But, since our client’s webhost only recently upgraded to PHP 5.3 (and only after much griping from their many customers), that was mostly likely how the hacker got in. The hacker could have inserted this bit of code previously but only activated it now, even though the webhost is now running PHP 5.3 and the client’s site is running the latest version of Joomla 1.5.

The Clean-Up

To clean up the mess and ensure that the hacker no-longer had access, we took the following measures.

1. Joomla Updates: We updated all of the sites to Joomla 1.5.26. None of the Joomla 2.5 sites were affected and we think it was likely a vulnerability caused by a combination of some of the sites running versions less than 1.5.26 and the webhost running a PHP version less than 5.3. Apparently Joomla versions 1.5.25 and .26 are pretty moot if you’re running off of a server with PHP 5.3 as it has password recovery protection built into it.
2. Version Verification: We installed the Version Verification Tool component and checked every site for modifications to the Joomla core files. If any were found they were replaced with the real versions of those files.
3. Findhack: We uploaded a PHP file to the root folder of every site called “findhack.php”. This file searches your site for any files that contain “base64_decode”, which is the encrypted code that the hackers embed into index.php files. Any files that we found that had base64_decode encrypted code in them were cleaned or replaced. There are a lot of legitimate files that use base64_decode in them, but it’s pretty obvious when it’s a hack and when it’s not if you’ve worked with Joomla a lot.
4. User Cleanup: We removed all user accounts from all of the sites except for one Super Administrator account. We changed the username and password the Super Administrator account to something new and secure. All client’s we told we would create new accounts for them and their staff on an as-needed basis.
5. FTP Password: As an added precaution, we changed the FTP password for the webhost.
6. Unused Extensions: We removed all of the default Joomla templates from every site, and any other components or plug-ins that weren’t needed.
7. Clean Archive: We removed all of the “work in progress” sites, and archived sites on the client’s server.
8. Clean TMP Folder: We deleted the contents of the “tmp” folder on every site. In a lot of cases the hacker(s) had tucked away a file in either this directory, the /image/ directory, the /templates/ directory, or the /templates/your_template/ directory. A few times they had also created their own directory (which was pretty lazy and obvious on their part) called /drug/ or /goto/. Needless to say, any bad files/folders found were deleted.
9. CHMOD Sweep: Using Filezilla, we did a sweep on the affected site to make sure that the file permissions levels were set appropriately. We set all folders to 755 and all files to 644 (which are typical permission levels).
10. Backups: We have backups of all of our client’s sites with a tested recovery process. We use AkeebaBackup which is great because of how easy it is to use (and powerful) and how well it integrates with online storage solutions like Dropbox.

BONUS: If Google is showing a message in the search engine results page that says “This site may be compromised.”, you should follow Google’s Webmaster Tools Guidelines for Cleaning Your Site.

The Result

All told, this was little more than a nuisance for us and our client. And Google has already cleared the bad URL’s from its SERPs. But this could have been a lot worse. On the plus side, we’ve improved our security checks and development processes slightly to try and combat these sorts of illicit and unethical attacks. Unfortunately, most web owners don’t even know they have a problem until it’s too late. So, we hope this helps anyone else who has the same problem – or wants to avoid it ;-). And if you have a more serious problem than this, you can also look into reporting the hacker to the Internet Crime Complaint Center – www.ic3.gov.