How to tell if my Drupal site is comprised from the SA-CORE-2018-002 -- 2018 March exploit?

Question

Just released exploit: https://www.drupal.org/sa-core-2018-002 --- Drupal core - Highly critical - Remote Code Execution - SA-CORE-2018-002

• How can I tell if someone used this exploit to hack my site?
• What can they do with this exploit if executed properly?
• I can't update my Drupal sites now, what is a good alternative to patch up this hole easily?

Answer 1

What could happen

I had a personal Drupal site hacked during Drupalgeddon, an exploit of similar severity (though of a different type). In terms of "what could happen," in that case the hacker put several "back door" files into my codebase (I knew very little about development at the time, and had no Git repository), from which he could send out spam email. The domain involved was blacklisted in spam filters, and it was a huge mess to be able to send email from that domain for the several months I had kept it afterward.

Since this vulnerability permits remote code execution, the attacker could presumably install modules to carry out phishing attacks, carry out commands on the command line with php exec(), steal passwords, and thereby compromise much of your server. The damage could range from something as simple as your machine being recruited as a spam engine or botnet node, or if you have sensitive information, the attacker might steal it and either resell it or blackmail you, depending on the information and the attacker's motives.

How to tell if you've been hacked

Most of the time, your site will not be defaced. When two groups of 14 year old script kiddies go at each other you might see a site defaced with Goatse images (NSFW), but unless the hacker has something against you personally he isn't going to do this. The goal for the hacker is either money or the ability to commit crimes with someone else's computer.

Now with that in mind, common things you will see are new users being created (especially admin users), and in the logs you may see a particular IP sending only one type of (abnormal) request. In the Drupalgeddon case, I was able to figure it out by seeing POST requests to a php file in my access log.

If you cannot patch your site right away

If you cannot patch the site now, I would recommend cutting the apache/nginx server so no one can get to your site. Or, have the server direct all traffic to an HTML page explaining you are down for maintenance, aka "hard maintenance mode." In all cases, you do not want to allow a visitor to have any shot at bootstrapping Drupal, until you can get an upgrade or patch in place.

And thinking back to my site getting hacked, remember that the first Drupalgeddon attacks started 7 hours after the release, and it was in the form of a script that auto-hacked thousands of sites. Move quickly!

If you are hacked

Hopefully you have a backup, in which case the best bet is to "nuke the whole site from orbit" and start over with a new server. I did a manual DB and file audit once because I didn't have Git and regular backups in place - it takes a very long time, but if it does happen, take a deep breath, and learn Git and learn how to set up a proper backup environment. If you have a business and its a customer site, tell them the truth up front. You will probably lose them, but better to lose a customer (you can get new ones) than your reputation.

Answer 2

How can I tell if someone used this exploit to hack my site?

Your Drupal 7 or 8 site can experience loss or theft of data, data can be removed, deleted or changed, wreaking havoc on the site in many different ways.

See this Stack Exchange post for general information on checking to see if your website has been hacked.

What can they do with this exploit if executed properly?

The exploit is a remote code execution vulnerability, which means any data has the potential of being affected.

This exploit has been given a risk score of 21/25, which is almost the highest that it gets. This risk score also defines the following vulnerabilities, among others:

• AC (Access complexity): easy (no skill) to access and exploit
• A (Authentication): no special authentication needed
• Cl (Confidentiality impact): all non-public data is accessible
• II (Integrity impact): All data can be modified or deleted

Read more about risk scoring and definitions here.

I can't update my Drupal sites now, what is a good alternative to patch up this hole easily?

There is a patch available if you are unable to update core right away. From Drupal.org:

If you are running 7.x, upgrade to Drupal 7.58. (If you are unable to update immediately, you can attempt to apply this patch to fix the vulnerability until such time as you are able to completely update.)

If you are running 8.5.x, upgrade to Drupal 8.5.1. (If you are unable to update immediately, you can attempt to apply this patch to fix the vulnerability until such time as you are able to completely update.)

To read more, here is an FAQ about the exploit

Answer 3

How to patch Drupal 7.x by hand against Drupal core - Highly critical - Remote Code Execution - SA-CORE-2018-00

If you are on Drupal 7.x and are unable to update your live site to 7.58, aren't familiar with applying patches, or are on a Drupal version for which the patch fails do the following :

1> Download and extract Drupal 7.58.

2> Copy the /includes/request-sanitizer.inc file from the 7.58 distribution into your website's /includes directory ( easiest via FTP or your hosting control panel file manager ).

3> Edit the version of /includes/bootstrap.inc on your live website ( backup first ! ). Find the function _drupal_bootstrap_configuration(). Add the following 3 lines after the statement drupal_settings_initialize(); :

// Sanitize unsafe keys from the request.
require_once DRUPAL_ROOT . '/includes/request-sanitizer.inc';
DrupalRequestSanitizer::sanitize();

Save.

Relax.

Answer 4

Here's a simple 1-2-3 process all here:

1. Copy code to clipboard from here https://cgit.drupalcode.org/drupal/rawdiff/?h=7.x&id=2266d2a83db50e2f97682d9a0fb8a18e2722cba5 or as quoted below.
2. create a blank file called 2018march.patch file in the root folder of your drupal directory.
3. Paste the code into the file
4. Run the command in the terminal: patch -p1 < 2018march.patch

If you don't have SSH or terminal access. You'll need to do it manually by hand using user's @elb solution.

diff --git a/includes/bootstrap.inc b/includes/bootstrap.inc
index 655db6d..880557e 100644
--- a/includes/bootstrap.inc
+++ b/includes/bootstrap.inc
@@ -2632,6 +2632,10 @@ function _drupal_bootstrap_configuration() {
   timer_start('page');
   // Initialize the configuration, including variables from settings.php.
   drupal_settings_initialize();
+
+  // Sanitize unsafe keys from the request.
+  require_once DRUPAL_ROOT . '/includes/request-sanitizer.inc';
+  DrupalRequestSanitizer::sanitize();
 }

 /**
diff --git a/includes/request-sanitizer.inc b/includes/request-sanitizer.inc
new file mode 100644
index 0000000..1daa6b5
--- /dev/null
+++ b/includes/request-sanitizer.inc
@@ -0,0 +1,82 @@
+<?php
+
+/**
+ * @file
+ * Contains code for sanitizing user input from the request.
+ */
+
+/**
+ * Sanitizes user input from the request.
+ */
+class DrupalRequestSanitizer {
+
+  /**
+   * Tracks whether the request was already sanitized.
+   */
+  protected static $sanitized = FALSE;
+
+  /**
+   * Modifies the request to strip dangerous keys from user input.
+   */
+  public static function sanitize() {
+    if (!self::$sanitized) {
+      $whitelist = variable_get('sanitize_input_whitelist', array());
+      $log_sanitized_keys = variable_get('sanitize_input_logging', FALSE);
+
+      // Process query string parameters.
+      $get_sanitized_keys = array();
+      $_GET = self::stripDangerousValues($_GET, $whitelist, $get_sanitized_keys);
+      if ($log_sanitized_keys && $get_sanitized_keys) {
+        _drupal_trigger_error_with_delayed_logging(format_string('Potentially unsafe keys removed from query string parameters (GET): @keys', array('@keys' => implode(', ', $get_sanitized_keys))), E_USER_NOTICE);
+      }
+
+      // Process request body parameters.
+      $post_sanitized_keys = array();
+      $_POST = self::stripDangerousValues($_POST, $whitelist, $post_sanitized_keys);
+      if ($log_sanitized_keys && $post_sanitized_keys) {
+        _drupal_trigger_error_with_delayed_logging(format_string('Potentially unsafe keys removed from request body parameters (POST): @keys', array('@keys' => implode(', ', $post_sanitized_keys))), E_USER_NOTICE);
+      }
+
+      // Process cookie parameters.
+      $cookie_sanitized_keys = array();
+      $_COOKIE = self::stripDangerousValues($_COOKIE, $whitelist, $cookie_sanitized_keys);
+      if ($log_sanitized_keys && $cookie_sanitized_keys) {
+        _drupal_trigger_error_with_delayed_logging(format_string('Potentially unsafe keys removed from cookie parameters (COOKIE): @keys', array('@keys' => implode(', ', $cookie_sanitized_keys))), E_USER_NOTICE);
+      }
+
+      $request_sanitized_keys = array();
+      $_REQUEST = self::stripDangerousValues($_REQUEST, $whitelist, $request_sanitized_keys);
+
+      self::$sanitized = TRUE;
+    }
+  }
+
+  /**
+   * Strips dangerous keys from the provided input.
+   *
+   * @param mixed $input
+   *   The input to sanitize.
+   * @param string[] $whitelist
+   *   An array of keys to whitelist as safe.
+   * @param string[] $sanitized_keys
+   *   An array of keys that have been removed.
+   *
+   * @return mixed
+   *   The sanitized input.
+   */
+  protected static function stripDangerousValues($input, array $whitelist, array &$sanitized_keys) {
+    if (is_array($input)) {
+      foreach ($input as $key => $value) {
+        if ($key !== '' && $key[0] === '#' && !in_array($key, $whitelist, TRUE)) {
+          unset($input[$key]);
+          $sanitized_keys[] = $key;
+        }
+        else {
+          $input[$key] = self::stripDangerousValues($input[$key], $whitelist, $sanitized_keys);
+        }
+      }
+    }
+    return $input;
+  }
+
+}