Last week I discussed how important it is to take security seriously from the very start of your website project. Once you have set out what you want your website to achieve, built the site and reviewed your code for basic well known flaws it’s time to consider how you will manage the website.

I regularly see a situation where a website has been built and put online only for a virus infection or defacement to hit it within days of going live. Without a proper and complete backup strategy this can be very costly indeed. So the very first building block of your security governance has to be the creation of a backup strategy.

If your website is part of a shared hosting plan (where you have no control of the server on which your site resides)  then by all means apply the standard backup service provided by the hosting company. Do not see the backup service as optional – when you need a website restored a penny saved can be pounds lost if you hit a snag.

If you have a Virtual Private Server (VPS)  – ie a server hosting only YOUR website(s) and which you control in full – you will most likely will still have an option to use the hosting companies backup solution.

I’ll discuss the merits of shared hosts versus a Virtual Private Server (VPS) in a later post but I will stress here that regardless of the type of hosting plan you have regular FULL backups ofyour site and database are THE most important part of your security assurance.

You should backup before and after any changes to code or templates of the site. And regardless of changes make a full backup each week. Be sure to keep clean backups for several months.

Since I started getting my hands dirty with iframe and gumblar infected websites I’ve begun to notice some subtle changes that have led to another wave of attacks to hit the websites I’m supporting at the moment.

Initially sites were injected with a variety of iframed domain redirects that were simple enough to tackle with regex searches. The construct of the iframe code was also pretty standard so for example setting your search tool of choice (sed, grep, awk etc on *nix – wingrep on Windows) to search for the  following string:

You’ll see that the key element is that this is a hidden iframe – there’s no good reason to hide an iframe on your site! This would find the majority of injected frame code – at least on my affected servers.

Of course a little bit of generalised searching was neccessary, but by and large a few scripts using that regex code would have done the trick.

A few weeks on and I’ve been hit again – the route to infection is yet again a badly secured PC or laptop. I set to the clean up using my tried and trusted regex searches but my complacency in keeping them up to date was exposed… some simple and subtle changes by the coders renedered my searches useless. – Back to square 1!

I thought that I might share the lesson with you all:

1. A hacked site will always be a target – continued vigilence is essential!
2. Regex searches need to be as agile and flexible as possible (without searching out valid code)
3. You’re only as good as your last  bit of coding!

This is the regex I have used for the current crop of site cleanups I have completed. You’ll see that the code hides the iframe by setting the borders and size to 0.

This is just a bit of a hint – finding code effectively and quickly is important, but preventing a hack/infection is far prefferable!

Over the past several months there has been wave after wave of variants of the Gumblar, Martuz and other types of iframe attacks that seem to be related. Each wave seems worse than the one before. Naturally most efforts have involved cleaning websites and attempting to prevent re-infections.  The scripts and tools now available are extremely effective in putting out the fires and are only improving with time – have a look at the side bar for links to my favourite ones .

As the various domains involved with propagating payload get blacklisted or shut down the immediate effect of the infections will begin to diminish – at least until the next wave appears. If you have a handle on cleaning out your code, and have developed a routine of backing up , monitoring and re-installing infected pages you are , like me,  just about ready to move onto a bit of problem solving instead of firefighting

Given that the method of infection is from infected PCs we need to be sure we are not infected ourselves – the trouble is that even after all of these months there remains some mystification as to how the infection is being spread in the first place. That being said – there are some steps you can take to check if you’re machine is affected. The first and most basic is to check the SHA1 number of a file located in C:\Windows\System32\.  This may sound like mumbo jumbo but it is in fact a very easy check to do.

Step 1 – download and install the free application filealyzer (this is a handy tool for analyzing files)

Step 2 – Navigate to the sqlodbc.chm file in  C:\Windows\System32\ using windows explorer

Step 3. Right click on the file and choose “Analyze with filealyzer 2”

Step 4 Have a look at your file information  – We’re looking for the SHA1 number and the file size

Step 5 – Copy the SHA1 number (you know how to do this right? Left click and highlight then right click and copy)

Step 6 – Go to the nice people at Scansafe.com where they have very kindly listed the NON-INFECTED SHA1 numbers

Step 7 – Check you’re number against the list – I use the find function in firefox – just paste in the SHA1 number we copied in Step 5 above

Step 8 – PHEW! I seem to be clear of the infection – and check out the file size – all good!

So – if you did all of the above and your SHA1 number and/or file size don’t match what next? The best advice at the moment is, unfortunately, a complete rebuild of your PC. The reason for this is the conflicting advice/evidence of how the infection is being spread. Adobe PDF and flash files seem to be one method of infection and you should be sure to upgrade to the latest version of each – but my advice if you suspect an infection on one of your PCs is to completely rebuild. I will get onto some advice on how to use live CDs and/or virtual machines for your website management in a later post.