A nice start to Christmas Day


As our news story over on 4xtra related we've taken on two new e-commerce sites after they we hacked and the site owner got little or no help from her existing support and hosting company.

We supposedly had two clean restores, but Although one was safe, the other turned out to have a small issue...

On Christmas morning, before we had had a chance to even examine the code to see what the restored systems looked like the sites were hacked again – and this time the attack attempted to cross-infect other sites on the same server – a total of twenty six in all. A wonderful Christmas present.

We were alerted almost immediately by our monitoring processes and no harm was done. A quick restore and a read-only lock down got everything straight, so that things could wait until after Christmas.

Step one was to find the infection, remove it and track down the hackers' point of entry. Both are Wordpress sites, extremely popular, but that in itself makes them targets. The injected code was removed, the point of access blocked and both sites brought up to the latest version. They are now secure, but access logging we installed shows up to fifty break in attempts every day!

The second step was something we had been planning to do for a while, which was to isolate the sites hosted on the server. Most although not all are run by PHP systems and PHP has something of a reputation for this kind of cross-site attack. We have had the problem once before emanating from an out-of-date Joomla site. Having blocked the problem by upgrading the site, we planned to isolate each site then, but the problem didn't reoccur and we got distracted... a serious mistake.

Apache normally runs every site as its own user, normally www-data. The problem than is that any script running on one site has access to every other folder on any sites it can see, making it possible to inject malicious code into sites which are themselves internally secure.

It is possible for Apache to run PHP as different user for each site. This denies write access to anything in another site's folders. That doesn't stop a site being compromised, but it does limit the problem to the one which was hacked. Unfortunately the instructions to be found on assorted sites all over the Internet, although each we found is correct either add something unnecessary or miss out a vital item. None provides a view of why the various steps has to be performed, or how they interact

Therefore we've decided to publish yet another explanation of how to implement this over on our blog.