DrupalCon Baltimore: 161 sessions, many voices, infinite possibilities. Earlybird rate ends Friday.
What is Drupal 7.32 / CVE-2014-3704?
Drupal 7.32 is a security release that includes a fix for a SQL injection vulnerability. Use the CVE-2014-3704 to identify this vulnerability. The advisory with technical details is available at https://www.drupal.org/SA-CORE-2014-005
When should I update my site?
We strongly recommend Drupal 7 users update their sites immediately.
Why is it important to update now?
Drupal 7 sites are exposed to this vulnerability until they are updated. Unlike typical security advisories released for Drupal, the nature of this vulnerability provides a way for an attacker to create an exploit without needing an account or tricking someone into exposing confidential information.
Update: Following the release of this security advisory on October 15, systematic attacks were launched against a wide variety of Drupal websites in an attempt to exploit this vulnerability. If you did not update your site within < 7 hours of the bug being announced, we consider it likely your site was already compromised. See the follow-up PSA for more information: https://www.drupal.org/PSA-2014-003
See also this drush-based audit tool which may find some signatures of the attacks, and see also the links on that project page.
Do I have to update all the code? Can I just apply a patch?
We recommend that people use the latest release; however, a patch is available at https://www.drupal.org/SA-CORE-2014-005. If you are running a previous version, a patch will provide the same protection until you can do the full upgrade. Make sure to do a cache clear after updating the code (e.g. drush cc all).
Can I just put the site into Drupal's "Maintenance mode"?
This is not an effective way to mitigate this vulnerability. You could disable the site entirely (e.g. temporarily pointing the webserver at a directory that contains a static HTML page, or remove Drupal's index.php).
Can I just use WAF rules to protect my site?
It is not recommended to solely rely on WAF rules to protect your site against this SQL Injection vulnerability. We're not aware of any WAF rule that can detect 100% of the attacks and avoid any false positives due to the nature of Drupal's module eco-system (read more). Moreover, there may be other HTTP exploit vectors outside of the GET or POST content to exploit this vulnerability. No mitigation will offer as good a fix as upgrading your site to Drupal 7.32.
My site has already been patched
We've seen many reports where people found that their site had already been patched even though nobody in charge of the site updated the site. This means that the site was compromised via a new entry or an updated entry in the menu_router table, which allowed the attacker to execute commands on the server to patch the site. At this point, the site has been compromised and should probably be taken offline while you assess what to do including forensic review; an audit of all files, code, users, permissions, roles, database content; complying with local regulations and standards including informing users and potentially law enforcement; and remediation or rebuilding the site.
See also this drush-based audit tool which may find some of the back-doors and see also the links on that project page.
Is Drupal 6.x vulnerable?
Drupal core 6.x is not vulnerable to SA-CORE-2014-005 (CVE-2014-3704). Sites using the DBTNG contributed module might be vulnerable depending on how that module is used. A Drupal 6 site that is hosted on the same server as a Drupal 7 site might be vulnerable. See an investigation and remediation guide for advice about exploiting across sites/servers.
Is Drupal 8.0.x vulnerable?
Yes. Drupal core 8.0.x before 8.0.0-beta2 is vulnerable to SA-CORE-2014-005 (CVE-2014-3704). If you have been running an earlier version of Drupal 8.0.x on a public server, it is likely to have been compromised if you did not update to beta2 or patch within hours of the release of the SA, and you need to initiate steps to audit your site and recover.
Is Drupal secure?
All software has security vulnerabilities and Drupal is no exception. In a study by WhiteHat Security, 86% of websites across a variety of platforms both Open Source and proprietary had a serious vulnerability.
Drupal aims to provide a framework with built-in security features 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.
Figure: from http://scor.github.io/drupal-security-2014/#/13
How are issues like this found?
This issue was identified by Sektion Eins, a renowned PHP security firm located in Germany who was hired to audit Drupal by an unnamed client. Every year dozens of Drupal websites hire penetration testers and security researchers to find issues like this and they are reported to the Drupal Security Team who helps get the fixes incorporated and released to the world. If you use Drupal in a high-security environment you might consider hiring such a firm.
How long did it take to release this patch?
The Drupal Security Team has a standard process for releasing core security issues. We work on them in coordination with the system maintainers and then release them on the third Wednesday of each month. The Drupal Security Team was informed of this issue in the third week of September of 2014. Given the severity of the issue, we debated about releasing it early. Our main concern was when people would have the time to perform the upgrade. Drupalcon Amsterdam started on September 29th meaning that many of our community members were busy preparing for that event. The week after Drupalcon is typically busy catching up from being at Drupalcon and then October 15th was the first regularly planned security release Wednesday. We felt that it would be better to use the regularly scheduled date which also happened to be the first date when the Drupal community would be likely to have time to focus on the upgrade.