Welcome to the second 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 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 web development and server security experts based in the UK, and addresses common questions we have received after the monster known as Drupalgeddon 2 begun.

In this post, we’ll take a look at some of the more obscure exploitations of Drupal sites as a result of Drupalgeddon 2018.

Has My Drupal Site Been Compromised?

One of the challenges for Drupal site administrators and agencies (who may manage many Drupal sites!) alike, is actually identifying whether a Drupal site has been compromised or not.

There is every chance that the attacker could have used the Drupalgeddon 2 vulnerability to exploit the site or compromise the integrity of the server; but may have no intention of defacing your site.

Usually, this is because the attacker has other motives. Many “script kiddies” become excited when a CMS vulnerability is discovered, as has been the case in the past with Drupal competitors WordPress and Joomla, but smarter, targeted attacks often leave no evident trace.

Such attacks are more passive, in that you may not notice any obvious signs of a breach itself, but you may notice signs such as your server resource load increasing rapidly over a short space of time, or your bandwidth costs going through the roof.

Why?

Because this smarter, targeted attack is more likely to be using your Drupal site, or potentially your entire web server, as a botnet. In other words, your server is now scanning for other servers running vulnerable versions of Drupal, and infecting them.

If you store sensitive customer data, perhaps, the attacker could have set up some kind of ‘information forwarding’ system which captures and sends them your user data either automatically or upon their request.

There’s also a substantial possibility that the hacker has installed other kinds of malware to conduct alternative activities using your server.

One popular manoeuvre is placing malware or Trojan horses which mine for cryptocurrencies. Even if you don’t use cryptocurrencies on your site or server, the chances are that the exploit will be configured to mine currencies from other vulnerable Drupal sites.

Overall, the stakes here are pretty high.

An attacker could have breached your server through your vulnerable Drupal installation, then proceeded to install the malware, and you could find yourself in a situation where your very own server is now probing and attacking (potentially many thousands) of other Drupal sites. If they’re vulnerable (i.e. not patched or updated), your server is the one held responsible.

The very least damage this could do is significantly damage your Google search rankings. Google, amongst other search engines and service providers (email providers like AOL, for instance), are likely to negatively mark, or even blacklist your server or domain name.

To add insult to injury, you’ll most likely notice your operating costs increase — as a result of massively increased server load and concurrently-running processes.

Besides this, however, it’s likely there will be no obvious signs, which makes it all the more important to run an audit of your Drupal site, and more importantly the server, to verify that all is clean.

Cocoon offers an affordable solution to this concern — Drupal Security Check, as part of our Drupal restoration service, Drupal Site Restore.

With Drupal Security Check, we’ll be able to audit your Drupal website, and your entire server, to identify whether any exploits exist and whether malware or other obscure injections may have been placed.

This is done using a refined method of both manual and programmatic checks, drilling down far into your installation to find any hidden infection.

If you’re clean, then of course you are good to go! Alternatively you may opt to make use of Drupal Padlock, a service which works to prevent imminent and future attacks from occurring, by locking down Drupal and the server configuration.

However, if malware or other malicious code or software is discovered, we’ll take the appropriate steps to swiftly remove any offending infection, whilst securing your Drupal installation and optimising your server configuration for maximum security.

You may wonder how it’s possible to guarantee increased security against unknown potential future Drupal vulnerabilities.

It’s quite simple, really.

Let’s say Drupal were to encounter another vulnerability, even on a similar level, in the future. Any damage can be limited, contained and swiftly acted upon if the server’s configuration is fool-proof and water-tight, as far as we currently know, in terms of Linux (or Microsoft/macOS Server) security best practises.

In more simpler terms, we can integrate a variety of systems which can:

• Identify an attacker before an exploit takes place, based on suspicious activity of the offender
• Permanently block all means of access to your server (HTTP, FTP, SSH) by the offending user (or bot, of course)
• Alert you or your IT/ISP support of the hack attempt immediately
• Automatically lock down the vulnerability or hole in the website to prevent other attackers from attempting a breach

Additionally, server security methods like this limit the potential damage that can be done, even if an attacker is able to identify and successfully exploit a vulnerability.

A very simple example is that they may only get as far as creating a malicious account, or altering the content of one page, before they are locked out of the server and the vulnerability is locked down until a Drupal patch or update is available.

In essence, the (potential) damage is contained, and is shut down far before the offending criminal is able to do worse damage, which could wreak havoc for your business, and your customers.

For site administrators seeking ultra security for Drupal and your server, Drupal Padlock may very well be your answer.

Stay safe, and happy site building!

—Your Cocoon Team