Drupalgeddon 2.0

We hope you find this an interesting and useful article. However, if you just want the quick and dirty facts...

(TL; DR - Jump to takeaways)

UPDATE:

A week after this article was published, another critical Drupal core security update was released - SA-CORE-2018-004 - on Wednesday, April 25, 2018. It's a great time to be a Thinkbean client, as every client was (yet again) already protected against this exploit - even before it became public knowledge. If you are not a client, go talk with your developer right now and make certain your Drupal instance has had this latest vulnerability patched. Then, come back and read this article. If you don't have a reliable, professional Drupal development company monitoring your site, contact us now.

What is it?

As you may have gathered by the “2.0” portion of the title… for the second time in less than four years, a major vulnerability in Drupal core has been announced. As was the case in 2014 with SA-CORE-2014-005 (aka “Drupalgeddon”), the latest security announcement (SA-CORE-2018-002 (aka Drupalgeddon 2.0)) is highly critical (25/25 on the Drupal Security Team (DST) “Security risk” score). Both vulnerabilities allow for remote code execution by an attacker. If you are technically-inclined (and are really interested in some of the technical details behind this vulnerability), check out this article from Check Point Research.

How was it discovered?

Drupal is (still) one of the most secure platforms available on the web today. Ironically, this is because of, not in spite of, these recent security releases. Part of the reason for this is the thousands of contributors who regularly work with it. This, particular, vulnerability was discovered by Jasper Mattsson as part of general research and security of Drupal. Jasper works for a Drupal development company in the Netherlands.

What does it mean?

Basically, this means your Drupal 6, 7 and/or 8 site has a flaw in the core programming of Drupal, itself, which allows anyone who knows about it to take over your site. There are several reasons why these vulnerabilities have been treated with such gravity:

• It’s very easy for an attacker to leverage the vulnerability.

• There is no privilege level required for an exploit to succeed.

• All data (including non-public data) could be exposed/accessed.

• All data could be modified or deleted.

• Known exploits already exist “in the wild”.

• For all intents and purposes, all Drupal sites are affected.

What do I need to do?

Put into the simplest terms, you need to be certain your developer has already updated your site (at the very least, on the day the update was made available). If you do not have a developer and your site was not updated, you need to consider your site compromised. Do you have thoughts of asking your developer to “check and see” if your site has been hacked? On the surface, that’s a reasonable initial thought. However, be advised it could take tens of hours or hundreds of hours to make such a concrete determination. Even then, it may very easily not be discovered. Our strong recommendation would be: don’t waste the resources (time, money, effort).

This is a situation where the quality of your web hosting provider really paid off if you were using a good one. There were a few providers who were already protected from this vulnerability. That is a very short list (Platform.sh, Acquia and Pantheon (there may be others)). Shameless plug: Thinkbean hosts its Drupal web projects only with the aforementioned hosting solution providers. Check out this post from one of our main hosting partners.

Even if your site was hosted on one of the protected hosting platforms, it is absolutely imperative your site be updated… for a number of reasons. It is not important to go into the reasons why you must update even if you are hosting with one of the protected providers. Just know - you need to. Ask your developer to explain the reasons to you if you are truly interested.

What if my site is compromised?

If your site needs to be considered compromised because you did not update immediately, you can find some information here. Basically, your only real options are:

• Replace your current installation with a backup from the time immediately preceding the announcement (preferably, no more than 12 hours prior).

• Re-build the site.

• Close the site down and leave it closed.

These may seem like extreme options. However, the reality is if you did not update in time and you continue to allow your site to run, you are not only jeopardizing the safety of all the information on your own website (public and private) but you are also very likely to be an unwitting accomplice to the compromising of your users and other websites. Although, since you are now reading this article, you really couldn’t consider yourself an “unwitting accomplice” any longer.

Daily, automated backups are yet another example of why high quality, Drupal-specific hosting is well worth the average costs. If you didn’t upgrade immediately then you should have a recent, complete backup available to restore the site from the day before the announcement.

Why would anyone want to hack my little site?

It is important to understand... big or small, you are no exception to this exploit. There is no site on the web today (Drupal or otherwise) which is not on some hacker’s radar, somewhere... more specifically, some hacker’s bot’s radar, somewhere. Ask your developer to tell you how many hacking attempts, per day (yes, that’s per day), your site gets.

We use our own, internally-developed monitoring application on all our client sites which gives us access to a great deal of client site information (such as illicit access attempts). It may take some digging but your developer should be able to give you that information. Trust us, you will be amazed at that number.

If for no other reason, your site will be hacked to have a backdoor installed. That way, an attacker will have undetectable access to your site at-the-ready. Should your site become of interest at any point in the future, they have an easy way in. Even if your site holds no interest, in and of itself, it will be hacked and used as a vector - an access point from which to launch other attacks against more desirable targets.

One of the most common reasons for hacking into a site is to gain access to computing resources (e.g. processing power). Hackers love to take over other machines and launch surreptitious, unrelated attacks on others (e.g. DDOS attacks). Another, recent use-case for this exploit is cryptocurrency mining. There is an interesting article on exactly that topic here.

There are approximately one million active Drupal sites on the web today. One of the Drupal-centric hosting companies mentioned earlier (Acquia) has stated publicly they have been stopping in excess of 100,000 exploit attempts per day – and that’s just one Drupal hosting company. You are not an ostrich. Don’t act like one. You can’t stick your head in the sand and hope you won’t be affected by this. If you do, you’ll be hurting yourself and others.

• If your site was not updated by 04.11.18 (at the latest), consider your site compromised. Restore it from a backup from 03.27.18 (the day preceding the Drupal Security Team public service announcement (PSA)).

• If you do not have a backup, talk to a developer about your options.

• In most cases, the best course of action will be to restore the site from a backup or re-build it.

• Attempting to sanitize your site by asking a developer to determine if you have been hacked is resource-prohibitive (time, effort, money) and will not guarantee your site is secure.

• With vanishingly few exceptions, this update should be performed by a professional Drupal development company.

• This is an urgent update. If your site was not updated then contact a developer to determine your next steps.

• Bots attack any vulnerable site, regardless of “importance” or “size”. Just as a search engine, bots crawl the web 24 hours a day, 7 days a week, 365 days a year looking for vulnerabilities (this one in particular).

• Vulnerable sites will have been hacked if for no other reason than to become vectors.

• DST risk score 25/25 - the highest possible urgency.

• The vulnerability is being actively exploited, at present (likely, millions of daily attempts).

• This vulnerability (as well as Drupalgeddon 1.0) can remain hidden and used when desired.

• If your site was hosted by one of the three providers mentioned in this article then you were protected from this exploit but you still need to update ASAP.

• Drupal remains one of (if not the) most secure platforms available today.

• Professional, Drupal-specific hosting is usually somewhat more expensive but well worth the expense (case in point).