On October 15th 2014, the security team at Drupal announced that all Drupal 7 web sites were vulnerable to SQL Injection attacks.
A German security firm, SektionEins, discovered the flaw, advising:
“A malicious user can inject arbitrary SQL queries. And thereby control the complete Drupal site. This leads to code execution as well… can be exploited by remote attackers without any kind of authentication…”
Drupal 7 and all following releases can be easily compromised (with the exception of the newly released 7.32 or 8 beta2). Drupal 6 is also vulnerable if it utilises the DBTNG module used for Drupal 7 PDO database compatibility. This highly critical vulnerability, CVE-2014-3704, allows anyone to execute PHP code on a vulnerable server. Remote attackers are able to delete everything, install backdoors into the website, change any data in the database including passwords and modify any data hosted on the server. The vulnerability hands over complete control of website content, and low skilled attackers are able to exploit this by deploying easily found attack scripts.
First Steps:
The first step is to check your version of Drupal, immediately. If you have 7.32 or 8 beta2 then you do not need to do anymore. If you do not have 7.32 or 8 beta2 then you should upgrade without delay.
Drupal upgraded, now what?
We will outline the bad news and then discuss some restorative and assuring good news.
The Bad News
When the security team at Drupal warned the world on Wednesday 15th October 2014 of the SQL injection vulnerability users were warned to assume their websites were compromised if not updated by October 15, 11pm UTC.
The reason for Drupal’s caution is that a late patch will potentially not affect vulnerabilities, such as backdoors, already introduced into the system. It is also possible that an attacker, once gaining control of the site in question, will have patched it themselves to retain control and stop other hackers gaining from the potential spoils of the vulnerability.
Drupal have advised, that sites not updated within the six hour timeframe, should be taken offline. All files and databases then have to be deleted and then the site must be restored from backups made before October 15th 2014. Finally, the website must be updated before bringing it back online as the backup will be vulnerable.
The Vulnerability
The bug was introduced in early 2011, allowing the execution of arbitrary code remotely with only one HTTP request and no knowledge of the site is required to conduct the attack.
Drupal handles all database queries by using prepared statements with placeholders conveniently indicating where in the SQL query the input from the user should be included.
SELECT * FROM {users} WHERE name IN (:name_0, :name_1)
Above, variables are bound to :name_0 and :name_1. As this is a prepared statement the attacker cannot inject values into it thereby controlling the SQL query. The placeholder number must be correct so Drupal expands :name to :name_0, :name_1 using a function, this function however is flawed. The flaw is that it incorrectly expands the array to :name_$key0, :name_$key1. SQL queries can now be manipulated as an attacker has control over $key0 and $key1 as seen below.
SELECT * FROM {users} WHERE name IN (:name_test) OR name = ‘Admin’ --, :name_test)
The above query results in an SQL injection giving full control of the database to the attacker. SektionEins have also published a blog demonstrating a proof of concept for an attack that takes one GET request with a cookie that will not be shown in any log.
Password Change Attack
We recreated a password attack in our lab and discovered that the only indication of the standard attack was the log below:
127.0.0.1 - - [03/Nov/2014:08:49:51 -0500] "POST /?q=node&destination=node HTTP/1.0" 200 8889 "-" "-"
This log was linked to changing the username and password of the administrator using the following script.
The Good News
The advice given by Drupal to restore the website back to backups made before October 15th 2014 is what could be considered wiping the slate clean instead of trying to identify if the slate is dirty first. Drupal’s advice may also not guarantee the site was not already compromised, due to the vulnerability existing since early 2011. A proportional response should be the first step to take. We will outline steps that can be taken that will help identify the potential impact of this vulnerability on a given site. As the attacks are so simple it is likely many are being perpetrated by ‘script kiddies’. Assuming this makes it unlikely that enough foresight or effort was dedicated to removing attack trails such as footprints in logs.
Steps to take
1. A forensic investigation of the logs can reveal suspicious activity and its timing.
2. The database can be investigated for users added and modified.
3. Files can be compared to files in backup to identify changes to existing files and discover any new files created.
4. Traffic leaving the network can be analysed to uncover potential attacker connections.
Ultimately, a risk based decision needs to be made between the likelihood of a successful attack having been perpetrated against your website and the impact and complexity of restoring the site to its state prior to October 15th 2014. It may be pertinent to seek assurance before deciding to commit to a full rebuild of your website as it may not have been breached. This will offset the chance of the loss of incremental changes that were committed to the site after the October 15 backup cutoff date and the time the site will need to be offline and inaccessible.
If you would like support in completing an investigation please get in touch using:
contact-us@7elements.co.uk.
Links
Drupal “Public Service Announcement”
https://www.drupal.org/PSA-2014-003
Drupal FAQ
https://www.drupal.org/node/2357241
Drupal flowchart of treatment steps and options
http://drupal.geek.nz/blog/your-drupal-website-has-backdoor
SektionEins Blogpost
https://www.sektioneins.de/en/blog/14-10-15-drupal-sql-injection-vulnerability.html