Open sourcing security, or, how Drupal could have saved the ABC's users
You might have heard that last week the ABC got hacked. The truth is a bit more complex than this, and is not as alarming as the statement may imply; rest assured, most of Aunty's sites are fine. However, there are still plenty of lessons to be learnt for everyone concerned, whether you run a website or merely use a website's services. In this post, we'll walk you through some of these lessons, and we'll show how Drupal could have prevented this from happening.
Who's running my website, and what do they use?
What actually happened was that one of the ABC's minisites was compromised, and the database was exported and dumped onto anonymous hosting sites. The minisite was for Making Australia Happy, a TV program that compared Australians from different walks of life to determined what made them happy, and part of the site's functionality involved allowing users to register an account to discuss what made them happy. As far as we and others have observed, this doesn't mean that the rest of the ABC's sites were compromised; the ABC's director of corporate affairs, Michael Millett, has stated that the website was operated by a third party.
This in itself could be a point of concern. On an organisational level, it's important to be well aware of what web assets you have and what responsibilities you have as far as maintaining them goes. If a website is operated by a third party, you need to be able to ensure they are regularly maintained and have security updates applied, and you need to make sure that you have a proper maintenance agreement in place to make sure that someone remains responsible for this.
When dealing with third party providers, it helps to have technical people on hand that are able to discuss the provider's platform of choice with them and are able to work with them to resolve any potential issues. We place a lot of confidence in open source solutions, especially Drupal, because the code and feature set is open for review by anyone. This ensures that our clients can review and understand the platform we work with in minute detail if they so wish, which is difficult to do when dealing with proprietary or bespoke solutions.
Furthermore, if you are a third party provider, you are probably the first person to know if your chosen platform is in danger of being compromised, and it's your responsibility to be proactive about notifying clients and applying updates. As a third party provider ourselves, we are careful to pay attention to notifications of security updates for Drupal and its contributed modules, notifying clients about security updates, and we routinely follow procedures to upgrade sites quickly and easily.
Security in the open
You might wonder how it's possible for open source projects like Drupal to maintain good security, because its codebase is in the open and is therefore available to be picked apart. This openness is often perceived to be a liability, but for us as developers and for hundreds of thousands of Drupal site owners across the world, this is more accurately an asset.
Having the Drupal codebase available for millions of people to pick through enables it to be tested by more than just attackers, it is available to be examined by developers, site owners and security experts all over the world, and tested rigorously to determine whether it is vulnerable to attacks, whether they use familiar or cutting-edge techniques. One rule coined to describe the advantage of development in the open states "Given enough eyeballs, all bugs are shallow", and this definitely applies with regard to security issues.
Furthermore, Drupal's open development methodology allows anyone to sign up to drupal.org, and allows anyone to submit a security issue. Once the community has evaluated and confirmed it, a fix can then be quickly rolled into an update.
Drupal has its own security team dedicated to ensuring that Drupal's core remains secure, providing support to contributed module maintainers, and developing best practices which can then be passed on to the community at large. Most other major open source web platforms, including Wordpress, Joomla, and Ruby on Rails, have their own security teams that serve the same purpose.
One interesting aspect to this story was that the user tables were leaked, which contained hashed versions of passwords. While storing a hashed password is not as dangerous as storing a password in plain text, there is the potential for attackers to take these hashed passwords and then attempt to extract the original password. The reason why attackers would want the original password, even though they've compromised this one site? If the user wasn't careful and reused the same password on multiple sites, attackers could then use this same password to get into all the user's other services; their email, their Facebook, their bank account and more. This is why you should never, ever use the same password on more than one site.
If you use unique passwords for different websites, it might help you to start using a password manager, especially one that allows you to generate your own passwords with a particular strength in mind. I personally use 1Password as a password library, but you can use anything you like, including LastPass, PassPack, KeePass or even an encrypted text file.
In technical terms, one of the most common ways for a password hash to be converted into a legible password is to compare it against a rainbow table, a dictionary of hashes and their decrypted equivalents. Many websites tend to use a relatively simple algorithm for hashing passwords such as MD5.
To prevent a match against a rainbow table, you can salt a password hash to ensure that it contains a signature that is unique to whatever platform or site you are using it on. Salted passwords cannot be compared against a rainbow table; they must be manually decrypted, and that requires that attackers have been careful enough to obtain the salt that was used to hash the passwords. The salt is usually stored in the site's configuration files; if the attacker hasn't been careful enough to grab that too, or if they only had access to the site's database, then they can't crack the passwords so easily.
Drupal 7 uses the SHA512 hashing algorithm together with a generated salt to perform multiple hashes on a password. Specifically, the password is hashed a number of times using a technique called password stretching to make it time consuming to crack the password. Drupal 7 hashes passwords over thirty thousand times, ensuring that the process of trying to extract original passwords becomes very time consuming indeed, to the point where it's no longer worth it to try. Here's a great writeup we found that covers the technical details, and if you'd like to poke around the Drupal 7 source code to find out for yourself, you can do so here.
(Note: For anyone who still has a Drupal 6 site or earlier, all that does is store your passwords with an MD5 hash, which is easy to compare with a rainbow table. Contact us if you'd like details on getting your site upgraded.)
Be calm (and vigilant)
We hope that you've learnt something new about security on the web as a result of this article, and that you've been reassured that if you're working with Drupal, hundreds of thousands of people around the world have your back as far as security goes. We encourage you, therefore, to follow a few simple rules:
- Never reuse passwords
- Take care when creating new passwords
- Make sure your sites are up to date
- Know who is responsible for maintaining your sites
- Keep an eye out for security announcements
It may be that if the ABC or its third-party provider had opted for Drupal on this site instead of a bespoke solution, they may not have been exposed so badly. We remain hopeful that we (or the thousands of other Drupal developers around the globe) are able to help them out.
As for us, we are proud and privileged to have a tool as versatile and secure as Drupal in our arsenal.