28 Days After Drupal Exploit

A a critical Drupal security exploit was released in October 2014. Critical vulnerabilities in the core of content management systems are not as common as they once were, as can be seen in the amount of media coverage that this one generated.

Drupal Data Survey

Using a custom Nmap NSE script I surveyed the top 10 thousand sites that are powered by Drupal. Expecting to find a number of sites that had not been patched the actual number (57.5%) found still surprised me. After all this is not a random selection of Drupal sites, these are typically high traffic sites that I would expect to have some level of ongoing maintenance. The survey was conducted 28 days after the public release on 15th of October 2014.

Understanding the Results

The easiest way to determine the exact version of a Drupal powered site is to examine the CHANGELOG.txt file in the root of the site. This is a file that can be removed to make fingerprinting the exact version of the site more difficult. An Nmap NSE script was customised for this purpose and used this method to determine the version.

5630 out of the full 10'000 had the CHANGELOG.txt file in place enabling the exact version detection to take place. Of these I separated Drupal 6 and Drupal 7 installs to determine the percentage of Drupal 7 installs that have been patched.

The bar graph pictured in the graphic show the totals found for each of the categories, these are the total sites within the 5630 that were successfully fingerprinted.

Updated to show the distribution of versions in use

This chart shows a break down of the versions found. Staying focused on Drupal 7 it shows there are a range of Drupal version 7 releases in use. Some of these may have been patched manually, however I would be confident in predicting the majority of these older versions have not had security patches applied.

A number of responses in the comments have indicated that 7.31 installs may have been patched manually, fixing the vulnerability without updating the CHANGELOG.txt. Looking closer at the results we could remove both 7.32 and 7.31 from the Drupal 7 installs, and still find 49% of Drupal 7 installations in the top 10'000 sites to be potentially (likely?) vulnerable.

Vulnerable Drupal Installations in the Top 10K

The need for better management

The key point from this experiment is systems that are not regularly maintained and updated when patches become available will be a liability for any organization. Ensure a process is in place for updating all software including web applications and add-ons.

If you do not have the expertise or time to patch your web applications consider getting a managed hosting provider that does the job for you.

In Aug 2014 a spacecraft landed on a comet, is patching really that hard?