Advisory says to assume all Drupal 7 websites are compromised

If your organization uses Drupal, you might have a serious problem on your hands. On October 15, Drupal urged users to apply an update that fixed a SQL Injection flaw. However, unless that patch was installed within seven hours, Drupal now says it’s best to assume the website was completely compromised.

The SQL Injection vulnerability exists in an API used by Drupal, which is supposed to prevent SQL Injection. It was re-discovered by German security firm SektionEins in September, after a Drupal user hired them to check for vulnerabilities.

Drupal uses the API as a way to handle prepared statements in Drupal core 7. Thus, all versions of the Drupal 7.x branch before version 7.32 are vulnerable. If exploited, a remote, unauthenticated attacker can inject SQL queries, elevate privilege, or otherwise completely control the Drupal installation. Code execution is also possible.

Immediately after the vulnerability became public knowledge on a wide scale, criminals started searching the Web for vulnerable installations.

Using automated techniques, scores of websites were targeted to the point that Drupal says it’s easier to assume installations that were not patched within the seven hour time frame are compromised. Worse, in some instances compromised websites were actually patched by the attackers, in order to prevent further exploitation.

“Automated attacks began compromising Drupal 7 websites that were not patched or updated to Drupal 7.32 within hours of the announcement… You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, [which is] 7 hours after the announcement,” Drupal’s latest advisory explains.

Once the issue was addressed in the Drupal advisory announcing a patch, experts took notice of the fact that it had been previously disclosed.

“The fact that this vulnerability was independently sitting in the public domain in Drupal’s public bug tracking database since November 2013 is interesting. They appear to have overlooked the severity and it took an independent researcher to separately find it and bang the security drum in order for people to take notice,” commented Robert Horton, European managing director at NCC Group.

Ryan Aslett, an Infrastructure QA Engineer for Drupal, offered some insight as to why the security team (comprised of 40 volunteers from around the world) missed the earlier reports.

“Drupal’s volunteer security team does an excellent job of finding and preventing security holes, but they are not omniscient. And while this bug was mentioned in a bug report, you must also understand that there is no person, or groups of persons who’s job or role it is to read every issue with Drupal core,” Aslett commented.

“That issue wasn’t submitted as hey, this is a security hole,’ and it wasn’t submitted to the security teams issue queue (where there *are* people who’s role it is to address these sorts of things). There are currently over 14000 issues in Drupal core’s issue queue. I would bet money that somebody else has also reported another potential security hole via some sort of report in there, and nobody has seen it. Who’s job is it? Yours. Mine. Everybody who participates in an open source project. Many eyes make all bugs shallow only works if you actually have many eyes.”

Again, anyone using a Drupal installation that isn’t updated to version 7.32 (or an installation that wasn’t patched within the target window) should assume the worst and start the recovery process.

Drupal has offered some basic steps, but the incident response process will differ between organizations, so it’s best to stick to internal policy no matter what. For administrators acting on their own, contact your Web host and discuss options, which could include assistance in responding to a potential incident.

In the mean time, the first step is to take the Drupal website offline. Replace the index.php file with a generic HTML page, and begin the transition process to a backup of the website that is from October 14 or earlier.

Do not attempt to restore without a backup or just patch a standing install. Attacks targeting this vulnerability have been known to install backdoors, which may reside outside of Drupal’s core code.

Unfortunately, if the backups were stored on the same server as the compromised website, it might be best to remove the entire installation and rebuild it from scratch.

Either way, the entire server will need to be checked for malicious code, and signs of malicious activity. This is because a single vulnerable Drupal install is all that’s needed to compromise the server and the other websites on it, which compounds the problem for administrators hosting Drupal on re-seller hosting accounts or shared hosting environments.