Drupal security hole - October 2014

https://www.drupal.org/PSA-2014-003

http://grahamcluley.com/2014/10/assume-unpatched-websites-running-drupal-7-compromised/

https://news.ycombinator.com/item?id=8528605

Some excerpts from the above links:

Date: 2014-October-29
Security risk: 25/25 ( Highly Critical)

Automated attacks began compromising Drupal 7 websites that were not patched or updated to Drupal 7.32 within hours of the announcement of SA-CORE-2014-005 - Drupal core - SQL injection. You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement.

Simply updating to Drupal 7.32 will not remove backdoors. If you find that your site is already patched but you didn’t do it, that can be a symptom that the site was compromised - some attacks have applied the patch as a way to guarantee they are the only attacker in control of the site.

...

What a unholy mess.

In a nutshell, if your site wasn’t protected within a few hours of Drupal’s announcement on October 15th, you need to restore it from an old backup or rebuild it from the ground up.

...

Whenever I read about the latest vulnerability in a popular WCMS, I wonder why static HTML export still doesn't seem to be a prioritized feature in popular systems.

Are there any well-maintained open-source CMS out there where static HTML export is an integral part of the architecture, ideally with good usability and written in PHP (not that I like the language, but that's what is available everywhere)? (I'm not talking about command line static site generators without a user-friendly backend - those are only an option for techies.)

I like how the commenter had to provide the disclaimer about not liking PHP in the Hacker News thread. It's probably a required disclaimer, otherwise the commenter could get booted off of HN and maybe the Internet.

Never admit that you like to program in PHP or like to develop around Wordpress.

At least the commenter was correct about command-line, static-site generators being only acceptable for techies.

Geeks enjoy using complicated things because: 1) it's not mainstream like using Wordpress and 2) it gives them a reason to try to simplify the process.

But one of the pros of using a static-site generator is to protect against security holes. But Drupal has existed since at least 2001, and it has a large community of developers. It seems like this security hole would have been found through testing.

One person creating an app in a vacuum could easily introduce a security hole, but it shows that even large, mature open source projects can be flawed at times.

More HN comments that suggest an interesting level of complexity or maybe it's a conundrum.

Since it's 2014 and not 2004, many more useful services exist today than before, and these permit businesses or website owners to "outsource" certain functions.

Another HN thread discussed how site owners should use another service, such as MailGun, to manage email, especially outgoing messages.

I use MailGun with my Grebe blogging app to send the login link. I have not tried installing an email server on my DigitalOcean droplet. I still might, but it was easy to download the MailGun Perl module and use MailGun's API to send a message.

Today, it may be unnecessary for a site owner to try to install or build every function that's required of a web site, but it might also be hard to let go of or outsource certain functions.

Instead of having pieces of the site spread out across multiple services, site owners might prefer to install a CMS and its plugins that attempt to do everything that the site needs.

Anyway, some interesting ideas suggested by HN commenters:

Can you use a hosted service? Wordpress.net, Shopify, that kind of thing? If you can make that work, that should be your first and only choice. If not... are you really sure that you can't use a hosted service? Okay, then build a site that does static HTML for end users, with a carefully locked-down admin section. On a different domain, if you can.

If you need dynamic features for users (a shopping cart, etc.), again, see if you can integrate a hosted service with your static site. If the reason you can't use a hosted service is because your client is too cheap to pay for it, do not take that client.

Otherwise, if your client absolutely needs bespoke, dynamic features for their end users, and absolutely no hosted service will work for them, they need to invest in a support contract, and you need to tell them up front that they'll have to do that. There are actually contractors out there that do long-term support for other people's apps, if you don't want to be saddled with it yourself.

...

the ideal system for small websites is a machine that is turned off by default, and when an admin needs to change something it is turned on (even if it takes a whole minute). After the changes are committed, the system creates html and sends to S3. For forms, comments, and dynamic things it's best to use third-party (like facebook comments and a billion forms services), or use a different small machine that captures user input (completely separate from the turned-off admin machine).

...

A separate machine/VM is better from an availability perspective.

...

How so? A separate machine is one more thing that can fail and since it isn't web facing it won't help with availability if the other one fails. And if it is a VM they will both go down if the underlying hardware fails.

...

E.g. the frontend can be replicated (if needed), S3 can be used, while the backend CMS remains intact. Or the backend CMS can be implemented in a HA setup and the static hosting in the cloud.

...

Sure, static export plug-ins do exist in plenty, but I don't think that core functionality like this should be implemented as a plug-in. First, if it isn't enabled by default, most people won't bother to enable it.

We shouldn't let perfect be the enemy of good. Even if some blog article from months ago won't get the updated shiny new sidebar, what's the matter? The New York Times still have content from the web stone age on their server [1] - it doesn't use the latest template, but isn't it more important that this content is still available? It probably wouldn't be had they used a dynamic CMS back in 2001.

...

As the creator of a static export module for Drupal, and a maintainer of another, I agree that in the end if it's not built into the core, it's not going to have much long-term viability. That said, D8 is built on services, which makes an interface for static export available basically out of the box.

...

> b) the whole web is moving towards contextual dynamic delivery.

But not using server side dynamism like Drupal provides. It is moving towards sites serving up static files consisting mostly of Javascript that then call data services, so called single page sites.

...

In so-called single page sites, the data services are the server side dynamism. The only difference is that you've moved the template engine client-side, and replaced one call to the server-side application with multiple calls.

SQL injection attacks are just as possible against those kinds of apps, although slightly tougher to configure because you need to read client-side JS to find the service URLs, tokens, etc.

Drupal is used to power client-side JS-based sites. The current Tonight Show website is a recent example.

...

If your content management system is also your content delivery system, you are doing it wrong.

...

Having moved a large media co from bespoke systems which worked this way, I couldn't disagree more. Separate frontend and backend systems are an absolute maintenance nightmare and kill time to market which is the lifeblood of any online commercial endeavour. Apart from being extremely dated (c. Vignette) that architecture is a technical conceit which doesn't put business needs first. It is easy to build and easy to secure but that doesn't make it a useful longterm solution.

...

Stacey is like Kirby without a web interface. You manage content by dropping text files into directories. It's not inelegant. Admin interfaces can be just as poor for representing content as anything else (see: TinyMCE/WordPress) so once you get a client used to the workflow it isn't much of a hassle. It's not like you're forcing them to build jekyll.

...

Do we really expect every parish choir with a website to configure server file and directory permissions and turn on HTTP authentication? Seems to me that static site generation is only going to be more secure if the people setting it up know what they're doing. Probably the best approach these days for a parish choir website is a hosted solution like Wordpress.com, Squarespace, Google Sites, or if we're talking Drupal specifically, Acquia Cloud Site Factory, or Pantheon.

...

Those developers still using Drupal must really not be having fun. Drupal is an EOL still sticking around from back in the day of monolithic php cms frameworks that were broken at the core (Joomla, PHPNuke, etc). They make developers lives worse and lead to very little in solid products. It was good for a time, that time has passed and there are better ways.

Keep this in mind when you pick up new monolithic/take-over frameworks, they bloat and die, microframeworks are the way to go. I am sad for developers lost in Drupal dead zones. Drupal man walking!

Drupal is at least 13-years-old, and it currently powers thousands or hundreds of thousands of websites. Like Wordpress, Drupal won't be disappearing anytime soon because some geeks think that it's outdated software, maintained with a so-called outdated language. Why have developers even started their own shops based around Wordpress and Drupal? Conferences for those apps still draw large crowds. Those are not signs of dying software ecosystems.

For decades, Cobol and Fortran apps powered businesses. The C language has been around for over 40 years, and C is still being used to create new apps in 2014. Back in the early 1990s, C was suppose to be dying because of C++. And then in the mid to late 1990s with Java exploding on the scene, C was definitely suppose to die off.

Why can't PhP be the web scripting language version of venerable programming languages? Why do geeks jump to a new language every 3 to 5 years?

I suppose that in 5 to 7 years from now, or maybe even now, Python-Django, RoR, Go, NodeJS, Scala, etc will be considered outdated and replaced by the the hot new language invented in 2020.

I guess the most desired future programmers will be those who can program in at least six different languages in order to maintain old code and convert it into the current trendy language.

Have fun trying to get your microframework to satisfy the requirements of massive governmental organizations, universities, and gigantic media sites. I think you haven't a clue as to what drupal's capabilities are if you've got it even in the same ballpark as Joomla and PHPNuke.

...

Drupal 8 aims to cut down on the NIH syndrome by using high-quality Symfony 2 components instead of in house libraries.

...

I stopped using Drupal and WordPress about a year ago and am glad I did. Myself and several clients just dodged a MASSIVE bullet!

...

What are you using in place of those? Wouldn't your clients normally pay for maintenance?

...

For my monthly subscribing clients, I use an MS stack (with Azure) with Visual Studio and then have them on the $20/month CloudFlare plan.

Included in their monthly sub is an update service. I maintain a 24 hour turn around on any changes. This way, I get to control my code, then don't break their site, and everybody plays nice.

Lately, I've been using PyroCMS or KeystoneJS for a lightweight CMS when necessary. Most of my CMS customers are one-time dev deals. I design, build and then hand it over to them so I'm not responsible for security or updates - which is something I have in the contract they sign.

By doing so, the clients I need to maintain control over (in a security sense) I can and then I don't have to take chances with WordPress or Drupal. I've been a fan of Drupal, so it's tough to see they got hacked pretty good. Usually its plugins which get hacked, so getting the core of your framework hacked is a huge deal.

...

I replaced Wordpress with a home-built solution that is drastically simpler. It retains most of the URL compatibility so links wouldn't break, but it has only a tiny fraction of the functionality of Wordpress (most of which we didn't use anyway). It's entirely possible that our solution has vulnerabilities (though we designed it with security in mind, and the code base is much easier to audit due to its simplicity). But at least it's not going to get compromised due to a generic Wordpress exploit.

...

There would be a lot of demand for a much simpler WP alternative built with security in mind. Would you by any chance be open sourcing the project? More eyes on the source couldn't hurt.

I thought that was the point of Ghost.

#drupal - #wordpress - #programming - #security - #php - #cms - #blogging