Support

Documentation

Unhacking Your Site

Nicholas K. Dionysopoulos

AkeebaBackup.com

May 2011


Introduction

So, the unthinkable just happened: your site got hacked. What should you do to unhack it and how can you make sure you will stop being hacked?

Emergency measures

Once your site gets hacked, it's safe to assume that everything on it is compromised and that the hacker can continue to access it at will. The first thing to do is to get your site into emergency off-line mode. Do not trust Joomla!'s off-line mode, it's not designed to guarantee that your site will not keep on getting hacked by, e.g. a blind SQL injection attack or an attack targetting an ad-hoc entry point PHP file.

Then proceed to immediately change your Super Administrator, database, FTP password and hosting account's passwords. If an attacker got through, these passwords should be considered compromised. Remember to edit your configuration.php value and update it with the new database password.

When you're done working on your site, do not forget to remove the emergency off-line mode from your site!

Identifying the hack

You should always identify the source of the attack. This will tell you a lot about what just happened to your site and help you defend against similar attacks in the future. Download your Apache access log files to your local PC. It's not necessary to download the whole lot, just the records for the last X days, where X is the number of days since you know that your site was definitely not hacked. Use a “grep” program, like WinGrep, to search for potential hacking entry points.

What to search? Look for “insert”, “update” and “replace” as these signify a SQL injection attack. If it looks like a SQL command (possibly with comments like /**/ all over the place) it's most likely a SQL injection attack. Look for accesses to your administrator/index.php file which came from an IP other than yours, as these signify a brute force password cracking attempt or an unauthorized login to your site's back-end. Also look for access to PHP files except index*.php in your site's root and administrator directories.

If you run into something which looks like a SQL injection attack, take a look at the component's name (if it occurs in a URL with index.php in it). That's a potentially vulnerable component. Check if the component is listed in the Vulnerable Extension List and, if so, make sure you have a newer version than the affected one. All developers had a vulnerability at some point and released an update to “plug the holes”.

If you have requests to a stray PHP file, check with the developer of the component it's stored in that the file is indeed required for correct operation of the component – or look at the component's installation ZIP file and make sure that the file exists in there. If the file should not be there, it's a malicious script placed in there by the hacker and must be removed at once.

If you see repeated requests to the same PHP file (other than Joomla!'s index*.php files), this is a warning sign that something's wrong. If the file is placed in an awkward directory like tmp or cache, examine its contents. If it's just CSS, there's nothing to worry about. If you see a lot of complicated code, it's a hacking tool and must be removed.

Using this tedious, time-consuming process you know how you got hacked and if the hacker left “back door” hacking scripts behind and remove them. If you skip this step, you can bet that your site will be hacked again in no time.

Do you have an infected site? Fix it!

Some hackers modify core Joomla! Files. This is more tricky, as you don't get to see the results of the hack immediately and it's hard to know what was affected.

If you have a last known good backup of your site (from a point in time you can bet your life that the site wasn't hacked), you can use Akeeba SiteDiff to compare the last known good backup with a fresh backup you take from the hacked site. You can also use any other file comparison method. Take a look at the modified and added files. If you see PHP files in that list, start worrying. These files might be hacked. If you do not have a last known good backup or can not use SiteDiff for any reason, please proceed with all of the following steps regardless.

If you have modified files, it's easy to fix them. For core Joomla! files, simply download a fresh full installation Joomla! ZIP package and extract it on your local hard disk. Remove the installation directory and upload the rest of the files to your site, overwriting all (I mean ALL) existing ones. It will take a while.

For extensions with modified files, simply reinstall the latest version of each component, module, plugin and template you have. If you have modified some files yourself (e.g. template CSS files) make sure you have backup copies of those files before following the above procedure so that you can redo your changes after reinstalling the latest versions. Once you go through the pain of this process you will realize why all developers argue against modifying files.

If you have PHP files added since your last known backup, take a look at their contents. As said above, if you see any strange code it's most likely a hack file. Check that the file doesn't exist in the original extension's installation package and remove it from your site. Hey, if you delete a file which you shouldn't you can always restore it from a backup. You do keep regular backups of your site, don't you?

If you do have a last known good backup from not a long ago...

...then the above can mostly be avoided. Do note that the following procedure will lose all your site's modified or added data since your last known good backup. Start by removing everything from your site, i.e. all files, directories and database tables. Then, restore your backup.

If you are experienced enough, you can try merging back modified data from a locally extracted backup of the hacked site to the now-being-unhacked site. This process is well outside the scope of this walkthrough but let it be said that it involves manually moving non-PHP files and carefully examining database contents.

I hope that by reading this you realize why having frequent, tested backups is of paramount importance to your sanity. How frequent? Well, let me reverse the question. How much data are you willing to lose if your site crashes or gets hacked? That's how frequent you should backup. On most sites it ranges from a few hours to a couple of days, on sites being infrequently updated that may be a week or a month. One size does not fit all.

Make sure you won't get hacked again

First, I'd like to say that the above statement is a blatant lie. Nobody can guarantee that a site is unhackable. Anyone who says otherwise or implies that you should do this and that and never worry about your site's security ever again is a dangerous liar and should be tarred, feathered and stringed in the old-fashioned way. Let it be made clear that security is a process and all it can achieve is to make your site a little harder, but not impossible, to hack. If a professional hacker gets your site on his sights, you're pretty much doomed – but, then again, these guys go for big bucks so, unless you're a bank or a government, I wouldn't worry that much if I were you.

Anyway, let's make sure that at least you won't be getting hacked all over again, the same way you got hacked in the first palce. After having followed the above procedures for unhacking your site, let the updates begin, starting with Joomla! Itself. Are you running the latest version of Joomla! or are you a sitting duck? Check http://joomla.org for the latest version and update instructions, or use Admin Tools Core to do both an update check and the update itself in a single click.

Make a list of all components, modules, plugins and templates installed in your site. Visit the respective vendors' sites and download the latest releases. Install them on your site. Extra special note: templates are software, not just a bunch of graphics. Template developers do release security upgrades all the time. Make sure you install them. I've seen many sites getting hacked because of a dated template with a SQL injection or XSS vulnerability. Most people forget to update their templates – and I used to be one of them, until a few years ago.

After updating everything, let's take a look at your site's users. If there any Super Administrators that shouldn't be there, block them, change their passwords to something random and their email address to something invalid (so that it's impossible to reset their passwords). In that case, also check for content modified or created by those users and audit it carefully. Hackers enjoy messing with your site's content.

than a password consisting of five not very common words. For example “cougar waives his fluffy tail” is more secure than “ahY5*k9u@d”. Which one is more likely to remember without having to jot it down anywhere? Yes, the easy to remember one, consisting of plain English words, is indeed the most secure one!

Once you do all of those, make sure you're taking daily backups. Akeeba Backup Core can help you with that. It even comes with scheduling support for your convenience. Stay alert. If your site get hacked again, you have a backup to restore from and you can narrow down your Apache log search in a day's worth of log files – hence easy to figure out what went wrong and how to resolve the issue.

If you're extra paranoid about security (getting a site hacked has that effect on your) I strongly recommend taking a look and implementing my Master .htaccess file. It does get a while to get it configured properly, but it's worth it. For the extra paranoid amongst you, you may want to also take a look at Admin Tools Professional. It can further enhance the security of your site by applying a lot of input filtering for things such as Cross Site Scripting, SQL Injection, Local File Inclusion, Remote File Injection and much more. Please note that it will only protect your Joomla! Site from attacks coming through Joomla!'s index*.php files. If you're using a third party extension with ad-hoc entry points (PHP files meant to be called directly over the web, such as VirtueMart's PHP files) all bets are off. Nothing will get between them and the Internet – which is one of the reasons why I proclaim that not going through Joomla!'s index*.php files is a Terribly Bad Idea™ anyway.