Woody Hayday

10 days of perpetual issues with hackers. 10 DAYS. 100+ sites bombed randomly between every 5 minutes and 5 hours and that’s only after proper detection, who knows how far it had gone before. But from the relentless irritation some positives developed, if you are in the (precarious) position of hosting LOTS of websites on a shared hosting account or you run a shared hosting service then read on, the value of maintaining limit pushing amounts of sites on a single account really should be considered – if the loss of earnings for all the hacker downtime doesn’t wipe out the savings then the cost of repair, security hole identification and eradication probably will, not to mention the loss of face to the search engines.

Website hacker entrance vectors (have any security holes?)

Common CMS, E-Commerce systems and forums (out of date or zero day, they all have or have had vulnerabilities) – WordPress, Drupal, OSCommerce, Gallery, PHPBB, VBulletin etc. etc. Particularly relevant here are the open source systems, but they are all susceptible – how many of these do you have installed where? For me these could of been answered with “a lot” and “some places”, clarity has now been restored but more on that later.

CMS Plugins (^^) – Often overlooked (especially by me), installed plugins can in themselves be entry vectors, often CMS’s push their communities to develop additional functionality for their system, which is a good thing, however if the system itself doesn’t deal particularly well with the security of folder structures or indeed how plugins are accessed they can offer ways in. Be careful with plugins which deal with file management and code execution (e.g. file attachers/uploaders etc.) Try to use late version highly rated plugins from reputable sources, with things like WordPress, plugins are low risk though as it has an excellent security model.

Bespoke server-side code and CMS’s – in my experience these is often LESS likely to get hacked, firstly “hackers” in this case are more likely to be script kiddies sitting in web cafes in some of the poorer world nations, they often use known exploits on common systems rather than trawl the web, searching for one off programmer mistakes. If you are behind the bespoke stuff leave out as many foot prints as possible and triple check everything. For bespoke stuff the most likely point of entry is simple SQL Injection, use SQL parameters.

FTP/WebDav – This really comes down to passwords as next indicated.

Passwords – Acquired by trojans or traffic sniffers, it becomes irrelevant what security you have in place across the whole setup if you don’t look after them properly. Avoid connecting to anything unencrypted (or at all if possible) on any network you don’t 100% trust, WIFI and wired, even if it’s a friends they could have a network sniffing Trojan on an idle machine. Install good anti-virus and protection software. Use Avast (free for private use) and Spybot Search and Destroy (these two are plenty.) Be careful with providing access to other users, whether it FTP, CMS, SSH, whatever – you may trust them but do you trust their computers?

Detection and Fixing – Realising you’ve been hit and fixing it

So after they gain entry, what would a hacker really do? Often with web hacking the motivation is kudos, money or sabotage – all are achieved through defacing, deleting or modifying web pages/logic and/or altering/downloading databases. A nightmare from the point of view of shared hosting users.

Depending on how they gain entry a hacker (or their automated executing code) may search through all of the files they can access, through ftp or server-side scripts, built to identify possible files to manipulate. They may download copies of things (e.g. databases!) but will likely set about cycling through all available webpage files and doing things such as:

• Inserting code within the page (iframes to bad websites, links to their websites – designed to improve their search engine rankings, redirect code which just shuttles people on to their sites)
• Replacing the file with a predesigned page (kudos fronts ‘this website was hacked by…’)
• Replacing common server-side functions and variables (e.g. replacing all the send values on email scripts to forward emails to an account other than the owners)

If you have a single site, or 10 or something the chances are you personally check them all every now and again, getting a little facetime at least once a week say. In this case your opportunity for hosting a hacked site is 7 days, not awful, not great – Google and browsers will start blocking your site if the hacker has inserted any code going to malware or similar, and otherwise may start to drop you down the rankings if your site now displays a ‘hacked by..’ page instead of your wholesome site.

In the case of a lot more sites on the host this can mean no detection for a longer time, if no system is in place, often first recognised through a drop in statistics/earnings (more likely earnings as in the case of iframed malware a change in the number of hits can be not hugely obvious.)

To add confusion to the mix it’s not unknown for hackers to mask their changes to you, it’s very easy with .htaccess files and php/asp headers (for example) to show content relative to its viewer. E.g. the hacker could shuttle people coming in from Google to a hacked page but people that access the site directly (typing it in) get shown the normal site. Furthermore they may not hit every site you have, perhaps a handful of random choices, some folders not others, a smokescreen like attack which could change each time.

Chances are once you get all your pages fixed and get around to looking at where the security hole is that when you recheck your sites they would have been hit again. This tells you two things, 1. The hacker is relentless (or more likely has a relentless automated program, exploiting 24/7) and 2. You have not plugged the security hole. Or if you are really unlucky you are being hacker tag teamed.

So anyway, detection. How do you go about knowing the integrity of your web portfolio? What if it spans 10 shared hosting accounts or 4 servers? Well likely if you own your own server you have spent the time/cash in locking everything down, what I suggest here would be useful to you guys but you may already have a better solution in place.

Currently there are a bunch of services which will do this for you, of which I have tried zero. “Monitoring” services are available worldwide ranging in prices drastically, for me though even the high end services didn’t offer a full set of features and were mostly hugely overpriced but for the top 50% of the portfolio, not effective for me.

The good things about using external monitoring services are obvious but none seemed to be able to offer realistic change monitoring (e.g. WordPress blogs may change content between <div id=”whatever”> and </div> every hour but the rest of the page should stay almost the same.) It is important they see the addition of malicious code to good pages and not throw constant false alarms. For ‘this website was hacked by..’ pages though they probably do a good job (as well as malware detection.) Uptime monitoring is also common as part of the packages, useful without doubt.

I suggest another way though of monitoring an established portfolio, that is the way I have resolved my recent hacker attacks, a realistic option for shared host/anywhere-in-the-world-with-a-laptop client based use. Ultimately an extension of a few older applications I wrote to manage a growing portfolio, weathered by several hacks across accounts within the past 6 months – Hard checks of every important file.

At first I wrote my system to simply allow me to take stock of the sites and CMS’s I have in place, to work out possible security holes from behind the scenes – but it turns out it works surprisingly well in identifying breaches. By checking your actual live file structure (.htaccess, index.php, default.aspx, index.html etc.) against a known correct file structure snapshot, you take the whole http part of the checking out of the loop, effectively making it a higher level integrity check than external services can ever offer.

By making Checksums of every critical file (often hackers just hit index.php, index.html, default.aspx etc.) within a given ftp/file structure and then automatically rechecking at scheduled points it becomes easy to minimise your window for financial fallout from hackers. This may seem like a time/bandwidth/processor consuming task but in actuality 100 websites with WordPress installed could be checked in a few Mb of download – in terms of modern data use that’s a few browses of a facebook photo gallery. What’s more it can run in the background, only prompting you on changes to files, as frequently as you want.

The side benefit of producing complete hosting account checksum snapshots is you are also able to accurately backup a working copy of your hosting account. Built into the checking process this means that you can then correct hackers’ malicious changes with a click of a button.

This of course does not take into account more hard-file based websites, database changes or regularly altered sites. I recommend automated screenshots to cover these or the combination of external monitoring services and integrity checking.

I have written an alpha release of this system (named Website Integrity Checker for now) and will gladly distribute/discuss it if you drop me a comment below. A beta copy might make its way out sometime.