The Drupal team released an update to a critical SQL Injection vulnerability a few weeks ago and urged all their users to update or patch their sites immediately.
If your site has been compromised you can use our free guide to fixing Drupal hacks.
Today the Drupal team released a strong statement via a public service announcement:
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.
In case you’re wondering, this is a very strong statement for any organization (especially an open source project) to make. It’s one we agree with and tried to amplify, without causing alarm in the initial post. Less than 48 hours after their disclosure, we released a post saying that attacks were already in the wild and attempting to compromise every site they could.
The scariest part of this vulnerability is that since Drupal uses PDO, this vulnerability is not only limited to SELECT statements; an attacker is able to able to insert or modify arbitrary data in the database.
Severity, coupled with its simplicity, is a recipe for disaster. It’s a matter of time before it’s integrated into the latest toolsets and attacks are actively detected.
The first attack started 8 hours after the disclosure. The attackers began hitting our honeypots with the following SQL Injection attempt…
One thing I want to make very clear is that every site behind our website firewall is and has been protected against this attack. We still recommended all our users to patch, but our virtual patching (along with our SQL injection protection) kept and will continue to keep our client’s sites safe.
Recovery Mode
If you have not patched your site in time and were not using a Website Firewall with virtual patching enabled, you should assume that your site was indeed hacked. You need to defer to your incident response procedures until you can prove otherwise. We have a Drupal guide that can help you.
The Drupal team provided some steps in their disclosure, but we also wanted to recommend the following steps:
- Check if your site is actively serving malware or spam. Free scanners like SiteCheck and Unmaskparasites exist for this purpose.
- Download a filesystem backup from before Oct 15th and compare all file changes since then.
- Download a database backup from before Oct 15th and compare any changes there. Look for new users and new hooks especially. If you can, restore to that backup to be safe.
- Change all passwords.
- Look for any new file added.
The scary part of this issue is that Drupal, unlike many other of its counterparts – Joomla! and WordPress – is heavily employed in larger organizations (enterprises). This means that it’s highly unlikely that they were able to patch. Unlike consumers and small businesses, large organizations have processes that dictate the steps they are allowed to take and at what points. Each step has a series of approvals and depending on the size of the organization those approvals can be exhaustive (meaning they can take time).
This is a recipe for disaster; if those websites are in fact compromised, they could be leveraged and daisy chained for a massive malware distribution campaign. Take that into consideration with the size and audience of brands, and the impact grows exponentially.
If you are one such organization in this type of situation, we highly recommend employing technology solutions that give you more time to follow your steps while still protecting your online property.
1 comment
Interesting to see that, despite the warnings, two public sector websites here in the UK that were using Drupal 7 have been hacked and defaced – Shropshire fire service and Nottinghamshire police. Info here: http://www.bbc.co.uk/news/uk-england-shropshire-29966897
Interestingly, checking each on Sucuri Sitecheck also flags up that they are both running on out of date versions of Apache.
I think you guys should get in touch with them 😉
Comments are closed.