28 Days After Drupal Exploit

Last month a critical Drupal security exploit was released. 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.

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 that 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 we 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 in this experiment is that systems that are not regularly maintained and updated when patches become available will be a liability for your organization. Ensure you have a process in place for updating all your 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.

Today a spacecraft landed on a comet, is patching really that hard?

7 Responses to 28 Days After Drupal Exploit

  1. e70838 November 13, 2014 at 2:12 pm #

    I have patched my site 12 hour after public disclosure. 36 hours later, when I have received the mail saying that a new release of drupal core was available, I have checked its content. There was nothing more than the patched line. I have not installed it. If you see 7.31 in CHANGELOG.txt, it already means that the site is regularly updated (7.30 was 2 weeks before 7.31). I think many site administrators have only installed the patch.

  2. Greg Knaddison November 13, 2014 at 2:49 pm #

    I agree with e70838 that your method of detection is not accurate. Instead of saying “57.5%” you should say “No more than 57.5%” or “Up to 57.5%”. Of course, that makes for a weaker headline and less attention for the post.

    It’s also likely that many of these sites are protected in some other manner (custom WAF rules for their site, CloudFlare, another commercial CDN/WAF provider, or protections from one of the hosting providers that had platform-level protection).

    I agree with your overall message that people need to get better about automating their merge/test/deploy processes so that they can upgrade quickly.

  3. Alex Ivanovs November 13, 2014 at 2:50 pm #

    “Today a spacecraft landed on a comet, is patching really that hard?”

    My man.

    http://cdn.meme.am/instances/55675405.jpg

  4. scor November 13, 2014 at 2:56 pm #

    The patch published at https://www.drupal.org/SA-CORE-2014-005 didn’t include a change to CHANGELOG.txt, so people who applied that patch instead of doing a full upgrade to Drupal 7.32 will still look as if they are vulnerable, when they are not. It is not possible to get an accurate estimate of the number of sites which applied the patch instead of upgrading. This means that you can’t claim that 57.5% of the sites have not been patched, some of that 57.5% are patched sites.

    Your infrographic is misleading because it includes Drupal 6.33 and older than 6.33. None of the Drupal 6 versions were affected by this vulnerability. It would be more clear/accurate/honest if you broke down your 5,630 number into a pie chart with the following categories:
    – Drupal 6 (not affected)
    – Drupal 7.32 (patched and no longer vulnerable)
    – Drupal 7.31 or older (possibly vulnerable if not patched)

  5. Jafar November 13, 2014 at 3:08 pm #

    7 hours is way too short to notice an update and patch a site.

  6. ChrisChristoff November 13, 2014 at 3:09 pm #

    Just to point it out, it wouldn’t have been WordPress since WordPress automatically updates (no user input required, just like Google Chrome) for security releases (minor point releases) since 3.7. If a bug was found and the patch was issued as a minor point release, all WordPress sites would get the rolling update automatically within hours.

  7. Commercial Progression November 18, 2014 at 4:09 pm #

    Love the comment on the comet… it should not be that hard, if someone is responsible for it. We are launching a new service to intercept that commit before disaster happens. https://www.commercialprogression.com/drupalcare