转：Uncovering Drupalgeddon 2（cve-2018-7600）漏洞深度解析

Posted 2020-11-01 studyskill

转：https://research.checkpoint.com/uncovering-drupalgeddon-2/

By Eyal Shalev, Rotem Reiss and Eran Vaknin

Abstract

Two weeks ago, a highly critical (25/25 NIST rank) vulnerability, nicknamed Drupalgeddon 2 (SA-CORE-2018-002 / CVE-2018-7600), was disclosed by the Drupal security team. This vulnerability allowed an unauthenticated attacker to perform remote code execution on default or common Drupal installations.

Drupal is an open-source content management system (CMS) that is used by more than one million sites around the world (including governments, e-retail, enterprise organizations, financial institutions and more), all of which are vulnerable unless patched.

Until now details of the vulnerability were not available to the public, however, Check Point Research can now expand upon this vulnerability and reveal exactly how it works.

In brief, Drupal had insufficient input sanitation on Form API (FAPI) AJAX requests. As a result, this enabled an attacker to potentially inject a malicious payload into the internal form structure. This would have caused Drupal to execute it without user authentication. By exploiting this vulnerability an attacker would have been able to carry out a full site takeover of any Drupal customer.

The vulnerability existed on all Drupal versions from 6 to 8, though has since been patched to those who manually update their site. In this document we will showcase real life attack scenarios around an out-of-the-box installation of Drupal’s flagship product, Drupal 8.

Technical Details

The Vulnerability

To provide some background, Drupal’s Form API was introduced in Drupal 6 and allowed alteration of the form data during the form rendering process. This revolutionized the way markup processing was done.

In Drupal 7 the Form API was generalized to what is now known as “Renderable Arrays”. This extended API is used to represent the structure of most of the UI elements in Drupal, such as pages, blocks, nodes and more.

Renderable arrays contain metadata that is used in the rendering process. These renderable arrays are a key-value structure in which the property keys start with a hash sign (#). Please see below for an example:

[
‘#type’ => ‘markup’,
‘#markup’ => ‘<em>some text</em>’,
‘#prefix’ => ‘<div>’,
‘#suffix’ => ‘</div>’
]

Drupal’s Patch

The patch that Drupal published adds a single class called RequestSanitizer with a stripDangerousValues method that unsets all the items in an input array for keys that start with a hash sign. This method sanitizes input data in $_GET, $_POST & $_COOKIES during the very early stages of Drupal’s bootstrap (immediately after loading the site configurations).

We assume that one of the reasons that the patch was done in this way was to make it harder to find and exploit the vulnerability.

Finding an Attack Vector

Because of the above we focused on forms that are exposed to anonymous users.

There are a few of those forms available, one of which is the user registration form. This form contains multiple fields, as can be seen in the screenshot below.

Figure 1: The Drupal registration form.

We knew that we needed to inject a renderable array somewhere in the form structure, we just had to find out where.

As it happens, the “Email address” field does not sanitize the type of input that it receives. This allowed us to inject an array to the form array structure (as the value of the email field).

Figure 2: Injecting our renderable array into the mail input of the registration form.

Figure 3: Example of injected form renderable array.

Now all we needed was for Drupal to render our injected array. Since Drupal treats our injected array as a value and not as an element, we needed to trick Drupal into rendering it.

The situations in which Drupal renders arrays are as follows:

1. Page load
2. Drupal AJAX API – i.e. when a user fills an AJAX form, a request is made to Drupal which renders an html markup and updates the form.

After investigating possible attack vectors surrounding the above functionalities, because of the post-submission rendering process and the way Drupal implements it, we came to the conclusion that an AJAX API call is our best option to leverage an attack.

As part of the user registration form, the “Picture” field uses Drupal’s AJAX API to upload a picture into the server and replace it with a thumbnail of the uploaded image.

Figure 4: Form used to upload a picture using AJAX API.

Diving into the AJAX file upload callback revealed that it uses a GET parameter to locate the part of the form that needs to be updated in the client.

Figure 5: The AJAX ‘upload file’ callback function code.

After pointing element_parents to the part of the form that contained our injected array, Drupal successfully rendered it.

Weaponizing Drupalgeddon 2

Now, all we had to do is to inject a malicious render array that uses one of Drupal’s rendering callback to execute code on the system.

There were several properties we could have injected:

• #access_callback
  Used by Drupal to determine whether or not the current user has access to an element.
• #pre_render
  Manipulates the render array before rendering.
• #lazy_builder
  Used to add elements in the very end of the rendering process.
• #post_render
  Receives the result of the rendering process and adds wrappers around it.

For our POC to work, we chose the #lazy_builder element as the one being injected into the mail array. Combined with the AJAX API callback functionality, we could direct Drupal to render our malicious array.

This allowed us to take control over the administrator’s account, install a malicious backdoor module and finally execute arbitrary commands on the server.

Figure 6: injecting malicious command into one of Drupal’s rendering callbacks.

                         Figure 7: Successfully executing shell commands using the malicious module.

Conclusion

After seeing earlier publications on Twitter and several security blogs, it was apparent that there was much confusion among the community regarding this vulnerability announcement, with some even doubting the severity of it. As a result, we considered it worthwhile to looking deeper into.

The research however was challenging as we were starting from a very large attack surface since the patch blurred the real attack vectors. To expedite our findings, we were fortunate to be joined by experts in the Drupal platform. The final results highlight how easy it is for organization to be exposed through no fault of their own, but rather through the third party platforms they use every day.