Assume your Drupal 7 site has been compromised

Administrators of sites that run Drupal 7, and have not yet updated to version 7.32 or have done so later than 7 hours after the public revelation of the highly critical SQL injection vulnerability (CVE-2014-3704) on October 15, are advised to consider their site as potentially compromised and proceed to fix the issue.

The vulnerability was discovered by a researcher with German PHP security firm Sektion Eins, and the information shared with the Drupal Security Team, who issued an update that fixes the flaw.

“A vulnerability in this API 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,” the team noted in the initial warning.

The main problem is that the bug is extremely easy to exploit and automated attacks began compromising Drupal 7 websites within hours of the announcement of the existence of the bug.

“Simply updating to Drupal 7.32 will not remove backdoors,” the team warns and urges: “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.”

“Attackers may have copied all data out of your site and could use it maliciously. There may be no trace of the attack,” they say, and add that they “may have created access points for themselves in the database, code, files directory and other locations,” and “could compromise other services on the server or escalate their access.”

In case they haven’t updated Drupal themselves, site administrators should check with their hosting provider whether they have administered the patch for them before Oct 15th, 11pm UTC. If they have not, they should restore their website from a backup from before that date, or rebuild it from scratch.

The team also provided a helpful step-by-step guide on how to go about doing this and the things admins should be careful about.

“The so-called “Drupageddon” vulnerability could have easily led to exploitation of any systems running the vulnerable code. With such an easy to exploit flaw, the chance of exfiltration of data or further exploitation are high. For those who have good security controls, reviewing of logs and traffic directed at the sites following the vulnerability being announced and the patch applied is common sense and highly advisable with appropriate action taken if indicators of compromise are found. For those who don’t have such a good level of security or visibility into the logs, the advice from the Drupal team should be heeded. If you don’t know if you were exploited you should assume that you have been,” commented Gavin Millard, EMEA Technical Director at Tenable Network Security.

“The issues highlighted by the Drupal team could have been reduced if responsible disclosure followed. Announcing a fundamental flaw in the code to everyone without giving much runway to the users of Drupal to proactively patch, gives ample time for attackers to weaponise the flaw and exfiltrate data or manipulate the systems for later exploitation.”

It is estimated that some 950,000 sites use version 7.x of the Drupal CMS. Drupal 6.x is not vulnerable to this vulnerability.

Share this
You are reading

Assume your Drupal 7 site has been compromised