If you have heard about the Drupal security bugs from earlier this year, then it is time you took a closer look at what happened, and start taking some precautions to protect your own installations.This post describes the issues and which versions were at risk. We’ll also provide a series of tips to keep your websites secure, even if you aren’t running Drupal at the moment.

Drupal is a leading open source content management tool and runs about a tenth of the most popular websites. There were actually two different security vulnerabilities found that could allow remote control over a website by attackers. The first one was discovered in March and had the more widespread implications, where everyone running Drupal since v6 could be at risk. This could have potentially affected a million different users. This oldest version is no longer being officially supported, yet it is still popular and can be found in production use.

Drupal developers credited Jasper Mattsson, an employee of the Drupal security auditing firm Druid, for discovering the flaw. Researchers have also found active automated exploit attempts in the wild, along with a new attack method that places cryptomining software on the unpatched Drupal sites. (Cryptomining has become very popular in a number of other contexts, as we wrote about in February here.) This means that hackers are scanning IP address ranges, looking for vulnerable websites. This makes a compelling case to mitigate this vulnerability.

It is being called Drupalgeddon 2 (the originally named bug was found in 2014 and was a SQL injection issue that is described here). This new attack is somewhat similar, in that the flaw has to do with another code injection technique involving inputs to web forms that aren’t being properly checked. The issue was pretty serious: anyone can navigate to a specific URL on a Drupal-powered website and take it over. There is no authentication required and once you are in, you have complete control over the site. The flaw was serious enough that the main Drupal project website was taken down for a few minutes while the patch was applied. The patch is just a few lines of added code.

The second bug was discovered in June, and patches were issued for two versions, Drupal 8.3.4 and Drupal 7.56.  There have been no known attacks – yet. This bug had multiple exploits that including improper file handling and validations.

While all of these flaws were quickly patched, there are still many sites that haven’t applied the patches, even months after these events occurred.

Drupal put together a nice page of suggestions on improving your site security, and it is worth reviewing not just because of the specifics to that software, but the general implications of keeping your site current and secure. For example, you should make a forensic copy of your site before applying any changes (in case an attacker has already entered your site), decide whether to rollback or rebuild your servers, and figure out whom you should notify in case of a breach. There are also Drupal-specific suggestions, such as examining the menu_router and sessions database tables to see if there are traces of any suspicious activities, such as an open session for a new user that you don’t immediately recognize. And one researcher has suggested using the tool MinerBlock to ensure that your site isn’t taken over by any cryptominer malware in the future.

One other item that makes this exploit interesting is that just patching your server isn’t sufficient. An attacker could have already entered your system and still have complete control over your website. This is why their suggestions on examining user behavior are also important.

The general suggestions are useful for any website, no matter what code it is running. These include:

• Use multi-factor authentication to protect your logins. By now, this should be common practice, because of the numerous password breaches. However, it bears repeating.
• Use stronger passwords, this should also go without saying.
• Audit all your user accounts, and ensure that new ones or new admin roles haven’t been created by an attacker, and
• Don’t use an account named “admin” as your administrator’s account.

Finally, Drupal has two projects worth examining. The first is an extension called Paranoia that can block misused PHP pages and prevent privilege escalation techniques. The second is an older project called Security Review that will examine your php code for common programming mistakes. Both of these might be a good idea to deploy as well. As the project team says on this last webpage, “Security is a process,” so make these code reviews part of a continuous auditing of your website security.