Drupal Sites Used in Cryptojacking

[engine]

Over 300 Drupal sites are being used in the Drupalgeddon2 RCE flaws.
Update your Drupal CMS now!

...hundreds of compromised Drupal sites being used to host "cryptojacking" malware that uses the CPUs of visitors to mine cryptocurrency via CoinHive.

[theregister.co.uk...]

Earlier story
Important Drupal Release on March 28 [webmasterworld.com]

[keyplyr]

CMS are easy targets for many types of hacking. They all use the same framework & code so it's just a matter of time till someone discovers a vulnerability and exploits it for their gain.

[explorador]

Drupal was usually a name under the radar on such issues, not that it was perfectly safe but lately, it's enough to confuse clients on their confidence to the product.

[TorontoBoy]

I've had really good luck with Drupal. I can see this through my logs' lack of attacks. Then again maybe they all go for my Wordpress sites! Still I do all updates required.

[ergophobe]

The one advantage Wordpress has is that it can be set to update automatically. This is not possible with Drupal 7 and would almost certainly result in bringing websites down in Drupal 8, where every minor update is fraught with danger.

So though I think Drupal tends to have stronger security than Wordpress (especially if you're including third-party add-ons), there's a reason that a lot of people fail to update their Drupal sites. A complex Drupal site can be quite fragile in my experience. It absolutely needs to be updated on a dev platform, pushed to test where the current live data is uploaded, tested, then pushed live.

[TorontoBoy]

WP only updates minors automatically. Majors need the manual push, as far as I know. I did not think D8 was so fragile.

[engine]

A complex Drupal site can be quite fragile in my experience. It absolutely needs to be updated on a dev platform, pushed to test where the current live data is uploaded, tested, then pushed live.

I assume that's why there are still vulnerable version out there. Either way, Drupal must be updated, and kept up-to-date.

[Travis]

I wonder if there is a single legal "thing" about cryptocurrencies ...

[keyplyr]

cryptojacking = another reason to use security headers that block 3rd party processes.

[surfgatinho]

One of my Drupal sites got hacked within days of the last highly critical vulnerability being announced. Was kind of bad luck as there were lots of other (temporary) reasons why security was down.
Spotted it pretty quickly as the CPU was going 100% running a DDOS script.

As for updates - always a terrifying prospect on a live Drupal site. You need to be able to roll it back when everything goes white...

[TorontoBoy]

I have known people in D6 that almost never updated their sites, spam-tastic, and never got hacked. Are you saying that Drupal is not the rock solid CMS I thought it is/was? It only accounts for, what, 2% of web sites?

[thecoalman]

I had a site hit with this a little over 24 hours after the exploit went public. A Google Search Console email alerted me to it but it wasn't because it was hacked.

They obtained a new html verification file through the search console and uploaded it. I received an email about a new owner for the domain and another about the target country being changed. They uploaded/created a sitemap folder and added the url's for the sitemaps in the Search Console thus Google is executing the scripts... slick huh?

Fortunately the site is pretty static. Reverted to backup database and backup copies of the "site" folder from quite some time ago. Changed the database password and i think I should be good.

I have a zip file of all the files uploaded if anyone is interested in them. Send me a message.

[ergophobe]

I did not think D8 was so fragile.

At least that's my experience. Here's a collection of war stories from the 8.3 to 8.4 upgrade.
[drupal.org...]

I have known people in D6 that almost never updated their sites, spam-tastic, and never got hacked.

They got lucky. Of the 5-6 Drupal sites that I was in some way responsible for at the time of Drupalgeddon1, at least two were hacked within two days. And those sites were a mix of D6 and D7, and they were all up to date except for the Drupalgeddon patch.

The problem with any software that has a public-facing website is that the reprobates can scan at their leisure to see what tech you're running and create a database of all sites running Drupal or Wordpress, all sites that depend on JQuery, Bootstrap, Foundation, in theory all sites that have a given JS library, a given webhost, a given CA, and so on. Then when they hear of a vulnerability, they can target them en masse very quickly.

That's different from, say, a vulnerability in the Dropbox client for Mac OS X. In that case, they have to basically do widespread, untargeted phishing attacks and hope they happen to find someone who has both a Mac and Dropbox.

[TorontoBoy]

The problem with any software that has a public-facing website is that the reprobates can scan at their leisure to see what tech you're running and create a database of all sites running Drupal or Wordpress,..

The technical name for this is called reconnaissance. I have run Open Source hacking software that included reconnaissance, a vulnerability database, exploits and the ability to create webkits, and have found Drupal sites pretty difficult to hack. I guess the open source vulnerability database does not include everything!

One of my ex-customers had a D7 site that was not updated for 2 years, with 330 modules. I skinnied it down to ~210 modules as best I could, but was then booted because they could find someone in Russia or India with no Drupal experience to work for cheap. I did wish them luck.

Narrowing down Drupal exploits, is it core code, modules or both that are vulnerable? D8 has so much, including the kitchen sink.

[explorador]

I have known people in D6 that almost never updated their sites, spam-tastic, and never got hacked. Are you saying that Drupal is not the rock solid CMS I thought it is/was? It only accounts for, what, 2% of web sites?

It depends on their traffic, the server security and their environment. When I worked on a media company many sites received attempts of hacking, that's way different to other types of sites (personal, hobbies, MFA made for adsense, etc) Drupal never failed when I worked there and was my weapon of choice when I had to drop my CMS (because I was leaving).

I don't know if they ever updated the core or modules, but the latest years the remaining site using D7 has been hacked to post online tv show links several times. I no longer work there so I don't know what could be the cause.


About D8, it was suppose to be better, when I read about Symfony (based on that thing that I actually know) I hated it and since then I've been distant from Drupal. I don't know how many here are aware of the details, but Drupal 8 is a totally diff animal, so in terms of Drupal history I would wonder how the guys from Backdrop are doing.

[ergophobe]

Well, keep in mind that both Drupalgeddon and the latest exploits were zero-day - there were no known exploits in the wild. In fact, most of the Drupal exploits I recall, and at this point certainly most exploits to core, are zero-day. So I'm not surprised you didn't find vulnerabilities.

Most exploits are in modules, but of course that is both because there is far more module code and the quality is lower. I actually found and fixed a security issue in some module (don't remember which and in the announcement, they didn't even mention me). It was a basic failure to sanitize user input. But what mitigates the threat from a lot of the module exploits is that often in order to be able to exploit the vulnerability, you must already be granted some level of elevate privilege. The vast majority of Drupal security announcements that I see come in the mail (if you run Drupal sites, you should be subscribed to the security email list), are things I can safely ignore because they are only a worry if you have untrusted admins. And if you have untrusted admins....

[ergophobe]

since then I've been distant from Drupal. I don't know how many here are aware of the details, but Drupal 8 is a totally diff animal, so in terms of Drupal history I would wonder how the guys from Backdrop are doing.

Same here. Every time I try to port a site to D8 just to see, I play with it for a while and then find myself in some situation where I can't keep the site on its feet. It has gotten better though. The D8.4 to 8.5 upgrade went fine with a project I'm testing. But still, it is not longer a hobbyist tool. It really is more appropriate for a situation where you have front-end dev, backend devs, dev ops team and sys ops team. Seriously.

As for Backdrop, after my last frustrating experience with D8, I went to look at Backdrop. I was thinking it seemed dead... and yet just a few days ago there was this
[sfconservancy.org...]

And a couple of months ago, the founder (forker) of Backdrop finally ported his personal site to Backdrop
[quicksketch.org...]

Still, I'm not sure it's where I would put my energies... I just don't know where I *would* put them. I tried perhaps a dozen CMS before finding Drupal. Before that I had rolled my own. At a certain point, I felt like it just didn't make sense to start from scratch.

Now I wonder about taking a step back. You can go one step back to something like SilverStripe that basically requires coding for many things Drupal does in the admin interface, but is out of the box a functioning CMS, or two steps back to a framework.

I don't think it makes any more sense to go three steps back (roll your own with PHP from scratch) than it does to go four steps back (roll your own with C++ from scratch).

[TorontoBoy]

I had heard that in D8 they will change upgrade philosophies from "start fresh for every major release" to an evolutionary, rolling release, such as what Wordpress uses. Maybe this is contributing to instability?

Zero days are near impossible to defend. Every once in a while I do reconnaissance and try to hack my D8 site. I cannot find any hole.

[ergophobe]

I think Drupal 8 is stabilizing. In the future, they are planning to make a front end, within the admin area, for Composer.

To me, the instability of Drupal 8 has been entirely based on conflicting dependencies. To run Drupal 8, you *must* manage your code with Composer. If you have skated by without doing so so far, you will not be able to in the future. What I've seen and others complain about is that you run into situations where of course you want drush so you require drush in your Composer JSON. drush requires some-awesome-package version 8.3.1 or lower. You have added a key module that is now a required component and in your Composer JSON. The key module requires some-awesome-package 8.3.2 or higher. Now you're just completely screwed. You can no longer run Composer. You can no longer update your site.

The more you are running recent versions, the more you run into this.

You get into situations where you update with Composer and it updates Symfony, but that requires a package that is incompatible with Drupal core and so on and so on and so on.

So at least for me, relatively new to Composer, getting it so that the Composer directives are loose enough to allow security updates to roll out, but tight enough so that you don't end up with incompatible dependencies has been a challenge.

And that's just starting to touch on the meta problem. It used to be that you could download a zip file, install Drupal core, and run a website. If you had a security update, you just downloaded the new code and applied it and ran update.php to run the DB updates.

Then, 6-7 years ago, pretty much everyone added git to their workflow with Drupal and that made it even simpler to apply a patch, test and deploy. Same essential process, but better tools.

But with D8, you can't really install and run it that way. You pretty much must have Drupal Console and drush to do maintenance tasks and you must must must use Composer. Even if you install a distro from a zip archive, it will usually have dire warnings about how you might be getting an old version and about how you will at least have to run "composer update"

More serious shops generally also run everything containerized. I honestly haven't gotten there yet. But to avoid nasty surprises when going from dev to test to live, I think it is becoming common, if not standard, to run with Docker or Vagrant and to also use various build tools (grunt, gulp, whatever you might need) and possibly bower since Composer is mostly for PHP packages, and you still might need a package manager for your client side packages (yes, this is real - I needed bower on a recent fairly simple Drupal 8 test project).

So...

Drupal 4 years ago, recommended tech: web server, DB, FTP client, Drupal, git, drush

Drupal today, recommended tech: web server, DB, Drupal, git, drush, Drupal Console, Composer, Docker or Vagrant, grunt or gulp, bower

That's just a huge hurdle

[explorador]

Ergophone: That's just a huge hurdle

absolutely, and thanks for that detailed report - comment, appreciated. I had a few discussions with some people about this, they love the "new thing" and say drush, brush, cush, and whateverush 2.045.12 bring more stability and the safety we could only hope for on [insert-another-weird-name-here].

I have a few issues there. One is my background telling me that's too many moving parts, doesn't stick to KISS (keep it simpl...) and my experience of full versions and 0.1.2 less than half versions crashing unless the other part is xx.xx.1.1, etc. But mostly and this is a human thing (but I just can't help it) is wondering if one person has enough time to master each and every single one of them. Ok, granted, those previously mentioned can... and brings a new problem that I see in human terms: none of them has a personal site, if they do, some manage a site for a customer of theirs... has under 100 visitors per day. And even so (this is new to me) after a year and a half, those kids are nowhere to be seen, gone, moved to other stuff. It doesn't seem to me as a live solid ecosystem.

Each day I'm closer and closer to saying Good Bye Drupal.

[TorontoBoy]

There is some credence to the idea that D8 is no longer for the not-for-profit, that only sophisticated, very well funded companies can use D8, with a lot of specialized skills. I, too, profess to loving KISS, and D8 is getting way out there. But you can still set up a simple D8 site straight out of the box, and it will work.

[ergophobe]

Yes, you can use Drupal straight out of the box and with Views in core, it's quite powerful.

I would say, however, that the current definition of "straight out of the box" is a Composer-managed install with no added modules (rather than a tarball with no added modules). That is the recommended method for installing and updating Drupal currently - [drupal.org...]

But yes, if you don't have added modules, you don't need grunt/gulp, bower and you don't really need drush or Drupal Console as long as you have Drupal and Composer.

Many key players who decide the direction of Drupal think that Composer should be a hard requirement arguing that Drupal 8 cannot be maintained without Composer. With the switch to Symfony and the "Proudly not invented here" philosophy, the dependency problem has become much thornier.

I searched but can't find those discussions right now, but as I recall, they decided they would not make Composer a hard requirement until it integrated with Drupal so site builders could use Composer without necessarily knowing it (or at least without having to use it on the command line). So there is some recognition that it has become a beast to upkeep.

Anyway, some choice excerpts from this Lullabot article
[lullabot.com...]

Before we dive in, though, you may be asking yourself, “Why Composer? Can’t I just download Drupal and the modules I need without requiring another tool?” Yes you can, but you will quickly realize it’s not a simple task:

1. Contributed modules or themes often depend on third-party libraries installed via Composer. Without using Composer for the project, you’ll need to manage these individually when downloading, which can be quite a chore.

2. Some packages and modules only work with certain versions of PHP or Drupal. While Drupal core does help you identify these issues for modules and themes, it’s still a manual process that you’ll need to work through when choosing which versions to download.

3. Some packages and modules conflict with other packages. You’ll need to read the composer.json files to find out which.

4. When you upgrade a package or a version of PHP, you’ll need to do all the above over again.

5. If you’re thinking you’ll use drush dl and friends, they’ve been removed in favor of Composer.

That sums up the situation currently.

[edited by: ergophobe at 5:10 pm (utc) on May 21, 2018]

[ergophobe]

Or see the current guide on updating your modules in Drupal
[drupal.org...]

People who are used to doing module upgrades with Drush, should notice that in Drush 9 (the current version) all the up commands - pm-update, pm-updatecode and pm-updatestatus - are deprecated. You have to use the corresponding Composer commands.

[explorador]

ergophone: That sums up the situation currently.

Exactly what I remember about Symfony, the thing Drupal is based on now. I agree Symfony works out of the box, it did when we first met, the problem is exactly as the quote you posted describe it. As you try to add some simple things (that Symfony doesn't do out of the box) the mess begins. While unrelated, it also matches what we experienced with PhoneGap, yes it also works but for simple things. As you add some stuff you find out the version number from 1.20301 to 1.20305 can be a huge leap and compatibility madness between some stuff.

Drupal wasn't so different back then, but it wasn't so messy. I remember developers complaining because WP can be used with a wysiwyg editor out of the box while Drupal in most cases didn't allow this, so you had to install extra stuff. That's ok right? then you would notice some of the available stuff for just that task was outdated, no maintenance, security problems and others were just broken. You had to install something and then a fix for the fix. Not to mention the megabytes consumed by that simple extra functionality. They fixed this and then you could use Drupal in a more easier way than previous versions. I remember I often performed a clean install, added extra modules, configured the whole thing and THEN I had a compressed Drupal ready to deploy from scratch, I wasn't installing it from zero on each project, nope, this tarball was my beginning many times.

Sounds to me like today things are similar but more complex. I walked out of Drupal, why? I understand how things are behaving right now and I can't afford to install and build a project only to find out something is broken ahead when I already glued many things together. Some of the stuff they mention to make it work is "ok", no is not ok with me but ok with other people, yet... it doesn't mean you can easily work your way around on shared hosting for small to mid projects, you won't always have the same access to tools and configuration.

I just hate how that goes, it's not install, configure, doesn't work?, fix. It's about install A, then B, then C, you need D to configure A, then C to play with E. Really? from a developer perspective... really? not to me.

[TorontoBoy]

I have not quite given up on Drupal yet, but am unconvinced of any comeback. Year over year their market share shrinks. I believe it is down to 2.1%? For D8 I see complexity that is too much for the smaller organization, and a UI that continues to confound users. I hear about module incompatibilities that break the site. From the get go I did not agree with the lack of smooth transition (requires complete site rewrite and data migration) between Drupal major versions, and thought that D8 would fix this, or so I am told.

I am hoping for the best for continued stability of D8. Drupal has some very strong points, one of which is security.

[ergophobe]

@TorontoBoy - your post exactly summarizes where I'm at too. Kinda sad. I really like the Drupal community. If you've ever been to a Drupal event, it has a good feel. So much less corporate than, say, an SEO event. Way cooler. More like an SEO event used to be, but geekier and with a broader range of interests I would say.

[LifeinAsia]

I haven't given up, but definitely have no plans to move to D8. As the sunset time for D7 nears, I'll look into options at that point. But it may very well end up being a complete rewrite of the site. As ergophobe knows, my sites are so complicated that it could be a good excuse to simplify/streamline things. Especially since I don't like how Drupal does some of the things under the hood.

[TorontoBoy]

You may have 2 years, possibly more, for D7. I'm unsure about the migration tools, but it'll probably break a lot of things.

[ergophobe]

I guarantee that the migration tools will break a LOT of things on LifeinAsia's sites. Either way, it's going to be a total rewrite and a complicated content migration problem. If you don't like Drupal, that will be the time to jump ship.

[ergophobe]

PS - you could run Drupal 7 indefinitely. If your backup and system audit tools are good enough, so what if you get hacked? If you don't have PCI or HIPPA considerations, restore from backup :-)