Drupalgeddon 2.0: Why is this vulnerability highly critical?

Drupal warned of a highly critical flaw in its open source content management system platform that allowed attackers to take over websites. According to Drupal, over one million sites running the Drupal CMS were affected. What is the Drupal vulnerability, and why is it so dangerous?

A highly critical security vulnerability that affects such a large user base has the potential to disrupt large sections of the internet and put millions of users at risk. According to Drupal project usage information, over one million sites were at risk.

Dubbed Drupalgeddon 2.0, the Drupal-specific identifier for the issue is SA-CORE-2018-002, which assigns it a risk level of highly critical. This is based on the National Institute of Standards and Technology's Common Misuse Scoring System, on which the Drupalgeddon 2.0 vulnerability scored a 24 out of a possible 25.

An anonymous remote user can easily exploit this vulnerability to completely compromise a server, which is the reason for the high score. Ever since the proof of concept exploit code was released, hackers have been scanning for vulnerable sites, with many looking to install cryptomining malware.

This unauthenticated remote code execution vulnerability was uncovered by Jasper Mattsson, a Drupal developer, and it is caused by inadequate validation of user-supplied data received via Form API Ajax property requests.

This lack of validation can enable an attacker to inject a malicious payload into the internal form structure, allowing it to be executed without user authentication.

The # symbol has a special meaning within Drupal's code, but when the request parameters are sent as an array, there is no check to ensure that the array keys don't begin with the # character. This lack of validation can enable an attacker to inject a malicious payload into the internal form structure, allowing it to be executed without user authentication.

The patched versions of Drupal remove the # character from the parameter key names that begin with a # supplied through a GET, POST or a cookie before passing the sanitized request to the application code. This sanitization can also be done at the network layer, and many cloud hosting and service providers have implemented the same logic in their perimeter defenses to reject requests containing such values.

The Drupalgeddon 2.0 vulnerability was present in Drupal versions 6.x, 7.x and 8.x. It is essential that administrators update to the latest version -- 7.58 or 8.5.1 or higher -- and then complete an audit to see if their site was compromised.

Given the potential severity of this issue, there are fixes provided for unsupported minor releases, and even though Drupal 6 reached end-of-life status, the Drupal 6 Long Term Support project has patches available. Likewise, Drupal provides a general guide for those who fear their site may have been hacked.

Just updating Drupal will not remove any malware that has already been installed; a full restore from a clean backup is necessary. Finally, if they haven't done so already, developers and site administrators should subscribe to the Drupal security newsletter to stay abreast of any further developments.

Ask the expert:
Want to ask Michael Cobb a question about application security? Submit your questions now via email. (All questions are anonymous.)