Drupal SA-CORE-2014-005, perspective and lessons

On Wednesday, October 15, 2014, the Drupal Security Team published an highly critical security advisory (reference SA-CORE-2014-005) in regard of a vulnerability discovered in the database abstraction API that allows to automatically sanitize the parameters of an SQL query and, therefore,prevent SQL injection attacks.

Unlike typical security advisories regularly published for Drupal, the nature of this vulnerability provides a way for an attacker to exploit this breach without needing any account or privileges, without even needing for several conditions to be met at the same site (the use of a module, a typical configuration, etc.).

In short, this vulnerability allows an anonymous attacker to compromise any Drupal 7 site by a SQL injection attack.

This is the most serious security issue published since a very long time, at least 9 years.

Let's go back on the chronology of the event.

Discovery

This vulnerability was discovered by Sektion Eins, a renowned PHP security firm established in Germany,which was hired to perform an audit on Drupal for one of its clients. Once this vulnerability discovered , by the end of September, the Drupal security team was contacted and started the resolution process. The author of the discovery chose, of course, to delay the publication of the vulnerability in order to give some time to correct it and organize the process of publication and information.

Preparation

The highly critical nature of this security issue did not upset the existing organization. The team did not panic. Security advisories are published by the Drupal Security Team on a weekly basis, a regular basis that all professionals or enthusiasts with Drupal know and follow (every wednesday afternoon). This regular publication allows those who maintain Drupal sites to prepare themselves to take security measures if necessary, according to a schedule established in advance. After having developed the patch to correct this vulnerability (and, I imagine, after having the entire API database horoughly inspected ), a security advisory has been prepared, to be published on Wednesday, October 15, one week after the end of the DrupalCon Amsterdam international conference. A earlier publication would have not not allowed those present at the event, to develop an appropriate response.

On October 10, a communication is made ​​to alert the Drupal community on a forthcoming publication of a security advisory.

The members of the Drupal Security Team were also able to work together (all of them are volunteers, giving their time in agreement with their respective employers, all of them being major companies offering services related to Drupal, such as Acquia, GetPantheon, Commerce Guys, Lullabot, etc.) to develop preventive protection measures to mitigate the attacks that would undoubtedly wash over the hosting platforms specialized on Drupal once the security breach published, or even cancel them (Shields Up), allowing their customers to make the necessary updates peacefully.

On October 14, and that's unusual, we were clearly warned to be ready to update our Drupal site the next day.

Publication

On 15 October, the security advisory SA-CORE-2014-05 is published and is widely relayed on social networks. All members of Drupal.org receive at the same time the security advisory by email (those who have subscribed to security advisories, but who have not?).

Given the critical nature of the security breach, in addition to the recommendation (the injunction) to update any Drupal site to the new 7.32 release that addresses the vulnerability, a patch is also provided for those who do not have the time, or skills, to quickly perform such update in order to protect themselves as soon as possible. Applying this patch can be performed with one single command that takes only few seconds.

The distribution of this patch did also allow to protect all the Drupal sites that could not migrate immediately to the 7.32 version without impacting the business functionalities already implemented (the migration of such a complex site may require a number of checks before a release). Thus, all the versions of Drupal 7 in production (from version 7.0 to version 7.31) were offered a simple way to be immediately protected without affecting the smooth operation of the site. Even Drupal sites that have been carelessly designed / hacked until their heart (and we know that there is quite a number of them, since number of web designers do not respect the best practices in the design of a Drupal site, see Trouver un prestataire Drupal) were offered a simple and usable solution for their protection.

Of course, the information spreads quickly. The first wave of attempted SQL injection attacks can be found about 7 hours after the publication of the advisory.

Some lessons

Let's try to learn some lesson from the discovery and the management of this security breach.

The Myth of Security

Is Drupal secure ? This is a question that many have arisen, arise or will arise.

Zero risk does not exist. All software has security vulnerabilities (Heartblead, Shellshock, Java, Windows, Wordpress, etc. are probably words that evoke memories) and Drupal is no exception. Security is not a dogma, a binary yes / no, but above all a process of continuous improvement.

Drupal aims to provide a framework with built-in security features (read How Drupal is protected against the 10 largest security breaches) that make it easier for site-builders and developers to build a secure website.

Over the years the mix of security issues found in Drupal has changed. The OWASP project lists injection issues such as SQL Injection as the #1 issue based on how often it is found and the risk exposure. By providing rich APIs and developer education, Drupal has reduced the frequency of SQL Injection vulnerabilities.

The use of Drupal by government organizations such as the White House, the French Government, the site of the Prime Minister, the Australian state, etc., for which there is no doubt about their interest to have a good security, demonstrates that Drupal is just far from being the last in this domain.

The safety management

As zero risk does not exist, the most important question, eventually, is not how secure is Drupal but how Drupal handles security. Vladimir Prelovac, through his open letter addressed to the WordPress community, confirms that security management is indeed a major challenge for any open source solution.

Drupal has an organization and well-oiled procedures for managing security, from the discovery of a vulnerability, its correction and the publication / information to Drupal users. The management of this highly critical security issue, we could see through this post, is simply remarkable and demonstrates the maturity of Drupal, and of Drupal Security Team, in this domain. Preventive shields in order to mitigate, or even eliminate, any attacks exploiting this vulnerability have even been placed on the main specialized hosting platforms.

An awareness issue

In computing, a security policy always has two aspects: a technical aspect and an organizational aspect . We usually assume that a good organization of the security, with good information and appropriate user awareness, can solve / prevent 90% of the incidents that can occur. Technical protection measures are essential, of course, but without a good organization and an appropriate information of the users of the information system, these measures can quickly become ineffective.

Drupal is no exception to this fundamental rule.

The publication, 10 months ago, of a public issue queue pointing out the existence (possible at that time) of this vulnerability is a good illustration. Links for reporting a vulnerability are available on all the pages of Drupal modules (including modules core of course), but the non-use of these provided tools and the publication of an issue (among the two million articles published on drupal.org) in a public queue did not permit to detect it earlier. Besides, being published in a public queue, this vulnerability could have been exploited before the release of a patch.

The organization and procedures established by the Security Team to manage the security of Drupal can only be effective if users are well aware of the security procedures and / or are able to quickly find the information they need; in short, if the end user is the center of gravity of its security policy.

Drupal demonstrates here again its maturity about security through this steady will to constantly improve itself on this aspect. By discussing all the possible options to develop in order to prevent this situation from happenning again in the future, Drupal only implements the three angular stones of a serious security policy: Organization, Awareness and Improvement.

Drupal stronger

Because of its power, its scalability, its ability to evolve, Drupal confirms his breakthrough as a professional platform (CMS / CMF). Acquia (a company created by Dries Buytart, creator of Drupal) is now positioned as a leader in the famous Gartner Magic Quadrant of Web Content Management, along with Oracle, IBM, Adobe and their proprietary CMS. And along with Drupal, we may almost say, by extension. Due to its more and more predominant presence within major companies, firms or administrations, Drupal becomes the object of an increasing number of advanced security audits that can only be beneficial to Drupal and to us, Drupal users. And let's recall that it was during one of these audits that this vulnerability has been detected.

Although we would have been more comfortable without it, but the SA-CORE-2014-005 security advisory showed us how Drupal, through its Security Team and the mobilization of the whole community, manages this kind of vulnerability: with skills, serenity and responsibility. Thank you.

And some tools if your site has been compromised

Nevertheless, some Drupal sites could have been compromised , for many reasons : lack of an appropriate and prompt reaction, lack of time, lack of information (if you have a Drupal site, please subscribe to Drupal security advisories). But here again, the Drupal community is very responsive and several tutorials / tips (your Drupal site has been hacked? What to do now, or How to restore your hacked site) and tools are already online to help you to check if your site has been compromised and, the case thereof, how to sanitize it.

• The Site audit module now includes the detection of the main attack vectors that have been used so far (and it will be updated regularly).
• Drupalgeddon, a drush command, is also able to detect multiple attack patterns.

Please note that these tools can only detect IF a site has been compromised. But they can NOT guarantee that your site has NOT been compromised, for these tools actually only look for the patterns of the first known waves of attack. But other vectors may have been used since, without being listed by the the official FAQ. To be sure that your site has not been compromised, if you were not been able to protect your Drupal site in time (that is to say, within the first seven hours following the SA publication), you should perform a thorough analysis of the files and of the database or, and that's even easier, you should restore your files and your database at a date prior to October 15, if possible.

But we do hope that you would not need to. If any doubt, do not hesitate to call a professional. A hacked site can have very serious consequences (the infection can be spread toyour visitors, the site can be used as a spam sender, or could be banished from the server, etc.)

Why this post?

After the publication of security advisory SA-CORE-2014-005, I have been asked several times about the security of Drupal. It then felt relevant for me to better formalize and organize a factual answer to this concern, as complete as possible, and to share it. Feel free to improve it and share it if necessary.

This post is the translation of the article Drupal SA-CORE-2014-005, mise en perspective et enseignements published on October 26, 2014.