Drupalgeddon Two.

2018-04-2019:31:22

Wallarm

lab.wallarm.com

1033

EPSS

0.976

Percentile

100.0%

JSON

New Drupal Vulnerability in Detail

By @aLLy

The second Drupalgeddon has come! It is a new variant of a critical vulnerability in one of the most popular CMSs, which caused a big stir. This newly-discovered breach allows any unregistered user execute commands in the target system by means of a single request.

The problem is further aggravated by the fact that it puts all the most current versions of the application (7.x and 8.x branches, up to 8.5.0) under threat. The number of potentially exploitable targets is very high.

INFO

The assigned ID for the vulnerability is CVE-2018–7600. It has the highest threat level (“highly critical”).

The developers have issued a patch as on March 28, 2018, however, as recently as April 12, there were still no links to PoC or the detailed description of the problem in the Drupal public domain. It should be noted that the patch suggested by the developers was also very laconic and gave no indication as to where the vulnerability could be discovered. The application is easily installed; moreover, Drupal has an official repository at Docker Hub, and the deployment of a container with the required CMS version only takes a couple of well documented commands. Personally, I like to use JetBrains PhpStorm for debugging.

Given that the cat is out of the bag, let’s take a critical look at this exploit and study it more closely.

Deep Dive

First, let’s take a look at the patch which fixes the vulnerability.

Drupalgeddon 2 vulnerability patch commit

Cool, isn’t it? The developers have simply added filtering of all data submitted by users.

However, this patch can shed some light on the nature of the vulnerability. Pay attention to the code of the checking procedure: the data is handled by the method sanitize, which invokes stripDangerousValues.

/core/lib/Drupal/Core/DrupalKernel.php

545: public function preHandle(Request $request) {  
546: _// Sanitize the request.  
_547: $request = RequestSanitizer::sanitize(  
548: $request,  
549: (array) Settings::get(RequestSanitizer::SANITIZE_WHITELIST, [])

/core/lib/Drupal/Core/Security/RequestSanitizer.php

40: public static function sanitize(Request $request, $whitelist, $log_sa  
…  
44: $request-&gt;query-&gt;replace(static::stripDangerousValues($request-&gt;q

This method, in turn, executes verification of all the submitted parameters. Zero values beginning with # and values that were not whitelisted are stripped.

/core/lib/Drupal/Core/Security/RequestSanitizer.php

84: protected static function stripDangerousValues($input, array $whiteli  
85: if (is_array($input)) {  
86: foreach ($input as $key =&gt; $value) {  
87: if ($key !== ‘’ && $key[0] === ‘#’ && !in_array($key, $whitelis  
88: unset($input[$key]);  
89: $sanitized_keys[] = $key;  
90: }  
91: else {  
92: $input[$key] = static::stripDangerousValues($input[$key], $wh  
93: }  
94: }  
95: }  
96: return $input;  
97: }

What are those “mystic” parameters beginning with an pound sign? They are special placeholders for Drupal Render API. This API was introduced in the version 7.0 of the CMS and is used for rendering structured data into HTML markup.

Before the rendering phase, the data required for creating the requested page and its individual blocks is stored in the form of special arrays. This provides ample opportunities for changing the markup or the content of the page at any time during the page load or right after.

Render API implements so-called Renderable Arrays (or Render Arrays). They are structured arrays, that provide data along with hints as to how this data should be rendered (presented) for the user. Keys with the hash symbol (#) are the properties used by the rendering interpreter.

There is a set number of pre-defined properties, such as form, html_tag, value, markup, etc. Most them are described in the official Forms API whitepapers.

For the purposes of studying of Drupalgeddon 2 vulnerability, we are interested in the properties which invoke call_user_func during processing. Among them are #pre_render, #post_render, #access_callback, #submit, #lazy_builder, #validate. To demonstrate how exploit works, I’m using the key #post_render. The processing of this element is described in the Renderer.php.

/core/lib/Drupal/Core/Render/Renderer.php

500: if (isset($elements[‘#post_render’])) {  
501: foreach ($elements[‘#post_render’] as $callable) {  
502: if (is_string($callable) && strpos($callable, ‘::’) === FALSE  
503: $callable = $this-&gt;controllerResolver-&gt;getControllerFromDefi  
504: }  
505: $elements[‘#children’] = call_user_func($callable, $elements[  
506: }  
507: }

Now we need to find a point where user data is submitted to the function render, so we can incorporate this property with the desirable parameters. It’s best if we focus on points that are accessible to unauthorized users, as we know that exploitation of the vulnerability does not require authentication or rights.

/core/lib/Drupal/Core/Render/Renderer.php

182: public function render(&$elements, $is_root_call = FALSE) {  
…  
194: try {  
195: return $this-&gt;doRender($elements, $is_root_call);  
…  
207: protected function doRender(&$elements, $is_root_call = FALSE) {

Drupal is huge, and search for such points can take a while, so I won’t bore you with this task (given that the Check Point experts have discovered all that there is to discover already). On registering a new user, the CMS allows you to upload anavatar.

Let’s create a new account and upload some picture after routing the traffic through a proxy.

User avatar upload request