Exploit in the Wild: #drupalgeddon2 - Analysis of CVE-2018-7600

About CVE-2018-7600
On 28 March 2018, the Drupal core security team released security advisory SA-CORE-2018-002 which discusses a highly critical vulnerability CVE-2018-7600, later nicknamed drupalgeddon2. The vulnerability is present on all Drupal versions 7.x before 7.58, 8.3.x versions before 8.3.9, 8.4.x versions before 8.4.6, and 8.5.x before 8.5.1.
The vulnerability is estimated to impact over one million Drupal users and websites. The vulnerability can enable remote code execution and results from insufficient input validation on the Drupal 7 Form API. Attacks against Drupalgeddon2 target AJAX requests composed of Drupal Form API’s renderable arrays, which are used to render a requested page through Drupal’s theming system.
An attacker can use this vulnerability to force the server running Drupal to execute malicious code that could completely compromise the Drupal installation. Depending on the specific configuration, this could potentially compromise the host machine as well. This vulnerability is particularly critical due to the fact that there is nothing mitigating access to the vulnerability: an anonymous user use this to execute code remotely without authentication.
 
Analysis of Vulnerability Root Cause
“Renderable Arrays” were formally introduced in Drupal 7. These structures are implemented by an associative array and pass key-value pairs as function arguments or form data in order to render markup and UI elements in a meaningful way. Markup element properties have keys prefixed with the ‘#’ character. Below is an example of render array used in a normal PHP function.

Figure 1. Drupal core example of render array key-value pairs

 
A quick examination of the Drupal security patch revealed the addition of a class called RequestSanitizer. Of note is the method stripDangerousValues, which is called in another method called sanitize. The previous function stripped a control character, ‘#’, from index zero of an array parameter. Below is a snippet of the patch function.

Figure 2. Drupal patch stripping ‘#’ from parameterized input

 
Based on the content of the patch from the Drupal security team and analysis of Drupal’s Form API, Unit 42 researchers at Palo Alto Networks were able infer that certain Form API functions must be able to execute arbitrary code and that input sanitization for parameters passed with a leading ‘#’ character is necessary to try and prevent code execution attacks. In order to exploit this vulnerability, the exploit code had to target the rendering phase of either a page load or AJAX request with malicious code passed to one of the Form API executable functions.
The four exploitable Form API functions we determined to have potential for remote code execution are:

• [#post_render]
• [#pre_render]
• [#access_callback]
• [#lazy_builder]

 
Exploit Method Analysis
Public Exploits
Reports from Drupal experts in coordination with security researchers indicated that the default configuration, including a majority of fully developed configurations, has fields in the new user registration page that were not correctly sanitized prior to the Drupal patch. The default page at /user/register can be forced to send a specifically crafted AJAX request that can target a variety of form fields, including ones affected by the vulnerability and thus execute the attacker’s code.
Proof-of-concept (POC) code was released into the wild confirming these findings on April 12, 2018. Initial POC targeted the mail[] array utilizing the #post_render function to execute the PHP function exec, which executes underlying operating system functions in the context of the web server user.
Below is traffic captured to a vulnerable Drupal instance at local address 10.3.228.197. The PHP command it used is exec, and the payload is a simple wget command to an outside IP address 172.217.6.36.

Figure 3. Drupal server exploited and beaconing to http://www.google.com

 
Exploitation for known POCs is possible when passed by both POST content types: application/x-www-form-urlencoded and multipart/form-data.

Figure 4. x-www-form-urlencoded form data payload

 
A second POC found in the wild targets the timezone form field. The server responds with a HTTP 500 Service unavailable response, although the exploitation is successful.

Figure 5. Exploit utilizing timezone and #lazy_builder function

Figure 6. Timezone, #lazy_builder via multipart/form-data

 
The first publicly available POCs to appear have only been effective on vulnerable Drupal 8.x instances due to the default configuration of the /user/register page on 8.x versus 7.x. Other default configuration URIs include the /user/password page, which can exploit 7.x versions successfully. This particular exploit targets the _triggering_element_name form and requires two requests to be sent.
 

Figure 7. Drupal 7.x exploitation via two HTTP requests

 
At the time of this analysis, exploits in the wild are attempting to call wget, curl, and other second-stage mechanisms on malicious payloads in order to initiate a takeover of Drupal sites. As with any remote code execution vulnerability, weaponized payloads containing reverse shells, backdoors, botnets, and even crypto-miners have been detected in the wild.
Palo Alto Networks Next Generation Firewall signatures prevent these POC in-the-wild exploits, as well as the potential exploits described below.
 
Potential Exploits
Nearly all publicly available POC samples exploited vulnerable instances of Drupal by passing a render array key of [#post_render][] with a value of the PHP function exec, followed by a second key-value pair [#markup] with a value of an operating system function to be called by exec.
However, other successful exploits can and do take advantage of the four Form API functions listed above ([#post_render], [#pre_render], [#access_callback], and [#lazy_builder]).
In the interest of signature development, we at Palo Alto Networks cover traffic exploiting these API functions, as well as other ‘dangerous’ PHP functions that may be exploited. PHP functions that should be screened include:

• Exec
• ` (backtick)
• $ (dollar)
• system
• popen
• pcntl_exec
• eval
• preg_replace
• create_function
• include
• require
• passthru
• shell_exec
• proc_open
• assert
• include_once
• require_once
• $_GET
• $_POST
• $_SERVER
• $_FILES
• $_REQUEST
• $_SESSION
• $_ENV
• $_COOKIE

Aside from exec, malware samples in the wild include system, passthru, and eval. It is certainly possible that more elaborate attackers will be able to craft requests to take advantage of these functions.

Exploit Samples in the Wild

 
Conclusion and Mitigation
CVE-2018-7600 is in the wild and there is a great possibility that it will be exploited continuously in the future. Be sure to follow the instruction from Drupal Groups: https://groups.drupal.org/security/faq-2018-002.
Palo Alto Networks customers are protected from this vulnerability by the following products and services:

1. Threat Prevention Signature 40627 that identifies HTTP requests containing the exploit code.
2. PAN-DB blocks attacker’s C&C server IP and domain
3. WildFire and Antivirus identifies and blocks exploitation payload

 
Timeline

1. 28 March 2018 - CVE public disclosure / Drupal patch
2. 12 April 2018 – First PoC released into wild
3. 12 April 2018 – Palo Alto Networks released Threat Prevention Signature 40627
4. 13 April 2018 - Palo Alto Networks updated Threat Prevention Signature 40627
5. 16 April 2018 – Palo Alto Networks coverage improved via honeypot malware targeting vulnerability