Building a slide deck, pitch, or presentation? Here are the big takeaways:

  • An oversight that led to inputs not being sanitized was patched on Wednesday by Drupal.
  • The vulnerability is extremely trivial to exploit, making patching active installations critical.

A failure to sanitize inputs prompted a round of emergency patching for Drupal on Wednesday. The patch was announced a week in advance to give administrators time to prepare due to concerns that exploits “might be developed within hours or days” of the release of the patch.

The vulnerability relates to a conflict between how PHP handles arrays in parameters, and Drupal’s use of the hash (#) at the beginning of array keys to signify special keys that typically result in further computation, leading to the ability to inject code arbitrarily, according to Drupal’s security advisory. Exploiting this vulnerability does not require any authentication, only visiting a page with a maliciously-crafted URL is necessary.

SEE: System update policy (Tech Pro Research)

As a result, the patch does nothing more than add a sanitation check to /includes/ in the Drupal installation. Patches were supplied for the 8.5.x and 7.x branches, as well as the otherwise unsupported 8.4.x, 8.3.x, and 6.x branches of the software, the advisory said. According to Drupal’s usage statistics page, the software powers about 1.1 million websites.

While there is no known exploit in the wild when the patch was released, according to Drupal, the vulnerability was given a severity score of 21 out of 25. It was originally discovered by Druid researcher Jasper Mattsson, and is assigned the ID CVE-2018-7600 by MITRE, SA-CORE-2018-002 by Drupal, and “Drupalgeddon 2: Electric Hashaloo” by noted programmer Scott Arciszewski, among other members of the Drupal community.

The importance of software updates

Software updates for content management systems are particularly important, given the public-facing nature of such platforms, and the amount of damage that can be done if an attacker takes control of one. Unsecured CMS installations have led to the mass implanting of JavaScript-based cryptocurrency mining attacks, which have exploded in popularity in the first quarter of 2018.

In the case of Drupal, the original “Drupalgeddon” vulnerability from 2014 has been viewed as a significant part of how the “Panama Papers” documents relating to the now-defunct law firm Mossack Fonseca were exfiltrated from the organization. The Panama Papers was a release of 11.5 million documents–totaling 2.6 terabytes of data–detailing attorney-client information for over 200,000 offshore entities, some of which were established as tax avoidance schemes.

The client portal operated by Mossack Fonseca was found to be using Drupal 7.23, released in August 2013, when the story broke in April 2016. Drupal was running on Oracle’s fork of Apache 2.2.15, from March 6, 2010. The default settings in Oracle Apache web server allow viewing the directory structure. As Drupal files use the .module file extension, which is not executed by default in Apache, any user is able to view the source of the module files as plain text, as well as view the directory in which module files are placed. This led to the discovery of the “portfolio” module which was seemingly intended to allow clients to view their files.