Drupal SQLi (Drupalgeddon) Attack Trend CVE-2014-3704 / SA-CORE-2014-005

It has been over 19 months since Drupalgeddon, which refers to Drupal’s Security Advisory (SA) SA-CORE-2014-005. For those unfamiliar with it, it was a highly critical SQL Injection (SQLi) vulnerability that allowed an attacker to arbitrarily execute SQL commands remotely, leading to potential privilege escalation issues and execution of PHP code on the server.  The vulnerability affected Drupal 7 and was patched by the Drupal core team in CVE-2015-3704.  The vulnerability was severe enough that the Drupal team released a public service announcement (PSA-2014-003) warning users who had not updated to presume they were being compromised:

Automated attacks began compromising Drupal 7 websites that were not patched or updated to Drupal 7.32 within hours of the announcement of SA-CORE-2014-005 – Drupal core – SQL injection. 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.

If you like going back in time, I recommend reading these three articles to understand the severity of what happened:

• Oct 15, 2014: Highly Critical SQL Injection Vulnerability Patched in Drupal Core
• Oct 17, 2014: Drupal SQL Injection Attempts in the Wild
• Oct 29, 2014: Drupal Warns – Every Drupal 7 Website was Compromised Unless Patched

The Drupalgeddon event came to the forefront of media attention April 2016 with the Panama Papers debacle. When researchers disclosed that Mossack Fonseca had been using Drupal as the platform of choice for their customer portal, and WordPress for their website. There was a lot of speculation into the role that these platforms could have potentially played in the compromise. Drupal was specifically running on Drupal version 7.23 with 25 different vulnerabilities according to Forbes – the most critical being the Drupalgeddon SLQi vulnerability.

This came full circle at the recent DrupalCon 2016 in New Orleans, where we gave a talk on website security, with an emphasis on Drupal. Tony Perez was asked: (a) what his thoughts were on Drupal being the attack vector and (b) if we were still seeing attacks against the vulnerability.

Drupalgeddon… 19 Months Later

It has been a long time since the vulnerability was released – an eternity on internet time – enough so that we almost forgot about it. The web however does not forget!

We decided to investigate and the results were interesting. Remember, the vulnerability was disclosed October 15, 2014 and internet-wide attacks started just a few days after.

After the initial attacks in October and November of 2014, the attacks dropped and remained consistent through 2016. If someone had not patched, they are surely compromised now. But that doesn’t stop attackers from trying to find new entry points and even compromise already compromised sites.

As for the attack types, they remained consistent to what we saw during the initial release. Most attacks leverage the SQL injection vulnerability to create a new admin user with injections like the following:

Example 1:

name[0%20;update+users+set+name%3d%27derevos%27,+pass%3d%27$S$CTo9G7Lx2mQZv/dfetGZcq7
e1cVNpFpTRdZ8EckF/d6BnrMPZ/Ce%27+where+uid%3d%271%27;;#%20%20]=bob&name[0]=test&pass=shit2&test2=test

Example 2:

name[0;update users set name %3D 'HolaKo' , pass %3D '%24S%24DrV4X74wt6bT3BhJa4X0.XO5bHXl%2FQBnFkdDkYSHj3cE1Z5clGwu' where uid %3D '1';#]=test3&name[]=Crap&pass=test&test2=test

Example 3:

POSTLOG:name[0;update users set name %3D 'Mr.R00t2_404' , pass %3D '%24S%24DrV4X74wt6bT3BhJa4X0.XO5bHXl%2FQBnFkdDkYSHj3cE1Z5clGwu',status %3D'1' where
uid %3D '1';#]=test3&name[]=Crap&pass=test&test2=test

Each attack forces a new admin with names Derevos, Holako and Mr.R00t2_404, respectively. After an attempted injection, the attacker logs into the site as the newly created user. What they do, if successful, is a mystery. Each attack we recorded above was mitigated by the Sucuri Firewall. We are however noticing an interesting trend with Drupal 7 sites that we’re providing remediation services to. Attackers are using them to inject SEO spam which also corresponds to the increase in Search Engine Poisoning (SEP) attacks we have been seeing in our Hacked Website Trend Report Q1/2016.

Taking Security Seriously

If you are responsible for a website, Drupal or not, you have to take security seriously. It is your responsibility to patch, monitor, and follow good security practices. If your Drupal site has been hacked, you can follow our free guide to fixing hacked Drupal sites.