Welcome to the first post in our Drupalgeddon 2 series! This series of blog posts are intended to give Drupal site administrators and agencies guidance and advice on what to do following exploitation due to the vulnerabilities discovered as part of Drupalgeddon 2.
For clarity, Drupalgeddon 2 is the term being used across the web to describe the recent vulnerabilities in the Drupal 6, 7 and 8 platforms.
These vulnerabilities have caused widespread chaos over the entire web; not least because many of the world’s largest and most important organizations use Drupal as their public-facing content management system of choice — namely for their official websites.
Our advice is provided by a world-class team of UK based web development and server security experts, and addresses common questions we have received after the monster known as Drupalgeddon 2 begun.
In this post, we’ll be addressing the issue of a Drupal site repetitively being ‘hacked’, or ‘compromised’.
In situations such as this, the website administrator will often report that their site was initially compromised, they cleaned the Drupal installation, but the site continues to be ‘hacked’ again and again, typically on a daily basis.
Sometimes, the site administrator will specify varying time intervals between these hacks — for instance, that the frequency increases with time, or the nature of the hack is different every time.
It’s also worth noting that site administrators in this position will likely have already patched or upgraded Drupal (whether that’s version 6, 7 or 8) to the latest version; thus believing that the site is now secure, but still report issues of repetitive exploitations of the Drupal site.
The key point to grasp here is that the Drupal site is most likely not being re-compromised at all.
Given the nature of Drupalgeddon 2, and the fact that exploits occur using remote code execution (more on that here), the most probable scenario is that the initial attacker left (numerous) backdoors in the Drupal installation, so that they can easily re-enter and deface the site or modify content without having to actually ‘hack’ the site again.
So, what’s a backdoor?
‘Backdoor’ is a term given to a method by which the attacker leaves a means for themselves to get back into your system quickly and easily, without having to physically ‘re-compromise’ the Drupal site as such.
This could take form in various ways.
For instance, files in the Drupal installation could be modified to easily allow for re-entry. Locating such a backdoor is very difficult for your average site administrator, simply because Drupal consists of so many files, and many site administrators will struggle to differentiate between native Drupal code and a backdoor injection.
For the record, Drupal 7 core consists of a sizable 1,300 files and Drupal 8 runs on over 19,000 files. Either way, that’s a heck of a lot to sift through, and that’s before you factor in custom Drupal themes, contrib modules, image uploads and the like.
In fact, the backdoors could be installed anywhere in the Drupal installation — they don’t necessarily have to be in files part of Drupal core.
It’s likely that they’re also present inside your sites directory, which is a big problem in itself.
The sites directory is practically the only part of your Drupal installation that does not get cleaned when you update Drupal core.
So essentially, if you have backdoors present within the sites directory, cleaning or updating Drupal core is going to be of very little (if any) benefit to the integrity of the site.
Let’s just make things simple: if there are backdoors present within your sites directory, you are very likely to experience what will appear to be a ‘hacked’ Drupal site over and over again.
The infected files within the sites folder will need to be thoroughly cleaned out before the site stands a chance at continuing without being constantly defaced.
And of course, it doesn’t stop there.
The backdoor files within the sites directory were put there through some kind of previous vulnerability, which needs to be remedied and secured itself.
If you updated to the latest stable version of Drupal core before removing any backdoors, you are likely to continue to see exploitations on the new version of Drupal, currently 7.59.
This is because the attacker already has access to your server, and therefore can make changes irrespective of the updated Drupal core files.
They’ll still be able to modify, add, remove, or steal data unless the backdoors were removed completely.
There's more...
And as if it couldn’t get worse, you then have your database to worry about.
It’s possible that the attacker has injected backdoors into the database, which will allow them easier entry into the site’s infrastructure again.
This is an even worse scenario, because Drupal sites (as all other CMSs) heavily rely on the database to serve content, and therefore simply wiping or ‘cleaning out’ the database is not a solution, as re-installing Drupal core would be.
If a backdoor has been created inside the database itself, your typical Drupal site administrator is unlikely to be able to find, yet identify it, even if solely because of the sheer size and complexity of a Drupal database. This situation is compounded even further on a large website, which is home to an extensive amount of content, files and user accounts.
That’s backdoors covered, mostly, but there are still other ways that an attacker could be continually able to ‘re-compromise’ your hacked Drupal site.
The server level
One such way, and it pains us to say it, is that the attacker could have managed to penetrate the web server further than at application-level.
In other terms, they haven’t just hacked Drupal; but potentially your entire web server too.
This would likely have happened subsequent to the Drupalgeddon 2 compromise.
Coupled with an insecure server setup, an attacker who was able to gain access to your site via the Drupalgeddon vulnerability could have easily penetrated further into the server and made modifications at the server-level, which could have resulted in a complete takeover of your website and server.
It’s possible that the attacker would opt not to change your login details (to Drupal or the server), which is used as a disarming technique, providing you with a false sense of security that nobody has accessed the website or server via your account, but site administrators should beware.
If the attacker was able to gain server-level access, this means that backdoors, malicious scripts and malware could be installed anywhere on the server — far outside your compromised Drupal installation — giving you a heck of a lot more to clean up.
Cleaning up a hacked website or server as a result of Drupalgeddon 2 is a tall-order for even professional and long-term users of Drupal. For this reason, Cocoon is proud to announce the launch of two new Drupal security services — Drupal Site Restore and Drupal Padlock.
Drupal Site Restore is a multi-tiered service which aims to restore your compromised Drupal site and/or server to its previous functioning state. If that’s not possible, we’ll be able to replicate the server configuration to match its previous state as closely as possible.
Our other offering, Drupal Padlock, provides water-tight security for your server. We’ll configure both the server and your Drupal installation to lock your sites down and help mitigate and reduce the likelihood of imminent and future attacks and exploitations.
We hope this post has helped answer some of your questions regarding repeatedly hacked Drupal sites as a result of Drupalgeddon 2.
It’s a challenging time for Drupal sites and Linux web servers right now, but we have your back, no matter the extent of the attack.
As always, if you have any further queries, please don’t hesitate to reach out.
Happy site building, and good luck!
—Your Cocoon Team