Recovering from a Hacked Website — Part 1

Recovering from a Hacked Website

Part I, Defending your Site

About 18 months ago my website was hacked quite badly and this series of articles is about how I recovered (or am recovering from that) with a few insights and tips along the way as to how you can avoid what happened to me in the first place.

I've been on the web since about 2003 and in 2004 I began my site, Celtnet (http://www.celtnet.org.uk). About a year later I started a new section on the site, Celtnet Recipes (http://www.celtnet.org.uk/recipes/). Initially I added a bunch of Welsh Recipes there to go with the various Welsh Legends and lists of Celtic gods I was adding to the main section of my site.

The site was growing and it needed to be more dynamic, so I move over to PHP on top of a MySQL database as my content delivery platform and added a forum as well as an article directory.

Over the years the recipe section grew, initially just with those recipes that I found interesting. Then I started on a personal project to add to the site recipes from each and every country in Europe and then recipes from each and every country in Africa. All the time I was also adding traditional and British recipes.

By 2010 the British and African recipe sections had grown into some of the largest on the web and I was getting lots and lots of visitors. This was converting into quite a decent income.

Neo from the Matrix stopping bullets. How to make your
website bullet (and hacker) proof.

However, though I was expanding the site and updating the code quite often, it was still really only a hobby site for me. I had begun some limited SEO and was working on the in-bound links to my site, but nothing serious.

Then, in 2011 things went a bit awry in my life and I lost interest in pretty much everything. The site was left on tick over and in 2012 it was hacked through a vulnerability in the forum system phpBB. My rankings in Google began to tumble and it was not really until February 2013 that I began to take notice.

By that time things had gone very wrong indeed. All the most popular sections of the site had been compromised and I was nowhere to be seen in the searches that I had previously been most popular for.

Some things were historic, I had cleaned out the bad code, but the Google spiders had stopped coming and I had pharmaceutical and adult spam all over the place (where the header to files are compromised and Google spiders or google referrals see different content to what someone coming directly to the site sees).

As I say, I had been running my site as a hobby site, so I quickly had to learn how to harden my site and in the process I decided to give my site an overhaul to improve my SEO and to get more links.

The first thing was to go over all the code with a fine-tooth comb and to remove some of the riskier JavaScrips I was running. This meant that two of my advertisers had to go as they relied on public domain code that was just too easily compromised (this had been responsible for some of the exploits — redirects to spam sites).

Next I found that some of my SQL query code had not really been optimized. The main database had grown so big that queries were failing, so I went through all my SQL and optimized everything. That got the site back up and running again at optimal speed and queries were running once more.

But to reduce the load on the server overall I decided to cache my pages, also in the hope of making page queries faster.

But this exposed another vulnerability. As the site runs on PHP potential SQL inject vulnerabilities and insertion of malicious code into the cache became a possibility.

So, every page that required a variable from a get or post statement had 'htmlentities' wrapped around the variable to prevent malicious code being inserted.

for example, say I require a variable timeStamp to be passed to the script.

my original code would define this as:

$timeStamp = $_GET['ts'];

but the new header code defined:

$timeStamp = (htmlentities($_GET['ts']));

so that every malicious character like '#', '%', etc is encoded as an HTML entity.

Next I put checks around every variable, to ensure that they were valid. So, if I expected a variable to be numeric only I checked for that, or if it had a specific format I checked for that too.

The most pain was with searches, of course. But there I made a list of all potentially malicious characters and common malicious code strings and I stripped those from any user input before performing any searches or caching any pages.

Next I deployed BadBehavior throughout my site. This stopped the majority of known malicious bots from even getting to see any of my pages and malicious attacks dropped considerably (server load also dropped as a result so it was a win-win).

Now I checked permissions on all my directories and upgraded or changed them then I updated all third-party software to the latest versions and if there were problems with any of them I changed over to something else.

With the site suitably protected and hardened, the next step was to undo some of the damage done to the overall SEO.

I will detail those steps in the next article...