Drupal Security Upgrade 7.32

The Drupal Security team announced a highly critical vulnerability in Drupal 7.x on October 15, 2014 which allows SQL injection attacks on websites. The vulnerability is called SA-CORE-2014-005 - Drupal core - SQL injection, and soon got the name Drupageddon.

The Team also announced the security release to address this: Drupal 7.32. All Drupal 7 users were asked to upgrade to this new release immediately.

Shortly after this announcement, many Drupal 7 sites were exploited for the vulnerability which arose from a database abstraction API. According to the Security Team, “...this vulnerability allows an attacker to send specially crafted requests resulting in arbitrary SQL execution. Depending on the content of the requests this can lead to privilege escalation, arbitrary PHP execution, or other attacks.”

Seeing the widespread attacks made on Drupal sites following the announcement, it was further declared that if users had not upgraded their Drupal 7 versions to Drupal 7.32 within seven hours of the announcement, it was highly likely that the sites were already compromised.

At Srijan, all our systems use GIT to manage the code base for the sites deployed on production servers. After the announcement, the sites were put to offline mode and security patch was applied to release tag and a new Release tag was created and pushed to production environment/server, after which the sites were reverted back to online mode. The complete process was completed in around 20 mins.

A patch was also released for sites which could not be upgraded to Drupal 7.32. However, the patch or the upgrade would not fix the vulnerability, if the site is already compromised. Many websites also reported that their sites had the patches already fixed, even though they had not done it. This is also being seen as a way to know that your Drupal website has been compromised. Drupal.org also says that there may be no trace of an attack.

So what happens if your website has been compromised? It’s possible that all your data might have been copied, and which can be used for malicious purposes.

Attackers could also create access points or backdoors to reach the database, files directory, code and other locations. This could give them further access that could compromise services on the server. Removing these access points is not a fool-proof method. So if the patching or upgrade was not performed by your hosting provider, it’s best to revert to a backup of the website older than October 15.

The process described at drupal.org for this is mentioned here:

• 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.
• A meticulous file integrity check of the site is required. If Git SCM is used then "git status"  or Hacked module should be able to point out suspicious changes
• An audit of the server is require.
• Install, Security review, Drupalgeddon, Site Audit contributed modules and execute these modules checks.
• Change the Drupal hash salt in settings.php for password generation.
• Reset all passwords.
• Rebuild the menu system using "menu_rebuild".
• Scan through the users to check users having "admin" role when they are not required.
• Run scripts to check public / private files locations for any php or shell files.
• If the site is built using Features module, check for any overridden feature.

In case a restore from a backup is not possible, it is recommended that the website be rebuilt from scratch.

What about other versions of Drupal? Drupal 6.x sites are not vulnerable to SA-CORE-2014-005. But if a Drupal 6 site is hosted on a server that also hosts a Drupal 7 site, it might be vulnerable. Also D6 sites using the DBTNG module might be vulnerable, according to the Drupal Security Team. Drupal core 8.0.x before 8.0.0-beta2 is also vulnerable.

Is your Drupal website at risk? Has it been compromised? If you need help to figure this out, contact us and we will get back to you immediately.