Drupal Core – Highly Critical Public Service announcement
drupal.org
drupal.org
After all, most sites out there probably don't need server-side dynamic preprocessing for every request. The CMS directory could be locked using HTTP auth (implemented by the HTTP server); this way, not every little CMS bug would allow the world to compromise the whole server.
Do we really expect every parish choir with a web site to hire a CMS specialist who installs updates within hours of the release and fixes all compatibility quirks that occur with new major releases? This is an unworldly approach that bestows thousands of zombie machines on us.
And what happens if the CMS for some old site stops being maintained? A responsible admin would shut the site down, resulting in a loss of potentially valuable information. This issue would be solved by using static HTML export, too.
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.)
It's not like you're forcing them to build jekyll.
1) reordering posts -- posts are displayed in _alphabetical_ order, as are directories, so the suggested nomenclature is a numerical prefix before every file name. So if I wanted to rearrange things, I had to decide whether not a linear shift was worth the benefits of file name readability.
2) the order of posts is reversed! I want new blog posts to show up at the top of my feed, but Stacey puts higher numbers underneath. I didn't want to count backwards, so I looked around and found a php hack for reversing this.
This might be fun if you're hankering for some DIY PHP, but I wouldn't recommend it otherwise.
https://github.com/kolber/stacey/wiki/Templating-Language#fi...
At this point, if I was advising someone building sites for small businesses and the like, my advice would be:
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.
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. Second, who knows how long and how well the plug-in will be maintained? Third, if static export is an architectural afterthought, it will probably break unusual features and workflows.
> a) it can lead to considerable complexity as an update to an atom of content may need to propagate to many parts of a site
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.
> b) the whole web is moving towards contextual dynamic delivery.
I'm not talking about amazon.com. They can probably afford proper maintenance of their fully dynamic site.
[1] http://www.nytimes.com/learning/general/onthisday/big/1014.h...
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.
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.
The problem is a lot of stuff is still dynamic even though it doesn't look like it.
There is an implementation out there that I think is the most intriguing, integrating Drupal with Jekyll: http://www.gizra.com/content/dekyll-drupal-on-jekyll/
There is at least one open source WCMS that uses static export at its core: http://openengine.de/ (site is in German, but docs are in English) - unfortunately, it has been unmaintained since 2010. It will export .htm or .php files depending on whether you need pre-processing on every request.
As far as I know, though, Publicis still use a closed source version of openEngine (openEngine Corporate ASP) for two clients: http://www.siemens.com/ (pretty big fish) and http://www.man-finance.de/ (search for "openEngine" in the source code).
So this is definitely viable as a core approach.
But I do think there should be a good separation between html and admin backend. Security is only one reason. There are other very important reasons:
1. waste of resources. the machine that builds the html from the cms is completely idle for 99% of the time.
2. scalability. the html should be served from a storage server like S3 together with a CDN. there should be absolutely no downtime in viewing html as a result of overload.
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).
Why would that have to be a separate machine? It could easily be the same one.
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.
It's template engine supports two tag types: one that gets run during the publish stage & one that get's run at the request stage.
It can then take an intelligent approach to publishing by having a publish step that renders each page to a static file. It's then trivial to test for the existence of 'run at request' tags and position the generated template accordingly: pure static files get put where a reverse proxy (nginx by preference) can see them, anything with per-request tags gets put in a 'private' directory out of nginx's paths for rendering & delivery by some front-end server.
This has many advantages, including:
- static pages can be served directly by Nginx - the public facing site runs in a separate process that consumes the generated templates - the public app (if needed at all) has no admin-centric code so has a smaller (& separate) attack surface - the publish step can be seen as a form of code generation so you could, in theory, publish a dynamic PHP powered site from this Ruby CMS
I'm also gradually working towards abstracting the template 'filesystem', currently you can render to the disk, redis, memcache or any other key-value store supported by the Moneta gem[1].
For the developer it gives the power of static site generators but provides a simple & usable editing interface for content editors.
Search is an issue for static HTML sites. Swiftype [3] and Algolia [4] look like solid options - has anyone used these in production?
[1] https://github.com/torchbox/wagtail
Compare this NYTimes article:
http://www.nytimes.com/2012/05/15/technology/facebook-needs-...
to this one:
http://www.nytimes.com/2014/10/28/business/virginia-plans-to...
Everything pre-redesign was published in as a static. Back-publishing 1,000's of articles is impractical and risky (for other reasons).
Would be curious as to why.
Also, while the pages clearly have different designs, it isn't immediately clear which is "better" (or that this betterness is due to its being dynamic versus static).
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.
If you're helping a client or company build a new site/app, and they are not ready and willing to either maintain the site themselves, or pay for a decent maintenance contract, or otherwise guarantee that security patches and hot fixes are applied in a timely manner, they don't yet value their website/app enough. It's your job—as someone who knows the consequences—to convince people of this.
This applies all the more when a project is built on a widely-used platform like Drupal, Wordpress, RoR, Django, etc. Though bespoke/lesser-used frameworks may provide a tiny amount of protection through obscurity, that's still no excuse for not educating people on the importance of maintenance in any software project.
If I'm not, is there a way to be notified about critical patches? Should I be signed up for a mailing list for every Github project I've incorporated?
Where I work, it seems like the standard practice is to finish the project, deploy it, and let it sit until the client requests any changes.
Maintain a staging environment (even in a temporary virtual machine if necessary) and run your updates in that environment first, then check it, and then deploy to production once you've confirmed everything is ok.
Your company should really not be taking the "set it and forget it" approach to building web-based applications. It is important to educate the client on the importance of a proactive support/maintenance plan.
As a digital agency building mid-market websites/ applications, we have also found that selling clients on support/maintenance has helped increase client loyalty as well when they want to take on new projects. If you build a site and then disappear the chance they decide to use a different firm next time increases greatly.
An authentication package that provides HTTP endpoints onto your framework where the controller classes are entirely out of your control or you simply pass a Request instance to the service class seems highly likely to be a security risk. The same goes for your ORM(s). Something like a Markdown converter seems less likely, though not impossible.
The popularity of the package could also play a role. If it's popular, it's more likely bugs/vulnerabilities will be spotted and revealed publicly on places like HN or Reddit.
Lastly, if you can ensure that all the packages you use follow semantic versioning, you can lock the version constraint in composer.json to only receive bugfix releases, which would in theory make it safe to run composer update as a cronjob. However, in my experience very few packages do this, and most of them when releasing a new minor version won't backport bugfixes/security fixes to older versions.
Personally, I have an RSS reader set up to notify me of new tags on Github for the more involved packages I use, but I also put a high emphasis on writing a lot of the code myself rather than use packages.
Really? I've found serious XSS bugs in frameworks that are semi-popular for writing real-time applications with a web component. What's outputted from your Markdown converter is generally assumed to be trusted HTML. Additionally, if it's not written in a language with good string support... it has string processing, which could lead to a crash or buffer overflow easily. It seems that a Markdown converter is exactly the sort of place you'd be likely to find an attack vector.
Absolutely not.
For one, an updated package can bring some subtle or crude incompatible changes when you don't expect it. Even in a minor/bugfix version.
Second, what if the composer repo itself is that got compromised? Then you are installing backdoors to all your sites automatically.
The article details how it can be practically impossible to tell if a site has been hacked. There is no reason to believe that your site has not been exploited prior to the announcement.
Whilst the post might have increased the volume of such attacks, I strongly doubt that this exploit was completely unknown prior to announcement.
In other words, if you run a Drupal site, that was vulnerable to this attack prior to the announcement, there is a risk that your site was exploited before the announcement.
This is a much more realistic scenario and also a more frightening one.
We saw the attacks start hours after the announcement.
http://blog.sucuri.net/2014/10/drupal-sql-injection-attempts...
This is a lot worse than Heartbleed, Poodle and others. Full database / server take over for 700,000+ sites that use Drupal.
There's also greater danger and incentive for attackers now that more websites are run by primarily non-technical people, as they are less likely to patch immediately.
The exploit is very simple, and doesn't require any interaction with the remote site. Explaining why they started on it very fast.
On other more complex exploits, we generally see days (if not weeks), before the attacks start.
1. Widely deployed software.
2. Internet facing on purpose.
3. Trivial to fingerprint.
4. Fairly robust exploit (doesn't crash the target or require version specific offsets, magic numbers, etc.)
And yes, when similar bug happens that meet these characteristics, mass scale exploitation will follow quickly after for various purpose (spamming, google ranking scam, DDOS, etc.)
There are many security vulnerabilities that have permitted full machine takeovers in an automated fashion for a long time now. Generally speaking though such attacks only work against very small fractions of the Internet, and, no matter how big Drupal may be in absolute terms, in relative terms, it is not that large. Heartbleed was so bad because it was so widespread. So many things use OpenSSL. That you could lose private keys was just icing on the cake; the arbitrary memory read was bad enough on its own, and the difficulty of detecting it also factored into its high rating. So, yes, I'd still rate Heartbleed far, far above this. Or the Ruby YAML attack.
(POODLE was by contrast well-named; annoying, yappy, ultimately not significant enough to warrant its own entry in the Great Security Vulnerability list. Enough to worry about and mitigate and it if helps bury SSLv3, hey, great, but not a thing for universal panic the way Heartbleed or Shellshock were.)
1- Extent of the damage
2- Number of points vulnerable
Heartbleed had (has) a lot more servers vulnerable, but the impact is a lot lower and it is a lot harder to exploit to extract valuable data. In fact, I doubt you will see a compromise or a major issue because of heartbleed (despite the mass drama).
Compared to this problem with Drupal, that is used by the many of the top sites online, the overall damage can be a lot bigger.
Time will tell.
My reasoning is that it's obvious (at leas I hope it is!) to your system admin that the system has been compromised when he's actively looking for indicators of compromise. This is not the case with heartbleed, so yes you can steal keys if you hack the cms and you control the server for a brief while. But this is obvious, the keys are going to rescinded, the users are going to be alerted and your access to the server is going to be severed again.
In contrast the consequences of heartbleed may not be completely known even now. What if the private keys of a linux kernel dev were compromised? The attack surface was huge, and the sensitive information covers more than only cryptographic keys. There could have been all kinds of stuff in the memory of the vulnerable servers.
16. Sep. 2014 - Notified the Drupal devs via security contact form
15. Okt. 2014 - Relase of Bugfix by Drupal core Developers [1]
---
We didn't want to disrupt the busy schedule of Drupalcon Attendees attended Drupalcon, a event to engage in discussion of the platform we, the organisers, know currently has a critical vulnerability.
We also assume attendees are uninterested in critical vulnerabilities while attending Drupalcon.
We assume attendees will be unable to return to their regular roles due to the excitement / insight / general awesomeness / other affairs unrelated to Drupal for a full week after attending out event.
Non-attendees implicitly missed out on our fun
We have now issued a fix, which is one line of code altering a database query string. Please be noted in our security advisory that you have almost no way to know whether your site was compromised and if it remains compromised.
---
It is more than terrible. It is arrogant, negligent and contempt.
[0]: https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patc... [1]: http://php.net/manual/en/language.types.array.php
So things like IDS (network and host), perhaps looking at adding a WAF to catch basic attacks, shipping all your logs off your front end servers so they can't be easily destroyed by attackers etc.
This kind of disclosure--> attack timeline now looks to be the norm, so this will become a theme and companies are either going to have to spend more on defense, or spend more on incident clean-up and then spend more on defense....
I much prefer
- external security monitoring (there are many vendors) - automated testing in pre production using skipfish/w3af/whatever - static code analysis - penetration testing - responsible disclosure programmes - hackdays
A lot of companies have difficulties getting app. patches applied quickly due to test cycles, so applying a WAF rule to block known issues (this one for example) can be a fast, low risk way of reducing the risk.
I agree, a direct targetted attack against your site they won't help (much). But for stopping a lot of robotic, automated hacking attempts they certainly have their place.
We were able to issue a virtual patching signature for our clients in less than 2 hrs after the disclosure.
Plus, our generic SQL injection signatures were already blocking this attack even without it.
That gives our clients more time to test and deploy patches without worrying about being compromised in the middle.
For example: https://twitter.com/i0n1c/status/522495098630987777
Many other sites were patched within hours.
However, there's a long tail of sites still running Drupal <7.32, and all those site's owners should assume, at this point, they've been compromised. As such, this PSA gives instructions for how to avert total disaster.
But trying to figure out how was not intuitive. The drupal web site was mum on the issue (you figured they post something on the site telling people to upgrade asap)
I figured it out eventually. Was disappointed how it was handled.
In fact, that's how I learned about most of the Drupal's core security issues (got a message in my inbox) and was able to patch them up really quickly.
The amount of time/resources it takes to keep your apps or sites secure today is so much greater than it was even a few years ago.
Development and maintenance practices that seemed reasonable to people only a few years ago now seem impossible. Delivering an app or site based on Drupal, WordPress, Rails, etc. as a finished product to a client that does not have sufficient in-house IT staff -- you can almost guarantee they're going to run into security trouble. And what is required for 'sufficient in-house IT staff' is way more than we thought a few years ago -- even if not everyone has realized it yet (those who have not will get burned).
And that for 99% of the cases (unless they process credit cards and transactions), it won't matter much, if at all.
This happened with someone I was working with, to try and rescue their WordPress.
Ironically, the site went down only because the malware that I'm guessing was scraping Google or making clicks on google adwords or something (I just skimmed the malicious code, it wasn't entirely clear to me what it did) -- had a bug in it that brought down their site. If it had been bug free, it could have kept using their site for it's malicious purposes for years without them ever noticing.
[1] http://www.usatoday.com/story/theoval/2014/10/29/white-house...
The petition site is D7. But last I checked they have some pretty heavy hitters on that project. They probably knew about and patched the vulnerability before it was even publically released.
[1] http://www.whitehouse.gov/blog/2014/10/24/welcome-white-hous...
I stopped using Drupal and WordPress about a year ago and am glad I did. Myself and several clients just dodged a MASSIVE bullet!
The killer here is:
"Consider obtaining a new server, or otherwise remove all the website’s files and database from the server. (Keep a copy safe for later analysis.)"
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.
What are you using to build sites now? When was the last time the codebase was audited by a security firm? There might be bullets out there for you...
If search engines had restrictions in place for this obvious type of malicious search activity, we'd be much better off and would see a massive reduction in the huge number of infected/exploited sites/apps. They are using them as a database of targets and must be stopped.
I feel this is a wake up call to petition search engine providers to implement and restrict these types of queries that are obviously malicious. We can't prevent direct attacks but these robots that farm search engines for mass infection, something can be done.
The other item is these software vendors need to restrict and minimize anything that puts a giant flag up saying "Look at me, I'm a Drupal site!" EG: CHANGELOG.txt shouldn't be in www root, etc. Even some simple htaccess rules can provide a mountain of help.
There was a one line patch that fixed this particular bug. Probably a lot easier to apply that than to do a full core update to a bunch of sites.
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!
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.
If anything, linking to massive governmental organizations and universities (both famous for their bureaucracy and resistance to change) that use Drupal would seem to support his claim.
Look at it this way--this Drupal vulnerability was caught because one company using Drupal invested in a code audit. Now everyone using Drupal can benefit from that audit, because the vulnerability was disclosed and patched by the community.
Now let's say you develop a CMS-like project on a microframework. Are you going to pay an outside company for a thorough code audit of the project? Is anyone else?
Thoroughly vet any platform (i.e. audit as much code as you can) before you deploy it, even if you want to believe that there are a lot of well-meaning white-hats looking at the product. (Linus's Law, etc.)
The SQL Injection vulnerability here was a little bit more clever than the ones you'd normally see. ($query = "SELECT * FROM table WHERE id = $tainted"; mysql_query($query);) All the more reason to take a closer look at the code.
And if no one else will, I'm certainly up to the task. But I make no promises I will publish my findings.