back to article DRUPAL-OPCALYPSE! Devs say best assume your CMS is owned

Drupal websites that had not patched seven hours after the disclosure on a "highly critical" SQL injection (SQLi) hole disclosed on 15 October are essentially hosed, the content management tool's developers say. Attacks against the vulnerability (CVE-2014-3704) in version seven of the content management system began "hours" …

  1. Anonymous Coward
    Anonymous Coward

    "Drupal websites that had not patched seven hours after the disclosure on a 'highly critical' SQL injection (SQLi) hole disclosed 15 October are hosed, the content management tool's developers say."

    So when are sysadmins supposed to sleep!

    1. Anonymous Coward
      Anonymous Coward

      Thank god we use MS SQL and Sharepoint.

      1. Anonymous Coward
        Anonymous Coward

        Thank god we use MS SQL and Sharepoint.

        Heh, if I want a website that is incompatible with web browsers and pretty much is a waste of computing resources, then I'd consider Sharepoint. But since I want a workable website, I'll keep good backups and take my chances.

      2. EvilPixieMan

        That's your problem right there - Faith.

    2. waldo kitty

      "So when are sysadmins supposed to sleep!"

      1. real sysadmins never sleep.

      2. who says sysadmins are supposed to sleep?

      3. who is watching over the system if the sysadmin is inadvertently sleeping?

      =) =) =) =)

  2. Lyle Dietz

    What is this "sleep" you speak of?

    1. Captain DaFt

      What is this "sleep" you speak of?

      It's a type of coma you fall into when the blood level gets too high in your caffeine stream.

    2. Wensleydale Cheese

      You also need a time machine

      to go back a couple of weeks to 15th October.

  3. Destroy All Monsters Silver badge

    Society for Rational Network Management, War Trackers Interest Group

    Subject: Ping

    Language path: Optima

    From: Society for Rational Investigation

    Distribution: Threat of the Blight, Society for Rational Network Management, War Trackers Interest Group

    "You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15, 11pm UTC, that is seven hours after the announcement,

    1. AndrueC Silver badge
      Thumb Up

      Re: Society for Rational Network Management, War Trackers Interest Group

      I've always thought the final chapter in that book was the crowning glory. Those communication snippets were good.

      1. Samuel Penn
        Thumb Up

        Re: Society for Rational Network Management, War Trackers Interest Group

        The communications throughout that book were such a wonderful take on Usenet. They are lacking in the sequel unfortunately, which I'm currently reading and not enjoying nearly so much.

        1. AndrueC Silver badge

          Re: Society for Rational Network Management, War Trackers Interest Group

          currently reading and not enjoying nearly so much.

          Yeah the sequel is something I want to re-read. It was okay but seemed a bit long-winded and convoluted (although of course A fire.. is hardly short and simple). From what I remember it leaves the door open for a third (or fourth if you include Deepness.. novel. I'm not sure how I'd feel about that.

      2. David Haig

        Re: Society for Rational Network Management, War Trackers Interest Group

        Sounds an interesting book, excuse the ignorance but what is it?

        1. AndrueC Silver badge

          Re: Society for Rational Network Management, War Trackers Interest Group

          The book actually being parodied is A Fire Upon The Deep. It's a very good novel. One of the few S/F novels that can convey the true size of the galaxy in human terms. A Deepness in the Sky is a prequel (20,000 years prior) that also does a great job of putting things against human scale.

          1. David Haig

            Re: Society for Rational Network Management, War Trackers Interest Group

            Thanks, will look it up

  4. Cliff


    That's pretty disastrous. 'Hacking' used to be bored kids for laughs and fairly limited disruption, but now it is corporate work a profit incentive, this is only going to escalate.

  5. Pete 2 Silver badge

    The canary?

    > sites unexpectedly patched to Drupal version 7.32 could indicate compromise

    So should we assume that while Drupal sites have *not* been upgraded to 7.32, that they haven't been hacked (yet)?

    Oddly for such a "catastrophic" bug, 1 2 3 4 5 ... all but 1 site on the first 2 pages of the Drupal showcase website (that still exist, or still run Drupal) runs an outdated version.

    Version checker:

    1. Fonant

      Re: The canary?

      If you updated the site to 7.32 then it's safe.

      If you find that someone else has apparently updated the site to 7.32 then that might be faked as part of a compromise. The flaw enables an attacker to do anything they want with the Drupal database, including updating apparent version numbers in the system table.

  6. Mage Silver badge

    So ...

    Drupal 6.x is OK then?

    1. Fonant

      Re: So ...

      As far as we know at the moment, yes.

  7. batfastad


    I assume this bug has been hanging around since Drupal 7 release in 2011? In that case it would be safer to assume that every Drupal site has been hacked well before this patch was released.

    Surprising there's an SQL injection vuln since the database is so central to Drupal operation. You would think they would be far more aware, especially given the way they make so many APIs and hooks available to module developers. I've seen Drupal sites doing 300+ DB queries to load a single page (4k+ in one case with a completely cold Drupal cache)! And people wonder why their Drupal sites are so slow!

    Drupal's a total dog of a CMS, but it's the best dog there is for customisation. Although if you need to bolt on 200+ modules to achieve your basic requirements, I would say you're better off doing it from the ground up anyway.

    1. batfastad

      Re: Ouch

      And actually reading this what's insane is that the advice to "restore from backups from before 15 October 2014" was given on the 20th Oct. Probably not that feasable for busy news sites.

    2. Fonant

      Re: Ouch

      The explosion in automated hack attempts only started some hours after the patch was issued (thus alerting everyone to where the flaw was). The Drupal Security Team clearly understood the seriousness of the issue, as they sent an alert out five days before the update was made public, warning Drupal admins to be ready for an important security update.

      It's technically possible that sites could have been hacked silently before then, but pretty unlikely unless someone was targeting a specific site for its data.

      The script kiddie attacks are not particularly subtle, they add new users to the system with admin permissions, and add .php files to the site that are easy to spot if you look. My guess is that they are mainly interested in using sites for sending spam emails, and adding links to spam sites, as normal.

      1. majorursa

        Re: Ouch

        As I understood it they had the bug reported (and a patch available) for 3 weeks before 15 oct but postponed release because they didn't want to burden those partaking in a Drupal conference somewhere (?). So the vuln was known for 3 weeks, then they published it and again waited 3 weeks to recommend to reload a full site backup from 3 weeks ago if you didn't patch within 7 hours after publication.

        I'm only a small-time sitebuilder and -maintainer but this is not going to work for most people.

    3. Michael Wojcik Silver badge

      Re: Ouch

      Surprising there's an SQL injection vuln since the database is so central to Drupal operation.

      It's not really surprising. Drupal uses prepared statements, but it builds the prepared statements using string manipulation of unsafe data. That's how SQL injection happens.

      Unfortunately the fix for this hole just patched this particular case (which assumed array indices were integers - a pretty dumb assumption in PHP1), and doesn't mention whether there are other instances of this antipattern.

      1Right up there with the assumption that PHP is a good idea in the first place.

  8. PassiveSmoking

    Bobby Tables

    Do I even need to have to say it? Again? Apparently I do.


    1. Destroy All Monsters Silver badge

      Re: Bobby Tables

      Unfortunately, you do not have an audience ...

    2. ovation1357 Bronze badge

      Re: Bobby Tables

      I've recently inhereted a site for a local charity which is written in the poorest of php: Embedded print statements galore, code duplication to sink a battleship, no functions, global variables and, you guessed it, nearly all of the many form inputs directly form part of SQL query strings!

      It's going to take me a while to tighten up the security of this particular site! I'm no expert on SQL injection but I'm pretty certain that htmlspecialchars() alone ain't going to protect it!

      And then there's the previous dev's clever idea about passwords:


      No salt in the hash - god knowns why the substring is used but then... The whole password is stored IN PLAIN TEXT in the next column of the same table. Duh!

  9. ovation1357 Bronze badge

    Total nightmare!

    This is really not the news I want to be reading, nor is it a particularly helpful response from the Drupal dev team....

    I understand why restore from backup might be the best solution, although actually the site may have been hacked at any time during its existence using this exploiit, so even a restore may not be sufficient!

    I look after a Drupal 7 site in my 'spare' (ha ha!) time which has grown very complex and very large - It's not the number of content pages, it's huge quantities of weekly timesheets submitted by certain users and the subsequent invoices they've generated.

    I keep a daily backup of the site, but two weeks after the vulnerability, it is simply not an option for me to trash the site. restore from a pre Oct 15th backup and then reimplement all the thousands (yes, thousands) of changes since then! I absolutely don't have the time to do this - I'm a one man band, moonlighting, without enough free hours to keep up with all the feature requests for the site - Do the Drupal core team think that all their users are companies with a well-resourced teams to do this?

    What I really need now is information about the nature of any typical backdoors used so I can get a better idea of whether anyone did exploit my site. I'm pretty sure nothing has changed on the filesystem, but of course Drupal also runs PHP embedded in content that's stored in MySQL, so I guess I'm going to be trying to audit that somehow.

    Please Drupal team, give me some other options!

    1. Anonymous Coward
      Anonymous Coward

      Re: Total nightmare!

      Wonder if is a result ?

      1. Neil Hoskins

        Re: Total nightmare!

        One of the reasons I chose Drupal was that it's what the Whitehouse uses.

        1. chris lively

          Re: Total nightmare!

          "One of the reasons I chose Drupal was that it's what the Whitehouse uses."

          Yet another reason that you shouldn't let famous people tell you what to use.

    2. Anonymous Coward
      Anonymous Coward

      Re: Total nightmare!

      "but of course Drupal also runs PHP embedded in content that's stored in MySQL"

      That, in a nutshell, is just one of many reasons I will *never* be installing Drupal.

      1. Fonant

        Re: Total nightmare!

        This is an option in Drupal that's disabled by default. I do not recommend that people use evaluated PHP code from the database, and recommend that they leave the modules that do this disabled.

        But, this flaw allowed SQL injection, which is Game Over for any non-trivial CMS however it happens to work.

        1. ovation1357 Bronze badge

          Re: Total nightmare!

          What? Disable Views? Not likely... While it is possible to accept php into regular nodes, this comes with a stark warning and is only available to people with sufficient privileges.

          There are times when it is really useful and perfectly safe to use a bit of evaluated php so long as only a trusted user (i.e. me) can add/edit that code.

    3. Roby

      Re: Total nightmare!

      Indeed. Many of us are in the same boat. It's very difficult to go back to week old backups, especially when you built the Drupal site in your spare time for a friend.

      Some of the things you can check for include new users, new roles, any new PHP files (especially in your sites directory) or a change to the .htaccess of the files directory. If you use any kind of version control like git then you can see if any files have changed or anything has been added. Unfortunately the files directory is usually excluded from git, so you'll have to check it manually. But there should really be no .php files or executable files in there, so you can check with one recursive search. Also check all of your views for PHP code, and if you have the PHP filter enabled, check all of your blocks for PHP code too. Probably also worth checking the database directly for any content using the PHP filter, because it could be in the nodes as well.

      There's also this Drush command that you can run on your site:

      But none of this can make you sure that your site is safe. You can only tell if your site has been compromised, not if your site hasn't been compromised.

  10. macjules Silver badge

    Smug bastard warning ...

    In charge of 11 Drupal 7 sites, 4 Drupal 6 sites, 2 Drupal 8 and 4 Wordpress sites. Got the notification within 1 hour and very simple to run a bash script to do:

    curl | patch -p1

    Shame about the White House Drupal 7 site though ...

    1. ovation1357 Bronze badge

      Re: Smug bastard warning ...

      Git! (No, really - git merge is equally quick way to pull version 7.32 into my branch. Obviously wouldn't work if it wasn't already included in that release though!)

      I'm thinking I really better had subscribe myself to Drupal security alerts... I heard of this via the site's non-technical registered owner who received an email alert from the hosting company threating to take the site offline if not patched asap.

      I learnt of this problem on 17th October an patched it the next day after testing the update (which broke several things for me in my test environment!)

    2. Fonant


      1) drush @sitealias up

      2) Check you're happy with the proposed updates, then enter "y".

      3) Job done.

      Then, for this particular issue:

      4) drush dl drupalgeddon

      5) drush @sitealias drupalgeddon-test


      a) Subscribe to security notifications, if you're not already subscribed.

      b) Confirm that you have database and file backups in place.

      c) Ideally make sure your code is versioned with something like Git, to make it easy to spot any changes to files.

      d) Note that Drupal core security updates are generally issued on the third Wednesday of the month, when they're needed.

  11. Alistair

    Drupal 7

    Hass effectively become the "Aliens" of web presentation?

    (Nuke it from orbit, its the only way to be sure)

    oh. Did you say runs Drupal?


  12. Tim Brown 1

    Horrendous piece of software

    Drupal is awful, I can write a complete bespoke system in less time than it takes to explain to a client how to administer a Drupal-based site. In fact without employing a specially-trained consultant, Drupal sites are pretty much unmanageable for the average small business, yet time and again I see developers touting them as the ideal solution.

    1. Destroy All Monsters Silver badge
      Paris Hilton

      Re: Horrendous piece of software

      So it's like nodejs, only less bad?

  13. Jodo Kast

    Too many

    Too many Drupal 'developers' treat the Drupal CMS like magic.

    They don't know how any of it works, and just assume everyone else has the same level of ineptitude.

    Whereas real developers know how *everything* works. Otherwise, how are you going to create a custom solution?

  14. nicboyde

    Looked at Drupal long ago to compare with other free CMS options, and went with MODx - which has also had its problems (always quickly resolved) - but if you've already been compromised, it's too late..

    Fixing a compromised site takes a very long time because while some back-doors are easy to find, others are dead sneaky - you are supposed to find the easy ones and think the job is all over.

    So back-ups are essential, yet on at least one occasion one of my sites had been compromised by at least two different baddies at different times and it took ages to find a clean (pre-hack [pre-hack]) backup. One had actually got in before the flaw had been published.

    What I really, really wanted was a site-signature for the code of the site, and file-signatures for each code file and some kind of signature-scanner that could detect a change in those signatures across the entire site and all the backups to identify the last clean version. MODx doesn't have this, and the least said about Drupal the better, but they don't have it either.

    I'm no techie - I'm not much more advanced than the "developer who treats Drupal like magic". This is why I use someone else's CMS rather than design and build my own. I can't build OSs either, or write drivers for flash arrays. All magic to me.

    As it should be. The magicians need to up their game, and in these days of thousands of baddies, working in shifts, hiding behind irresponsible and incompetent governments (if not worse), the magicians are failing to impress. We need the tools to make recovery from compromise as straightforward as, say, an original install.

    While I'm at it, the chap above who has "thousands" of invoice-like transactions that now have to be re-keyed, needed a transaction dump file - a journal we call them in accounting terms - which can be used to regenerate the online processes in a recovery - suitably error- and hack-checked to remove the SQLi transactions.This has to be maintained somewhere else, not in the same database as the one it protects. and, no, I don't know how to do this either.

    Come on Gandalf.

  15. Wensleydale Cheese

    Wait a minute

    Am I the only one who does daily backups?

    And keeps them hanging around for more than a week or two?

  16. hasan.raza

    Drupal Still has Awesome Security

    I have been using Drupal CMS for far to long, and its still most secure CMS out their.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021