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" …
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,
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.
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.
> 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:
http://www.whitefirdesign.com/tools/drupal-version-check.html
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.
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.
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.
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.
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.
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:
substring(md5sum($password),0,15)
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!
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!
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.
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.
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: https://www.drupal.org/project/drupalgeddon
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.
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 https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch | patch -p1
Shame about the White House Drupal 7 site though ...
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!)
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
Then:
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.
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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
