SYSSEC: March 2007 Archives


March 14, 2007

As you may have heard, someone recently inserted a back door into WordPress 2.1.1. What appears to have happened is that the attacker broke into WordPress's servers and modified the distribution:
Longer explanation: This morning we received a note to our security mailing address about unusual and highly exploitable code in WordPress. The issue was investigated, and it appeared that the 2.1.1 download had been modified from its original code. We took the website down immediately to investigate what happened.

It was determined that a cracker had gained user-level access to one of the servers that powers, and had used that access to modify the download file. We have locked down that server for further forensics, but at this time it appears that the 2.1.1 download was the only thing touched by the attack. They modified two files in WP to include code that would allow for remote PHP execution.

What's interesting about this incident is how it was detected. In many such incidents, what's detected is that there is something funny on the systems hosting the code (e.g., the CVS repository in the 2003 Linux kernel backdoor attempt. The relevant change then gets tracked down and studied very carefully. According to the WordPress people, however, what happened here was that someone detected the vulnerability and then they tracked it to an intrusion.

This is interesting because there are two major ways for someone to insert a back door into some piece of open source software:

  • Compromise one of the development or distribution servers.
  • Make a legitimate change that contains a back door.

The first is easier to do because most systems aren't very well secured and so all you need to do is break in and replace the distribution. However, it's also a lot easier to detect. First, breaking in often leaves signs. Second, the source code typically exists in multiple copies and so eventually the inconsistency gets noticed, especially because it's typically the download servers that are easiest to attack but they can be compared with the main source repository.

The second is harder to do but can be much more effective. You just submit a fair-sized patch to the project that happens to contain a security vulnerability. Most patches don't undergo particularly thorough review, especially on non-security projects, and it's quite easy to hide a buffer overflow or other vulnerability in your code once you get above a hundred lines or so. This is a little more work since you actually have to implement a semi-useful feature, but the bar for that is pretty low on most projects as well. I don't think I've ever heard of a backdoor being inserted this way. It's hard to know if that reflects that nobody does this or just that nobody catches it.