A recent Monday morning brought a nasty surprise. A hacker had gained access to a web site I run, and planted a script engagingly entitled “Magic Include Shell WordPress Edition”, buried under an innocent-looking directory called images in the uploads section of the WordPress blog installation.

The hacker chose a Friday evening to start spitting out trackback spam, where ad-laden comments are automatically posted to other blogs, hoping that the activity would attract little attention over the weekend.

Shutting down the script was easy; but how did the intruder gain access? Could there be other sinister scripts or executables lurking on the server? How could the server now be secured?

It was the cue for hours spent trawling through Apache logs, consulting with users and developers of open-source software used on the site, and inspecting server backups to check the state of files. We think that the problem began with a stolen cookie, escalated by a security issue in a PHP application that was not patched with the latest update, and resulting in the hacker having free ability to upload files and scripts to the web site, wherever the web server had permission to write.

This last point is interesting. It used to be considered obvious that web servers should not have permission to write files in places where they can also be served or executed by the web server. The problem is that the surge in user-generated content means there is pressure for easy authoring and customisation of web content. WordPress is an example, and some convenient though non-essential features depend on certain folders being writeable by the web server. That proved a fatal weakness, when combined with other vulnerabilities.

It is tempting to keep quiet about an embarrassing incident. However, I am convinced that it is better to discuss and learn from events like this. Further, I have never been under the illusion that web servers like mine are secure. They are not places for critical data. Flaws in popular applications are widely and frequently exploited, so my experience is not unusual. At the same time, just because something is commonplace does not make it unimportant. Hacked sites are the source of many perils, such as virus-infected spam messages, phishing sites, or any amount of illegal content.

Lessons learned? First, anyone managing their own web site, even on a shared host, needs to come to terms with the administrative responsibilities. Unfortunately, leaving well alone is a recipe for disaster. Fully managed solutions are increasingly attractive for non-specialists. Second, it is a reminder that insecure Windows boxes are by no means the main problem for Web security; Linux and PHP can be just as bad. It all depends on configuration, management, and applications. Third, the open-source community can be wonderfully responsive when people have problems.

Fourth, if you manage a web site, don’t forget to check the logs. If your site is hacked, at least you will be likely to discover it quickly.