Drupageddon Causes Massive Security Headache

Drupageddon Causes Massive Security Headache

2014 has been an interesting year for security bugs, as we have seen a number of long-standing vulnerabilities come up to light, ruining many IT administrator’s morning coffee. The now well-known issues such as Shellshock, Heartbleed and POODLE are vulnerabilities that existed in the code used on a widespread scale for many years. But this doesn’t mean that the old issues are forgotten, as one of the most commonly used content management systems, Drupal, has felt the full impact of SQL injection in its product. Here comes the Drupageddon…

In mid-October, Drupal published a security advisory in which they disclosed the existence of a SQL injection vulnerability in their current software version, one which scored highly in terms of security risk. The irony in this case is that Drupal has an API specifically designed to sanitize queries towards the database and prevent SQLi, and it is in this API that the vulnerability has lain dormant for at least 10 months.

A flaw of this nature in such a widely used platform is highly critical, as it leaves an estimated 900,000 websites vulnerable to an issue that any half-knowledgeable script kiddie could take advantage of, possibly taking control over the website, or just placing a backdoor for later use. Unfortunately, it looks like the memo wasn’t received by all of the site administrators, which prompted a second attempt by the security team at Drupal to raise awareness and urge every user to take the necessary measures. This time around, with a twist: “You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched [within] 7 hours after the announcement.”

Although the Drupal team did not mention it, the situation must be really critical if after two weeks from the initial public notification of the vulnerability, there are so many installations un-patched that a second Security Advisory was needed.

Within hours of the public notification of the Drupageddon vulnerability, the CMS had been bombed with attempts to take advantage of the flaw and gather as many compromised sites as possible, something that is easy to do with automated scanners. Some attackers have gone as far as successfully gaining control of a website, installing a backdoor, then patching it to the latest non-vulnerable version to ensure no other hacker gains control of their already ‘pwned’ area. If only the system administrators had been that diligent.

With a number of very high profile websites – Stanford University, National Geographic, The White House – the recommendation from the Drupal team is clear – if you didn’t update your Drupal installation immediately after the first notification, and you haven’t got a backup of your site from before October 15th, you may as well start coding your website from scratch.

The process of restoring a compromised website to its innocence requires multiple steps – replace your entire site with a static HTML page, remove all the files on the web server or build a new server, restore from the backup you created before October 15th (you have that, right?), then update and patch Drupal.

Hopefully most, if not all, of the obvious targets were patched long before the critical first 7 hours passed, but there has been criticism of the way in which the Drupal team announced this vulnerability. By simply notifying the world at large before responsibly disclosing the issue to its user base, smaller organisations will have struggled to respond in a timely manner. With the increase in watering hole attacks, even the websites of lower profile organisations pose a risk to the financial and personal data stored by large companies, as well as the data these smaller organisations store themselves.