DRUPAL-OPCALYPSE! Devs say best assume your CMS is owned
SQLi hole was hit hard, fast, and before most admins knew it needed patching
Drupal websites that had not patched seven hours after the disclosure on a "highly critical" SQL injection (SQLi) hole disclosed on 15 October are essentially hosed, the content management tool's developers say.
Attacks against the vulnerability (CVE-2014-3704) in version seven of the content management system began "hours" after announcement detailing how the easily exploitable bug granted full control including the execution of malicious code to attackers.
Flaw disclosers SektionEins described in an advisory that the flaw allowed remote unauthenticated attackers to inject arbitrary SQL queries through an API ironically designed to prevent SQLi attacks.
Drupal security bods Michael Hess and Bevan Rudge issued a 'public service announcement warning that because hackers were assumed to have compromised sites patching was now not enough and restoring only from backups would ensure security.
"You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15, 11pm UTC, that is seven hours after the announcement," Drupal's security engineers wrote in a post.
"... updating to version 7.32 or applying the patch fixes the vulnerability but does not fix an already compromised website.
"Removing a compromised website's backdoors is difficult because it is not possible to be certain all backdoors have been found. The Drupal security team recommends if your (hosting provider) did not patch Drupal for you or otherwise block the SQL injection attacks within hours of the announcement, restore your website to a backup from before 15 October 2014."
The duo went as far as to warn sysadmins to stop reading the announcement mid-way, patch, and continue reading.
"If you have not updated or applied this patch, do so immediately, then continue reading this announcement."
They warned that sites unexpectedly patched to Drupal version 7.32 could indicate compromise since attackers had been applying the fixes to lock out rivals. ®
Bootnote: Remediation steps
The Drupal folks are kindly offering remediation advice. Here it is:
- Take the website offline by replacing it with a static HTML page;
- Notify the server's administrator emphasising 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,
- While recovery without restoring from backup may be possible, this is not advised because backdoors can be extremely difficult to find. The recommendation is to restore from backup or rebuild from scratch.
Sponsored: Becoming a Pragmatic Security Leader