Your Tech Tamer

For the second time in less than a year, I found myself spending time this week dealing with a website that was ‘hijacked’ by someone with less than honorable intentions – it had been ‘hacked’.  What does that mean?  Do you need to worry about it?  How do you fix it if it happens?  While I’m not an expert on web-security, I now have a bit of experience (albeit hard-earned through the remediation of the impacted sites) and I figured that I’d share some of what I’ve learned.

If you have any form on the web that allows users to enter information, then press a ‘submit’ button, your site is probably vulnerable.  Why?  Well apparently, people with evil minds can paste code into the entry fields (e.g. Name, Address, e-mail or other fields), then activate the code by pressing the ‘submit’ button.  Rather than sending you, the owner of the website, an e-mail saying that So-and-So wants more information on your business (or whatever the ‘submit’ button was supposed to do), the submit button launches script that was injected, and “other” things happen.  Those “other” things can be almost anything from a nuisance to a serious breach.  Last year, on my own website, when the hacker hit the ‘submit’ button, they replaced my ‘normal’ home page with one which said “Beware of Palestein”.  Seriously.  They replace my home page with an ‘alternate’ page.  There were images of flames, etc., but the key point was that my site had been hijacked by the Palestinians (or someone claiming to be working on their behalf).

While putting up my original home page again was a snap, the more severe problem created by the ‘evil’ script was that search engines who probe for ‘evil’ sites found the ‘malware’ on my site and shut it down.  SHUT IT DOWN!!  Once I had remediated the problem, I had to resubmit the site (via a process offered on Google) as a ‘good’ site, explain to them what had happened and the steps I had taken to prevent the problem from occurring in the future, and wait for it to be ‘cleared’.  As soon as they cleared it, the ‘good’ site came back online.

The entire process (from when I found the sites had been compromised to when it was back up live) took several days in one case, and over a week in the other).  Bottom line:  You don’t want your site to be vulnerable to such attacks because you can’t afford for your website to go down.  Your website is the ‘front door’ to your business.

So, how do you prevent this from happening to your site?  There are a few simple steps to follow which should help.  That said, remember that hackers are forever working to ‘beat the code’, so they’ll keep trying…you just want to make it more difficult than it’s worth, or to be able to catch the breach before it becomes a problem.  Here are my experience-based recommendations:

1.      Make sure that the passwords used to publish your website to the internet (commonly called ‘FTP passwords’) are STRONG passwords.  We all know what those are – letters AND numbers, upper AND lower case, AND special characters.

2.      If you have a form with a ‘submit’ button, ensure that the person who developed the site employs data validation during the ‘submit form’ process.  What the heck do you mean by that?  Simply put, if someone enters their phone number, make sure that the phone number contains only numbers.  Similarly, a zip code should contain only numbers.  A name field should NOT contain special characters (other than perhaps a comma, apostrophe or period).  Typically, special characters are required to run ‘evil scripts’ (aka ‘malware’).  Even more wide-open fields (like ‘Comments’ fields) should prevent characters such as <,>,|,~, etc.  Most ‘comments’ can be submitted without the use of such characters, but malicious code almost requires that they be included to be effective.

3.      If you have a database that resides under your website, use similar logic as described above – strong passwords, and data validation every time that information is being written to the database.

4.      Visit your own website often (at least once a week) and click around.  Seriously…if you don’t check it out, you might not know if there has been a breach.  A breach will be OBVIOUS (the site works or it doesn’t).  If you have a web-browser OTHER than Internet Explorer (e.g. Firefox or Safari) use the NON-IE browser to check on your website.  Why?  Because internet Explorer continues to display compromised websites far longer than Firefox or Safari do.

Someone who doesn’t know you and hits a ‘roadblock’ while trying to view your site won’t know how to contact you to tell you there is a problem.  I don’t know how long my site was down – it took a friend going online trying to find my e-mail address – to call me and say ‘Did you know…’.  I’m embarrassed to say that my site could have been compromised a month earlier – I probably wouldn’t have known.

5.      Make sure that your website has been formally submitted to Google via ‘Site Verification’.  If you have done this, then Google will communicate with you in the event that they find a web ‘emergency’ on your site.  Trust me, Google may well know before you do if your site was hacked!  In the event of a breach, Google will send you an e-mail telling you if it finds that your site has become infected with malware – letting you know ASAP that you have an issue.

Google sends an e-mail to ALL of the following addresses – make sure that you have ‘real’ people receiving at least a few of these (you don’t need them all, 1-3 will do):  abuse@mydomain.com, admin@mydomain.com, administrator@mydomain.com, contact@mydomain.com, info@mydomain.com, postmaster@mydomain.com, support@mydomain.com, or webmaster@mydomain.com.  If possible, have different people receive the different addresses.  That way, if someone is out of the office, or doesn’t have access to e-mail for a while, the notice won’t be ‘lost’.  Additionally, make sure that ‘noreply@google.com’ is set as a trusted sender (you don’t want that e-mail to get caught in your spam filter).

6.      I’m going to state the obvious, but sometimes the obvious needs to be stated – make sure that you have a pristine copy of your website on your LOCAL computer/server.  Keep it safe and secure.  Refresh it after you make changes to the web, but do NOT use it as your main ‘publication’ folder.  Yes, this means having two copies of your site – one that is a working copy that you edit/publish from.  The other is a ‘pristine’ copy.  After you’ve published changes, when everything is working well, refresh the ‘pristine’ copy from the working copy.  Having this ‘pristine’ copy will save you from accidentally overwriting ‘clean’ pages with ones infected with malware.  If it happens (and there are a myriad of ways that it could happen which I won’t try to go into here), you have only to recover the affected pages from the ‘pristine’ copy.

If you implement all these things, does it mean that your site is ‘bulletproof’?  Nope.  Not a chance.  The hackers are working hard to breach the web wherever they can.  They find new ways every day.  Don’t get wound too tightly on the issue, but use common sense, to try to thwart the ‘bad guys’.  Remember, they’re likely to head to the easier sites to hack – they’re probably not going to invest extra effort trying to get around the roadblocks you’ve put up.  They’re going to go to a site that didn’t take the precautions that you took.  What’s the old adage – the thief is going to steal the car with the keys in it before they try to hot-wire a car.  Don’t leave the ‘keys’ in your website!

Finally, one of the first questions that I asked was ‘Why on earth would they care about SLC Consulting’?  It’s precisely BECAUSE it isn’t a ‘mainstream’ site that they chose it.  From my innocuous site (and the other one that I had to remediate this week fits that same description), the hackers could ‘jump off’ and go far and wide doing ‘bad’.  Then, those ‘bad things’ could, potentially, be traced back to the original site that was hacked.  It really is far easier to ‘take the keys’ and ‘lock the doors’ on the site beforehand.  While It is not a guarantee, it is hopefully, a deterrent.