The Drupal security team issued a patch on October 15. On October 29, it issued a public service announcement that states—in a nutshell—if you didn’t implement the patch within seven hours of its release you should assume your site is compromised.
Garve Hays, a solution architect with NetIQ pointed out the real irony of this security issue. It is a flaw in a Drupal module designed to prevent SQL injection attacks…that can be exploited through SQL injection.
This is a very serious issue according to Ken Westin, security analyst for Tripwire. “According to Drupal’s own metrics, over a million websites run Drupal. Drupal is the CMS of choice for many global brands as well as many government agencies including the White House (whitehouse.gov), Department of Energy (energy.gov), Department of Transportation (dot.gov) and Department of Education (ed.gov). Other high value target sites include Al Jazeera, the Twitter developer community portal and Yahoo Research.”
“The recently released SQL Injection vulnerability affecting every Drupal 7 application is very serious in that it allows for an anonymous user to run arbitrary SQL queries against unpatched Drupal content management systems,” agrees Greg Foss, LogRhythm senior security research engineer. “There are multiple public exploits as well, which make exploiting the vulnerability trivial for even un-skilled attackers. The Drupal Security team also stated that within hours of the public disclosure they noticed automated attacks compromising several Drupal web applications, in general it is assumed that any sites left unpatched during this timeframe are considered compromised. Their recommendation is to either completely rebuild or restore from a backup that was taken before October 15, 2014.”
Unfortunately, there’s a good chance that many—if not most—Drupal sites are compromised at this point. Even in a best case scenario most organizations take longer than seven hours to apply a new security patch, but Marc Maiffret, CTO of BeyondTrust points out, “I think a lot of people missed this vulnerability in all the news swirling around POODLE around the same time.”
The Drupal security advisory details step-by-step instructions for addressing a potentially compromised site:
Take the website offline by replacing it with a static HTML page
Notify the server’s administrator emphasizing that other sites or applications hosted on the same server might have been compromised via a backdoor installed by the initial attack
Consider obtaining a new server, or otherwise remove all the website’s files and database from the server. (Keep a copy safe for later analysis.)
Restore the website (Drupal files, uploaded files and database) from backups from before 15 October 2014
Update or patch the restored Drupal core code
Put the restored and patched/updated website back online
Manually redo any desired changes made to the website since the date of the restored backup
Audit anything merged from the compromised website, such as custom code, configuration, files or other artifacts, to confirm they are correct and have not been tampered with.
Is that good enough, though? Here’s the problem: this flaw has existed for nearly a year. It was initially cited as a bug in November of 2013. It was eventually upgraded to a security issue, but the patch was released seven months after that. In other words, attackers didn’t just have seven hours after the patch was released—they had about a year to compromise this vulnerability at will.
Foss stressed, “Taking this into account, will the sites really be considered free of backdoors even if developers roll back to before the suggested October 15 ‘safe’ date. I certainly don’t believe so. Personally, rebuilding is the safest bet and it’s probably a good idea to migrate to a new server as well because there is no guarantee the backdoor has been removed by rolling back the database and server-side code.”
Organizations should also have tools and processes in place to prevent incidents like this in the future. Tripwire’s Westin explained, “This ‘firedrill’ is a perfect example of why it’s crucial for security and IT teams to have a current and complete audit of all the applications they are running all the way up the stack, from the shell to the user interface. Attackers leverage automation and continuous improvement so defenders have to be prepared to do the same thing or risk becoming prey.”
Kevin Epstein, VP of information security and governance at Proofpoint, shared this: “So sites need to adopt multiple layers of security. Such might include application layer firewalls, anti-phishing technologies, and threat response technologies—all of which might mitigate the effects of an SQL injection attack, even if they didn’t block it outright.”
Finally, Maiffret offered some pragmatic analysis of the situation, and some advice. “It is a big vulnerability to have been missed, but such is the nature of running software as these things happen, and so—more importantly—companies need to make sure they have proper processes in place for how they keep up to date on vulnerability news, patch their systems, and use Vulnerability Management solutions for further verification.”
This post was brought to you by IBM for Midsize Business and opinions are my own. To read more on this topic, visit IBM’s Midsize Insider. Dedicated to providing businesses with expertise, solutions and tools that are specific to small and midsized companies, the Midsize Business program provides businesses with the materials and knowledge they need to become engines of a smarter planet.
- Tackling Swivel Chair Syndrome - November 14, 2024
- Unlocking Proactive Compliance with Adobe’s Common Controls Framework - October 14, 2024
- Unlocking the Power of Continuous Threat Exposure Management - October 8, 2024
