Content management system Drupal has issued a chilling public service announcement to website admins and internet users who might visit the hundreds of thousands of sites running its software.
According to the company, “automated attacks” started to hit websites running Drupal version 7 within a matter of hours of it disclosing a highly critical SQL injection vulnerability on October 15th.
Automated attacks began compromising Drupal 7 websites that were not patched or updated to Drupal 7.32 within hours of the announcement of SA-CORE-2014-005 – Drupal core – SQL injection. 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.
If a site using a vulnerable version of the Drupal CMS is attacked, hackers could steal information from the site or open backdoors to allow them continued remote access to the system.
This is a big problem. Because if you *now* update your website to Drupal 7.32 (which doesn’t suffer from the vulnerability) that won’t get rid of any backdoor that the hackers may have already implanted into your system.
Furthermore (and you may feel like banging your head against a wall at this point), Drupal says that some attackers may have actually applied the patch for website admins to keep out rival hackers, and potentially throw IT teams off the scent that their site has been compromised.
Updating to version 7.32 or applying the patch fixes the vulnerability but does not fix an already compromised website. If you find that your site is already patched but you didn’t do it, that can be a symptom that the site was compromised – some attacks have applied the patch as a way to guarantee they are the only attacker in control of the site.
What a unholy mess.
Of course, determining if there is a backdoor on your website isn’t going to be easy.
Clearly it’s important that vulnerable sites update to the latest version of Drupal as soon as possible, but as that’s no guarantee that they might not still have been compromised in the last couple of weeks more drastic action is required.
Drupal’s advice will be a hard pill for some sites to follow, but should mean that you can feel confident that your site is not affected.
In a nutshell, if your site wasn’t protected within a few hours of Drupal’s announcement on October 15th, you need to restore it from an old backup or rebuild it from the ground up.
The Drupal security team recommends that you consult with your hosting provider. If they did not patch Drupal for you or otherwise block the SQL injection attacks within hours of the announcement of Oct 15th, 4pm UTC, restore your website to a backup from before 15 October 2014:
- 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.
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.
Drupal is, of course, used by hundreds of thousands of websites across the internet – including some very popular ones.
“As soon as a vulnerability in popular CMS platforms like Drupal is discovered, millions of crawlers operated by hackers (similar to Google bots) start searching for vulnerable websites. Once a victim is identified, their website gets hacked, patched (to prevent ‘competition’ to overtake the same site) and backdoored,” explained Kolochenko.
“Within several days, access to the compromised website will be sold on the darknet market, more than likely to several different customers at the same time who each may well resell it several more times,” Kolochenko continued. “Like this, your personal blog may be easily involved in a dozen different criminal offences such as hosting illicit content, sending spam and infecting visitors, to name just a few.”
Don’t dilly-dally. If your website uses Drupal, and you are responsible for maintaining its security, check that you are running the latest version and determine if you may have patched too late to prevent possible compromise.
You may also want to check with your boss whether you’ll get paid for working overtime. After all, they wouldn’t want you to down tools at 6pm, right?
- Drupal Core – Highly Critical – Public Service announcement – PSA-2014-003.
- Your Drupal website got hacked, now what.
Found this article interesting? Follow Graham Cluley on Twitter to read more of the exclusive content we post.