Drupageddon: Aftermath

By now you've heard about the Drupal core vulnerability commonly referred to as Drupageddon. Let's look at some common questions.

How Bad Was It?

The Drupal community freaked out. Actually, the Internet community freaked out. Was the freakout justified? Unfortunately, the answer is yes. The vulnerability allows anonymous users potentially unfettered access to PHP and the site database and as soon as the Drupal Security Team announced it, the world knew about it. Within seven hours of the announcement, there were already reports of automated attacks.

There was a report that "at least 12 million" sites had been compromised, but the report based this number on bad assumptions, so you should ignore it, much in the way you should ignore numbers in advertisements qualified with "up to" or "results not typical".

What Was It?

Essentially, the vulnerability allowed savvy site visitors to perform arbitrary operations on the site database. There is an excellent post explaining what the issue was if you're interested in the technical details. Once an attacker gained a foothold in the database, then that opened the door to executing arbitrary PHP code and from there, your world was his (or her) oyster.

Has It Been Fixed?

Yes, Drupal 7.32, released in conjunction with the security announcement, fixed it. Update your Drupal core to that version, or at least apply this patch.

Can I Tell If My Site Has or Hasn't Been Compromised?

You can check for some of the known attack patterns to prove that your site has been compromised, but unfortunately, you cannot prove that your site was not compromised. Attacks could have done their dirty work and then left no trace. They could have left a backdoor that didn't follow any of the known attack patterns. As with many things, it's difficult to prove a negative.

What Is The Safest Thing To Do?

The Drupal Security Team released a frightening (and accurate) PSA that recommended rebuilding your server and restoring your site (code, files and database) from a backup made before October 15. Yes, that means what you think it means.

Do I Really Have To Rebuild Everything?

Per the Drupal Security Team, that's the safest thing to do. You don't have to do it, you merely assume more risk if you don't. Fortunately, there are also some potentially mitigating circumstances. If you host your site with one of the big Drupal-centric hosts, then your risk could be reduced if your host rolled out protections along with the security announcement. Both Acquia and Pantheon posted they had done this. Other hosts may have implemented protective measures as well, but the less Drupal-centric your host, the less likely that would be.

You can also check for some of the known attack patterns. While their absence doesn't mean that your site has not been compromised, it could affect your decision with regard to the risk you are taking by not rebuilding.

If your source code is under version control (like git), check to see if your codebase has been modified or if there are new files that have been added.
Check your uploaded files (which are normally not under source control) to see if there are any PHP files.
If you don't have your source under version control, you can still check for any PHP files (not just in the uploaded files, but everywhere). Be aware that there are plenty of legitimate reasons for a PHP file to exist in your codebase, so don't delete indiscriminately.
If you have access to your database, either through the command line or a UI, check the menu_router table for suspicious callback values, like file_put_contents, php_eval, or assert.
Look for any suspicious users, especially ones with the administrator role.
Look for blocks or fields using the PHP Code text format. Inspect them for suspicious content.