Whenever a security exploit is fixed, users are advised to patch quickly to reduce the risk of attack. In the case of a recent open-source Drupal content management system (CMS) vulnerability, the window in which users needed to patch before being exploited has been quantified as being only seven hours.
On Oct. 15, Drupal issued its SA-CORE-2014-005 advisory, warning of a highly critical SQL injection vulnerability that is also identified as CVE-2014-3704. Drupal is a widely deployed CMS that is used by the White House and the U.S. Federal Communications Commission (FCC), among other notable organizations.
On Oct. 29, the Drupal project issued a follow-up warning that it was aware of public attacks against Drupal sites that had not patched for CVE-2014-3704.
“You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement,” the Drupal project warned.
How the Drupal project was able to define the window of vulnerability is thanks in no small part to its community of hosting vendors. Greg Knaddison, director of engineering at Card.com and a member of the Drupal Security Team, explained to eWEEK that several companies that provide hosting focused on Drupal decided to create platform-level protection against this issue that not only mitigated the attacks, but also recorded data about them.
“While the rate of sites upgrading for this release has been better than the historic rate, it’s still not ideal,” Knaddison said. “The statement is perhaps stern, but also realistic. Our goal is to encourage people to take action so that these compromised sites are cleaned up as soon as possible.”
While patching is what the Drupal project would prefer all administrators do, there is another mitigation that can help protect unpatched sites.
“A well crafted WAF (Web Application Firewall) rule should be able to prevent this attack, and indeed CloudFlare had a rule running within hours of the release,” Knaddison said. “They do still recommend upgrading sites as soon as possible, which I think is prudent.”
For the CVE-2014-3704 vulnerability, a Drupal administrator must go into the CMS and update, as there isn’t currently an automated update mechanism for the core application. Knaddison explained that Drupal has a system for installing and updating extensions (including modules and themes) but not for the core itself.
“It does require a site admin to actually log in and click a few buttons,” he said. “Some Drupal-focused hosting companies have tools that make updating the core a similarly simple login-click-click-click operation.”
Knaddison added that some Drupal hosting companies also offer more automated updates. The idea of automated CMS updates is one that is already being used by other projects. The open-source WordPress blogging and CMS platform introduced automatic updates for security issues starting with the WordPress 3.7 release in October 2013.
Speaking about Drupal in particular, Knaddison noted that there’s a risk to automated update systems in that they require configurations of the Webserver that put the system at risk in other situations.
“Given that trade-off, there has always been lukewarm support for the idea of in-site and/or automated upgrades within the Drupal community,” he said.
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.
