Recent Drupal Vulnerabilities

Hours after Drupal released a patch in April, 2018, attackers had already created and shared proof-of-concept exploit code resulting in over one million vulnerable sites. This news came four weeks after disclosure of Drupalgeddon 2, which was another major remote code execute vulnerability. Installing patches and updating your WAF rules can help you prevent attackers from exploiting this vulnerability to take control of your servers.

What happened?

On March 28, 2018, Drupal disclosed a critical flaw that affected Drupal versions 7.x, 8.3.x, 8.4.x, and the latest 8.5.x versions labeled sa-core-2018-002, also known as CVE-2018-7600 and Drupalgeddon 2. The vulnerability was classified as a remote code execution (RCE) bug, which based on the patch, seemed to be sanitizing keys that start with the # character, specifically because of this line:

if ($key !== '' && $key[0] === '#' && !in_array($key, $whitelist, TRUE))

As Drupal’s security researchers started studying sa-core-2018-002 further, they discovered a new vector for exploitation, which resulted in sa-core-2018-004 — a new remote code execution vulnerability. Drupal released a new patch on April 25, 2018 to address the new critical RCE. The updated patch required the users to have the patch for sa-core-2018-002 applied. Merely five hours later, attackers had found a way to weaponize this patch and wasted no time actively exploiting CVE-2018-7602, affectionately known as Drupalgeddon 3.

Currently there are a handful of proof-of-concept exploits available in Python and Ruby, as well as a Metasploit module.

How bad is this vulnerability, really?

According to the Drupal project usage information this vulnerability affects over one million sites, or about 9% of sites that are running a known CMS. Based on the Drupal security team’s FAQ and independent researchers, we can summarize the following:

An anonymous user visiting a Drupal site can exploit the vulnerability
The attack allows access to non-public data
The attacker can modify or delete all the website data

This vulnerability may result in the following attacker behavior:

Stealing all the information, including personal data, from your website
Using your website to distribute malicious information
Using your website to attack other organizations
Deleting your Drupal installation
Defacing your site
And let’s not forget all the fun potential of a webshell...

You get the point, it is a nasty bug!

Since the disclosure of sa-core-2018-002, there has been another patch released, sa-core-2018-004 — which looks like an evolutionary patch for sa-core-2018-002 — further addressing newly discovered remote code execution (RCE) vectors.

Which Drupal instances are vulnerable?

The vulnerabilities have been dubbed “Drupalgeddon 2” and “Drupalgeddon 3” for a very good reason: like the prequel, Drupalgeddon 1, which was a pretty nasty SQLi, they impact Drupal versions 7.x, 8.3.x, 8.4.x, and the latest 8.5.x.

Not only can this latest vulnerability be exploited by any unauthenticated user, exploitation results in arbitrary RCE. Exploit methods were disclosed in mid April, but even before then, Fastly’s security research team immediately started noticing probes for fingerprint Drupal installations against our public honeypots around the time of the bug disclosure. Some example logs look like this:

x.15.53.83 - - [28/Mar/2018:14:56:58 -0400] "GET /index.php?option=com_user&task=register HTTP/1.1" 404 207 "-" "Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1" "ct:text/html"
x.15.53.83 - - [28/Mar/2018:14:57:00 -0400] "GET /user/register HTTP/1.1" 404 211 "-" "Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1" "ct:text/html"
xx.99.33.103 - - [28/Mar/2018:14:58:00 -0400] "GET /index.php?option=com_user&task=register HTTP/1.1" 404 207 "-" "Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1" "ct:text/html"
xx.99.33.103 - - [28/Mar/2018:14:58:02 -0400] "GET /user/register HTTP/1.1" 404 211 "-" "Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1" "ct:text/html"
x.36.27.6 - - [28/Mar/2018:14:58:50 -0400] "GET /index.php?option=com_user&task=register HTTP/1.1" 404 207 "-" "Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1" "ct:text/html"

We assume that attackers were preparing a map of Drupal installations that they could exploit once details surfaced and once they had a working exploit.

Mitigation: What can you do?

Patch it up! The Drupal team provided patches for not only the currently supported versions of Drupal, but also older unsupported versions like 6.x. Patching is the preferred method for mitigation. The Core Ruleset team quickly provided the community with a Modsec rule.

Here at Fastly, our SOC authored rules after analyzing the vulnerability notes and patch. If you’re using the Fastly WAF, we recently released these rules as part of configuration set v8 in our Web Application Firewall (Rules 4170000, and 4170001). If you have a Drupal installation, you owe it to yourself to update, or the very least turn on this rule in logging mode in your WAF to inspect for attack traffic.

Here’s is the Modsec syntax for the rules:

SecRule ARGS_NAMES|FILES_NAMES "@rx ^#" \
	"id:4170000,\
	phase:2,\
	deny,\
	capture,\
	t:urlDecodeUni,\
	log,\
	msg:'Field name begins with #, potential Drupal 2018-002 attack',\
	logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
	tag:'CVE-2018-7600',\
	tag:'application-Drupal',\
	tag:'attack-rce',\
	tag:'drupal-2018-001',\
	tag:'language-php',\
	tag:'platform-multi',\
	rev:1"

SecRule ARGS|ARGS_NAMES "@rx .+\[#(post_render|markup|type)\]" \
	"id:4170001,\
	phase:2,\
	deny,\
	capture,\
	t:urlDecodeUni,\
	log,\
	msg:'Nested field name begins with #, potential Drupal attack',\
	logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
	tag:'CVE-2018-7600',\
	tag:'CVE-2018-7602',\
	tag:'application-Drupal',\
	tag:'attack-rce',\
	tag:'drupal-2018-001',\
	tag:'drupal-2018-002',\
	tag:'language-php',\
	tag:'platform-multi',\
	rev:1"

To update to the new config set run this:

curl -XPATCH -v https://api.fastly.com/wafs/configuration_sets/552NEtnDyzucKd3vTjLgFC/relationships/wafs" \ 
-H "Content-Type: application/vnd.api+json" \
-H "Accept: application/vnd.api+json" \
-H "Fastly-Key:$FASTLY_TOKEN" \
-d '{"data": [{"id": "<WAFID>","type": "waf”}]}'

Then turn this rule on via these steps:

Set the rule status
curl -XPATCH -v "https://api.fastly.com/service/<SERVICEID>/wafs/<WAFID>/rules/<RULEID>/rule_status" \ -H"Fastly-Key:$FASTLY_TOKEN" \ -H"Content-Type: application/vnd.api+json" \ -H"Accept:application/vnd.api+json" \ -d '{ "data": { "attributes": { "status": "block" }, "id": "<WAID>-<RULEID>", "type": "rule_status" } }'
Patch the rule set
curl -XPATCH -v "https://api.fastly.com/service/<SERVICEID>/wafs/<WAFID>/ruleset" \ -H"Fastly-Key:$FASTLY_TOKEN" \ -H"Content-Type: application/vnd.api+json" \ -H"Accept:application/vnd.api+json" \ -d '{ "data": {"id": "<WAFID>","type": "ruleset"} }'

TL;DR

Drupalgeddon came back again (and again), but installing patches and updating your WAF rules can help you prevent attackers from exploiting this vulnerability to take control of your servers.