Drupal 7.32 Security PSA

Last week the Drupal project issued a PSA alert regarding the SQL injection vulnerability disclosed on October 15th. It was a serious bug, but the Drupal Security Team is among the best in the business, and they handled it as well as possible. However, users should know that updating to Drupal 7.32 does not remove backdoors that may have been installed, and any site that was exposed for very long should consider themselves potentially compromised.

Consistent with what we saw platform-wide, the Drupal Security team reported automated exploits appearing about seven hours after the update was released, preying on unpatched sites. It appears that professional black-hats pounced on the issue and were systematically working through lists of domain names to probe for weakness.

Since the 15th we have seen no exploited sites on Pantheon, and we have blocked tens of thousands of attacks. Thus far it appears that our platform-wide countermeasures were effective. However, concerned users may want to run the Site Audit or Drupalgeddon checks, which scan for after-the-fact evidence of a compromise. We've gotten some questions about these, which I will attempt to answer in this post.

Anatomy of an Automated Attack

Most of the attacks we blocked were attempting to establish a beachhead position for further exploits: either a dummy user with escalated privileges, or an entry into the menu_router table. These are both routes to executing arbitrary PHP on a site, either by allowing a dummy user to enable the PHP Filter module, or by setting up a menu route (a url) that would execute whatever PHP was delivered in a POST or COOKIE. 

From what has been reported by people who have sites off the Pantheon platform and were compromised, the next step is usually to try and install a PHP based "rootkit" or web-shell for continued adventures. Attackers are working their way up—injecting a bit of information into a database that then allows them to execute a small bit of PHP, which in turn downloads and installs a larger chunk of PHP.

This makes sense from an automated exploit standpoint: if you are going to spray attacks across a list of thousands (or even millions) of sites, your goal isn't to specifically do anything to any one of them—it's to set up as many assets as possible for later use.

Not All PHP Files Are Malicious

Most of the scanner modules look for rootkits or webshells by trying to identify files ending in .php which are flagged as malicious. While dropping .php files is the typical end goal of any automated exploiter, there are plenty of reasons you might have .php files as a healthy part of your Drupal installation. For instance, classes included with a module, or template files in a theme.

If a scan shows up with unexpected .php files, remain calm. This are cause for follow-up, not proof of an exploit. What are these files? What do they contain? If you don't know how to read PHP, try to find someone who does. Most importantly, contribute your findings back to the issue queue. 

Identifying new attack patterns is helpful, as are common false-positives. For instance, currently the Apache Solr connection class that comes bundled with Pantheon shows up as "suspicious" because it is a .php file, though that should be fixed soon.

Sketchy User Accounts and menu_router Entries

The fact that attacks adding users or menu_router items showed up in the wild, being automated, is a good indication that in black-hat circles these were known angles for exploiting Drupal via sql injection. While we blocked tens of thousands of these attacks, and have yet to find any confirmed instances of sites being compromised, users who were vulnerable due to waiting a day or more to update should still check their systems for signs of compromise. 

If you see suspicious users or menu_router entries, contact support and we'll investigate immediately. None have shown up on Pantheon yet, but we remain vigilant.

Most importantly, please be willing to contribute anything you see back. The pattern of sketchiness needs more data points to be defined. If it turns out you were affected, don't be a silent victim—the details of your exploit can help improve the state of general security. 

Stay Alert, Stay Alive

The internet is much larger and more important now than it was when Drupal first got started, and the underground ecosystem/economy of black-hat exploiters has expanded accordingly. If you spin up a new virtual machine in the cloud today, you'll start seeing brute force SSH attacks within a matter of hours. Staying up to date, deploying proper countermeasures, and insuring you have defense in depth are all key to keeping your online presence secure.

As a website platform devoted to serving professionals (or, as we like to say, "The Professional Website Platform") we take the security of our customers extremely seriously. It's not an easy challenge given that every site is different and may contain arbitrary custom code, but we continue to do everything in our power to defend the platform and arm our users to maintain security in their applications.