“Drupalgeddon2”: Drupal Module Configuration Vulnerability CVE-2018-7600
Date Added to KEV Catalog: November 3, 2021
CISA Due Date for Remediation: May 3, 2022
Table of Contents
On March 28, 2018 Drupal announced a remote code execution vulnerability on specific Drupal versions of 6, 7 and 8. This is a highly critical vulnerability that has numerous public exploits from Exploit-DB, Metasploit and GitHub (further details in Exploitation section).Jasper Mattson located the vulnerability.
CVE-2018-7600 is also known as Drupalgeddon2 and is described in SA-CORE-2018-002 (a Drupal security advisory). A few weeks later Drupalgeddon3 emerged as CVE-2018-7602 and was described in SA-CORE-2018-004.
Drupal is popular, free and open-source content management system software written in PHP and used by over a million websites across the world. Content management systems are used to create, edit, publish, and manage websites.
Tenable Nessus has a clear description of the vulnerability:
“The problem is that Drupal core accepts request parameters as array objects. While this is functionally no different than many other frameworks, a malicious user can pass an array object to the application with a keynote containing a payload. Drupal will process this without sanitization. A successful exploit attempt results in the potential compromise of the application and even the underlying operating system.” (Source)
Checkpoint further explains:
“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.” (Source)
Systems Affected and Detection
CVE-2018-7600 affects, per the Drupal Security Advisory:
>=7.0 <7.58 || >= 8.0.0 <8.3.9 || >=8.4.0 <8.4.6 || >=8.5.0 <8.5.1
CVE-2018-7600 is referred to as Drupalgeddon2 because over one million sites were vulnerable when this exploit was made public in March 2018. The sheer number of vulnerable sites was followed by various public exploits available just two weeks after the initial Drupal security advisory.
Drupal versions can often be checked by accessing the CHANGELOG.txt: domain.site/CHANGELOG.txt
Tenable Nessus has various plugins that check for CVE-2018-7600.
There are also CVE-2018-7600 scanners on GitHub, like fyraiga’s Drupalgeddon2 Scanner, which check versions prior to Drupal 8.
The Metasploit module exploit/unix/webapp/drupal_drupalgeddon2 with the “check” command can test Drupal 6.x, < 7.58, 8.2.x, < 8.3.9, < 8.4.6, and < 8.5.1 for this vulnerability
Vulnerable Environment Setup
A vulnerable Drupal environment can be setup through dockers or iso images. Note: use caution with publicly available images.
- Drupal Docker, searching versions by tags: https://hub.docker.com/_/drupal
- Drupal Docker via GitHub’s Vulhub (version 8.5): https://github.com/vulhub/vulhub/tree/master/drupal/CVE-2018-7600
- Drupal iso images: http://mirror.turnkeylinux.org/turnkeylinux/images/iso/
- Drupal 7.54: http://mirror.turnkeylinux.org/turnkeylinux/images/iso/turnkey-drupal7-14.2-jessie-amd64.iso
Older Drupal versions show their version history through the file CHANGELOG.txt. Wappalzer, the Linux “curl” command, and View Page Source also distinguish between Drupal 6, 7, and 8.
In the Vulhub Drupal environment (Drupal version 8.5), CHANGELOG.txt is not accessible, but View Page Source and Wappalzer show Drupal 8. The “curl” command and Web Developer Tools both show HTTP response headers which show Apache and PHP versions. The Apache and PHP versions can possibly infer the specific Drupal version.
The “curl” command confirms the following information:
- Apache 2.4.25 (released December 20, 2016)
- PHP 7.2.3 (released March 1, 2018)
- Drupal 8
PHP 7.2.3’s March 2018 release date can be used to approximate which Drupal version is used. Drupal 8 versions released in March 2018 include:
Assuming a March 2018 Drupal 8 version (not always the case), the above Drupal 8 versions can be compared to vulnerable Drupalgeddon2 and Drupalgeddon3 versions.
Drupalgeddon2 (CVE-2018-7600): >= 8.0.0 <8.3.9 || >=8.4.0 <8.4.6 || >=8.5.0 <8.5.1
Drupalgeddon3 (CVE-2018-7602): >=7.0 <7.59 || >= 8.0.0 <8.4.8 || >=8.5.0 <8.5.3
- 8.5.1 – 28 March 2018 >=8.5.0 <8.5.3 Drupalgeddon3 (CVE-2018-7602)
- 8.4.6 – 28 March 2018 >= 8.0.0 <8.4.8 Drupalgeddon3 (CVE-2018-7602)
- 8.3.9 – 28 March 2018 >= 8.0.0 <8.4.8 Drupalgeddon3 (CVE-2018-7602)
- 8.3.8 – 12 March 2018 >= 8.0.0 <8.3.9 Drupalgeddon2 (CVE-2018-7600)
- 8.5.0 – 7 March 2018: >=8.5.0 <8.5.1 Drupalgeddon2 (CVE-2018-760) and >=8.5.0 <8.5.3 Drupalgeddon3 (CVE-2018-7602)
This process isn’t guaranteed to identify the specific Drupal version but shows that all March 2018 Drupal 8 versions are vulnerable to either CVE-2018-7600, CVE-2018-7602, or both.
There are various ways to exploit CVE-2018-7600. The most common options are public exploits through Exploit-DB, GitHub, or a Metasploit module. Searching for public exploits saved on Kali Linux through the “searchsploit” command shows ruby and python scripts for various Drupal versions: searchsploit Drupalgeddon2 OR searchsploit Drupal 8
Github also has various public exploits, include a list of 7 proof-of-concept exploits.
GitHub POC Exploit Example
The Drupal Login page has a /user/register page by clicking “create new account”. One example, by a2u, exploits the Forms API AJAX request by sending a POST request from user email registration.
POST /user/register?element_parents=account/mail/%23value&ajax_form=1&_wrapper_format=drupal_ajax HTTP/1.1
This updates the form_id, sending the “id” command:
Burp Suite shows the POST request successfully ran the “id” command and shows the user www-data:
More information can be found here: https://github.com/vulhub/vulhub/tree/master/drupal/CVE-2018-7600Metasploit Example
The Metasploit module exploit/unix/webapp/drupal_drupalgeddon2 exploits a Drupal property injection in the Forms API. It affects: Drupal 6.x, < 7.58, 8.2.x, < 8.3.9, < 8.4.6, and < 8.5.1.
Select the module using # or full path to module name.
Above: use 1 OR use exploit/unix/webapp/drupal_drupalgeddon2
For the Vulhub Docker environment:
set RHOSTS 127.0.0.1
set RPORT 8080
set VERBOSE true
LHOST and LPORT should automatically be set, the “check” command can be used prior to exploit to test:
Exploiting the Metasploit module shows access as user www-data with the Meterpreter command “getuid”:
For this specific CVE, upgrading to 7.58 or 8.5.1 fixes this vulnerability. Best practice is to update to the most recent version of Drupal Core.