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.

It is likely that more patterns will emerge, so keep an eye on your favorite Drupal blogs for updates.

Want more options? Here's a flowchart detailing how you can evaluate your site along with some recommended actions.

North Texas Drupal October Meetup

We had yet another great meeting of the nascent North Texas Drupal users group this past October 20th.

Travis Tidwell asked the question- When Should You *Not* Use Drupal?  While we all love and user Drupal, it is not always the best tool for the job.  Check out his slides below for more info as well as some notes and related links.

Ian Whitcomb took us through building multi-site Drupal, including solutions such as MultisiteDomain AccessOrganic Groups and andPantheon One.

We also had a discssion of Drupal security, including the recent major core exploit.   Here is a way to see if your site was compromised using a drush command.  

Blog article about presentation with Video and Slides­

Static Site Generators

Bootstrapping your site

"API-first" Development

  • Drupal 8 with Symfony is a solid contender
  • Recommend to start simple with Symfony and bring in Drupal if requirements need it.
  • Other API-first platforms

HTTPS is now a Google Ranking Factor

You may have noticed that when you use your web browser to do online banking or shopping, and it generally switches to HTTPS / SSL mode (with the little lock graphic) for added security.  Looks like Google wants to make that the standard for everyone soon. According to the Official Google Webmaster Central Blog

"Over the past few months we’ve been running tests taking into account whether sites use secure, encrypted connections as a signal in our search ranking algorithms. We've seen positive results, so we're starting to use HTTPS as a ranking signal."

When HTTPS mode is enabled, all traffic is encrypted between your computer and the web server. Which is generally a good thing, but does add a small performance penalty for the time it takes to encrypt and decrypt all the traffic.  Often this is done on non-ecommerce Drupal websites just for the user login and user editing pages, as most content is really not that security sensitive.  But with this announcement from Google, it's time to start thinking about switching your entire site over to HTTPS.

So, how to do that in Drupal? The complete process is too complex for the scope of this blog post, and you will need to make changes on both the webserver and the Drupal sides.  On the server side, you will need to install an X.509 SSL certificate and make some configuration changes. Many web hosts will greatly help with that process, including our hosting partner, Pantheon. On the Drupal side, the easiest way to enable HTTPS mode is by using the Secure Pages module.

Screenshot of Drupal Secure Pages module configuration

The Secure Pages module will not let you engage secure mode until the server is correctly configured to use SSL.  To best comply with the Google initiative, you should select Make every page secure .. and delete all the pages listed in the Pages box, so that every page runs in HTTPS.

Ironically, that Google blog post (and the entire website) is not running in HTTPS mode.