Researchers map Drupal attack that bypasses poorly tuned Web Application Firewalls

Late last year, CSO Online reported on a vulnerability in Drupal that could have left thousands of websites compromised. Last week, researchers examined the attack in more detail, measuring the time it would take to compromise a website completely.

On October 15, 2014, Drupal urged users to apply an update that fixed an SQL Injection vulnerability.

Unfortunately, unless the patch was applied within a seven hour window, Drupal warned administrators that they should just assume installations in the Drupal 7.x branch before version 7.32 were already compromised.

“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,” Durpal explained in an advisory last year.

The attacks, called Drupalgeddon by some, took advantage of flaws in an API used by Drupal, which ironically, was designed to prevent SQL Injection attacks.

Last week, researchers at Trustwave’s SpiderLabs posted an overview of the attacks, including observations taken as an attack was in progress.

From exploitation, to infection and defacement, the process didn’t take longer than twenty minutes.

The SpiderLabs post is geared towards promoting their Web Application Firewall (WAF), which would normally exclude the story from coverage on Salted Hash.

Yet, based on rankings from last summer (just before these attacks made headlines), their WAF offering existed alongside other nearly identical products from Fortinet, Radware, Imperva, Barracuda, F5, Citrix, and Akamai.

So the focus on their WAF isn’t important, the issue that’s highlighted could happen with any product.

The larger point is that unless the WAF is tuned and has blocking enabled, it’s useless to the organization. The problem is that most organizations leave their WAF in monitoring mode, which would have done nothing to prevent the Drupal attacks – and the SpiderLabs report proves this.

The attack observed by Trustwave’s researchers originated from a location in Freemont, California. The Drupal vulnerability was used to add a new administrator account with a preset password. Once complete, the attackers could return and access the server and the website as if they were a legitimately credentialed operator.

“In this scenario, the target site was not up-to-date on Drupal software patches despite public announcement of the vulnerability in 2014. As this blog post shows, attackers are still searching for, and exploiting, vulnerable websites.

“In this case it was Drupal, but tomorrow it might be another application. The key is to make sure that your organization does a comprehensive software inventory, implements processes to take note of new versions and deploys patches as quickly as possible,” the Trustwave post concludes.