Skip to content Skip to navigation

SA-CORE-2014-005 and PSA-2014-003 - Drupal SQL injection vulnerability

IMPORTANT Security Notice

On 15-Oct-2014 the Drupal security team issued a security advisory relating to a highly significant vulnerability in Drupal 7. The vulnerability affects ALL Drupal 7.x sites running version 7.31 or earlier. If you have not already upgraded to 7.32 nor applied the available patch to database.inc then it is highly advisable to do so immediately. The security team more recently issued a follow up notice reiterating the importance and urgency of this topic, and advising: "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."

Note, the same issue affects any Drupal 6.x sites running the DBTNG module.

Some research

So the message is clear: if you haven't already upgraded or patched, then it's a very real possibility that your site has now been compromised.

From a quick search, it took me only a few minutes to find a site which I could confirm still has the vulnerability, so is a target for attack and indeed may already have been compromised. That site is Manchester University Music Society. Their current nginx configuration allows public access to their database.inc file, so by examining that file it was very easy to confirm that the vulnerability is there - it hadn't yet been patched or upgraded (and still hasn't, at the time of writing). This is just one example - I also found a very high proportion of other Drupal sites still, apparently, running Drupal 7.31 or earlier (indicated by their CHANGELOG.txt file). In many cases I can't easily test whether they've already been patched to remove the vulnerability because access to their database.inc file is prevented by their web-server configuration (the case for a standard Drupal installation running on Apache). Nonetheless I would guess that a high proportion are still vulnerable.

As a quick aside, public access to CHANGELOG.txt is often permitted on typical Apache based installations, and often prevented on nginx based systems, including our own. But the reverse is often the case for access to database.inc - our own is visible here and, needless to say, is not vulnerable - we upgraded to 7.32 very shortly after the original security announcement was made.

I did email the Manchester University Music Society at the address given on their contact page to warn them about the risk. That was at 10:25 (UK time) this morning. Checking again now at 15:50, their database.inc is unchanged and vulnerable. The change required is at line 739 where the vulnerable version has the code foreach ($data as $i => $value) and the patched/upgraded equivalent is foreach (array_values($data) as $i => $value). Clearly my email to them remains unread or un-actioned for some reason, possibly it ended up as spam. Again, I would guess they are simply one of many hundreds, quite possibly thousands of sites in the UK alone that are not aware of the issue or haven't got round to doing anything about it. The Drupal security team said "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." It's now a full two weeks, and counting, after the announcement.

So what is compromised in this context?

The potential payload of this vulnerability is about as bad as it gets - the path is clear for attackers to install backdoors as PHP files or other executables. I've seen several reports of malicious PHP files appearing on compromised sites. Those could do pretty much anything - abusing the server to send spam, accessing and forwarding usernames, email addresses, passwords hashes and other sensitive/personal data stored in MySQL or elsewhere on the system, and more. At the operating system level there should be some degree of protection - Drupal and PHP scripts would run as a restricted user, typically user-id apache or www-data on Linux systems, and that would not normally have access to the entire file-system, especially not write access. Indeed, in a well-configured Drupal installation it would typically only have writeaccess to Drupal's files subdirectory and below.

"The recommendation is to restore from backup or rebuild from scratch." - PSA-2014-003

" If you did not update your site within < 7 hours of the bug being announced, we consider it likely your site was already compromised." - FAQ on SA-CORE-2014-005

The two choices

Ignoring the fingers-crossed approach (which would be a very bad idea, considering level of risk and evidence so far) site operators are left with two routes:

  • Restore the entire site, Drupal installation, database, files directory etc. from backup, thereby losing all changes (content updates, new users, password changes, etc) made in the past two+ weeks. This route also assumes they actually have a usable and reasonably recent backup - not always the case for small sites run by individuals, clubs and associations, small businesses and so on.

  • Try to repair the installation. As the above-mentioned article says, "While recovery without restoring from backup may be possible, this is not advised because backdoors can be extremely difficult to find." Difficult, but not impossible. Nonetheless high-cost in terms of time and resources, and requiring further auditing at sensible points in the future to confirm that there's no sign that backdoors were missed.

What about passwords?

Whichever of the above two routes is chosen, there's a further challenge: change all account passwords, because those may quite possibly have been discovered. Drupal does not store these passwords directly, but as hashes, meaning that they cannot be directly obtained from the database. However, brute-force methods exist to extract a password from its hash. So really, after restoring or repairing a site and before putting it on-line, passwords would need to be changed/randomised.

Then, in the case of a repaired site (not restored from earlier backup) there's a further complication. Attackers could easily have changed account email addresses, so that new passwords could be obtained by them using the standard password recovery feature. So, email addresses would need to be checked and corrected first - that could be largely automated using an earlier backup of the database if one exists, but otherwise would be a manual process. Not a major problem for small sites with only one or a few user accounts, but a big headache for public or forum sites with hundreds or thousands of users.

Useful links


Topic: 

Solutions

Powered by Drupal

With our primary focus on the Drupal platform, we combine open-source products with custom development to deliver a cost-effective business solutions: Modules and applications.

Languages

Multi-language applications

We understand multi-language complexities, and can design and develop custom applications with properly integrated language support: Multi-language.

Help

Support and maintenance

Assistance by phone and email, site and server management, configuration and tuning. Please visit our support site for further information.