Drupal SA-2018-002 Weaponized: Coin Mining Exploits in the Wild

Drupal SA-2018-002 has been weaponized. Within 12 hours of a published proof-of-concept by security researchers, we can see automated attempts to systematically exploit sites across the internet.

Attempted coin miner installations over the past 24 hours

Attempted coin miner installations over the past 24 hours

 

Pantheon has had platform-wide mitigations in place since an hour after the original Drupal security announcement over two weeks ago. In addition to protecting our customers by blocking attempted exploits, our filter included payload logging, which means we can analyze the attempted attacks to determine their objective.

Compared to the last time there was an issue of this severity, there’s a new class of attack: coin mining. In 2014, BitCoin and its cousins were still a geek curiosity. Today, they’re a lucrative (if highly volatile) business, with mass appeal. It makes sense: why bother to ransomware a site when you can use their CPU to just mine coin directly?

Payload Analysis

There are a few different classes of exploit which we can observe in the first 24 hours. First, there are a wide array of simple probing attacks, which simply try to echo out a certain string, or cause the server to “phone home” to some remote server by calling wget or curl to ping back to a remote url. The goal of this exploit is likely to know who to come back for later.

Another level of attack is an attempt to install a beachhead file. These are usually small PHP scripts which will sit around waiting for subsequent requests; they’ll run eval() or and equivalent on whatever data blob the attacker decides to send down the line. Files we saw in our initial analysis included wer.php, l.php, config.php, and rxr.php, but honestly the specific filenames will change all the time. Any unexpected PHP file should be considered suspect.

While these two attack types are familiar, we’re now seeing a more sophisticated exploit which attempts to connect the server for a Drupal website to a botnet, install coin mining software, and turn the CPU of the server into a revenue generator for someone else. This exploit has been independently confirmed on the SANS Technology Institute's Internet Storm Center.

This high-level attack is fairly well obfuscated, includes resilience features such as creating a crontab to reinstall itself if it’s found and removed, and contains a script that will attempt to kill off any competing miners. That’s pretty impressive stuff.

We also saw slightly less sophisticated attempts to download a known trojan miner onto the server that powers Drupal, and I expect we’ll see more attempts around coin mining in the coming days. Given the immediate monetary benefit to a black-hat actors who can turn a vulnerable website into an active mining node, it seems like this could be the new go-to objective when targeting website vulnerabilities.

Keeping Our Customers Safe

The only way to know you are completely safe is to update your Drupal website so it is no longer vulnerable to this kind of attack. If you haven’t done this yet, please do so now. We at Pantheon try to do everything we can to protect our customers:

  • We make keeping your CMS up to date manageable with one-click core updates, and allow central teams to automate updates across hundreds or even thousands of sites.

  • We deploy Drupal (and WordPress) in an immutable configuration, meaning the CMS cannot write files to any area outside the uploads directory (which is locked down). This prevents a large class of attacks from finding a foothold on our platform.

  • We are also able to deploy platform-wide mitigations. In this case we were able to sanitize attempted exploits within an hour of the initial security release, two weeks before widespread exploit attempts began. This benefits our customers, but also allows us to capture attempted exploits and provide insight into what we see to the wider community.

Internet security is a team effort. We’re happy to support the work of the Drupal Security Team, and are actively sharing the details of our findings with them and other platform providers. Michael Schmid has also posted what he's been seeing from Amazee as well.

I would like to specifically thank the Drupal Security Team and Narayan Newton of Tag1 Consulting for helping to diagnose some of the payloads today in the DrupalCon Nashville Sprint rooms.

Topics Drupal Hosting, Drupal Planet, Security, Drupal