I spent several hours last week rescuing two WordPress blogs (this blog and GastroGrrl) that had both been exploited, and had become victims of nefarious spam links.
h2. WordPress Exploit
The exploit was remarkably clever. Only when Google’s search engine spider (googlebot) visited the site, did it include spam links at the footer of the page. The links were only visible when looking at the text-only version of the cached copy in google’s index. The reason I’d found the spam, was because the keywords showed up in the Google Analytics application, and GastroGrrl was no longer appearing in google’s index.
The exploits were a couple of files found on the web server – disguised as jpg and png image files – that were in fact malicious PHP scripts. The scripts went as far as adding a new user to the database.
I had no alternative except to completely reinstall both the WordPress application, and also the database. Twice. Not much fun.
The installs were up to date, though a few months ago, I was late in updating the software. Yesterday, WordPress announced another security update to version 2.6.5.
Along with the release, was a note that the version number had skipped from 2.6.3 to 2.6.5 due to a malicious, fake version of a 2.6.4 release existing online. Several months ago, an official WordPress download was hacked on the official servers, and exploits were widely distributed.
h2. Open Source Risk
Keeping open source weblog applications, like WordPress, up-to-date, can become quite an administrative overhead for those that manage client blogs. As weblogs have moved into the business/PR/marketing domain, many of those managing the blogs are not fully-fledged system administrators with the knowledge on how to secure their database or unix file permissions. This is a potential risk to the customer.
The problem is not limited to WordPress. OSCommerce, Drupal, Joomla – all popular open source applications – have all had exploit issues. This is not so much because the applications are poorly coded; it’s the nature of open source – anyone can examine the code. The more popular the application, the more likely it will be exploited.
In my work with Stan, when we discuss client requirements, we consider 3rd party open source solutions versus bespoke development. Much of the decision is based on the specific requirements, but increasingly, we also consider the security risk, and maintenance overhead.
A simple example is the ubiquitous CAPTCHA utilities found on web forms. They are an obvious target for spammers, who want to leave spam comments on weblogs etc. Open source CAPTCHA’s became a popular way to thwart such spam, and have become increasingly complex as they face a continuing battle with the spammers. In my opinion, this problem has now gone full circle. When applying a CAPTCHA solution to a web form, I choose *not* to implement a standard, open-source solution, opting instead for my own, less complex, easier to exploit, implementation. It may be easier to exploit, but who is going to bother?
Open source is great. My day-to-day development utilises numerous open-source applications. However, when a customer’s reputation is at stake, and indeed our client relationship, one has to ask the question – is open source software a risk to your business?
Tags: linkedin, open source, spam, wordpress
Erm, what has “open source” got to do with this? The bad guys target the biggest player, no matter where that comes from. If the most popular blog platform was Microsoft BlogPublish 2008, you can be sure it’d have just as many exploits and they would take longer to be patched.
PS: Remember you asked why I don’t have comments on my blog?
Simon. Yes you’re right. The biggest players are always going to be the main target. But when the biggest target also happens to publish it’s code to the world, it becomes a) easier to find an exploit b) easier to distribute exploited code and c) harder to address the issue afterwards
Of course, conversely, open source code can be scrutinised by legitimate users, and potential exploits removed. This tends to happen with code libraries more than applications.
The reality is that the majority of web applications and frameworks are open source, and it’s getting easier to deploy and integrate them without fully appreciating the consequences.
I think the both of you are right Simon & Howie. In my work as a software developer, i know how easy it is to exploit a piece of custom software once you have the code!