Drupal is one of the most popular Content Management Systems (CMS), along with WordPress and Joomla. In late March 2018, Drupal was affected by a major remote code execution vulnerability (CVE-2018-7600) followed by yet another (CVE-2018-7602) almost a month later, both aptly nicknamed Drupalgeddon 2 and Drupalgeddon 3.
These back-to-back vulnerabilities were accompanied by proof of concepts that translated into almost immediate real-world attacks. For many website owners, this situation was frustrating because the window of time to patch is getting considerably smaller. Additionally, updating or upgrading Drupal (or any other CMS for that matter) may have side effects, such as broken templates or functionality, which is why you need to make a full back up and test the changes in the staging environment before moving to production.
Rolling out a CMS is usually the easy part. Maintaining it is where most problems occur due to lack of knowledge, fear of breaking something, and, of course, costs. While this is an earned responsibility for each site owner to do due diligence with their web properties, the outcome is typically websites being severely out of date and exploited, often more than once.
Sample set and web crawl
We decided to choose a number web properties that had not yet been validated (including all versions of Drupal, vulnerable or not). Our main source of URLs came from Shodan and was complemented by PublicWWW, for a total of roughly 80,000 URLs to crawl. We were surprised to start hitting compromised sites quickly into the process and were able to confirm over 900 injected web properties.
Many of the results were servers hosted on Amazon or other cloud providers that were most likely set up for testing purposes (staging) and never removed or upgraded. Thankfully, they received little to no traffic. The other domains we encountered spanned a variety of verticals and languages, with one common denominator: an outdated version (usually severely outdated) of the Drupal CMS.
Figure 1: Crawling and flagging compromised Drupal sites using Fiddler
Drupal versions
At the time of this writing, there are two recommended releases for Drupal. Version 8.x.x is the latest and greatest with some new features, while 7.x.x is considered the most stable and compatible version, especially when it comes to themes.
Figure 2: Drupal’s two main supported branches
Almost half the sites we flagged as compromised were running Drupal version 7.5.x, while version 7.3.x still represented about 30 percent, a fairly high number considering it was last updated in August 2015. Many security flaws have been discovered (and exploited) since then.
Figure 3: Percentage of compromised sites belonging to a particular Drupal version
Payloads
A large number of Drupal sites that have been hacked via these two recent exploits were also infected with server-side malware, in particular with XMRig cryptocurrency miners. However, in this post we will focus on the client-side effects of those compromises. Neither are exclusive though, and one should expect that a hacked site could be performing malicious actions on both server and client side.
Unsurprisingly, web miners were by far the most common type of injection we noticed. But we also came across a few different social engineering campaigns.
Figure 4: Breakdown of the most common payloads
Web miners
Drive-by mining attacks went though the roof in the fall of 2017 but slowed down somewhat at the beginning of the year. It’s safe to say that the recent Drupal vulnerabilities have added fuel to the fire and resulted in increased activity. Coinhive injections remain by far the most popular choice, although public or private Monero pools are gaining traction as well.
We are seeing the same campaign that was already documented by other researchers in early March and is ensnaring more victims by the day.
Figure 5: A subdomain of Harvard University’s main site mining Monero
Fake updates
This campaign of fake browser updates we documented earlier is still going strong. It distributes a password stealer of Remote Administration Tool (RAT).
Figure 6: A compromised Drupal site pushing a fake Chrome update
Tech support scams (browlocks)
Redirections to browser locker pages—a typical approach for unveiling tech support scams. The most common redirection we were able to document involved an intermediary site redirecting to browser locker pages using the .TK Top Level Domain (TLD) name.
mysimplename[.]com/si.php
window.location.replace("https://hispaintinghad[.]tk/index/?1641501770611");
window.location.href = "https://hispaintinghad[.]tk/index/?1641501770611";
Figure 7: A compromised Drupal host redirecting to a browser locker page
Web miners and injected code
We collected different types of code injection, from simple and clear text to long obfuscated blurbs. It’s worth noting that in many cases the code is dynamic—most likely a technique to evade detection.
Figure 8: Collage of some of the most common miner injections
Snapshots
The following are some examples of compromised sites sorted by category. We have contacted all affected parties to let them know their resources are being used by criminals to generate profit from malicious cryptomining or malware infections.
Figure 9: Education (University of Southern California)
Figure 10: Government (Arkansas Courts & Community Initiative)
Figure 11: Political party (Green Party of California)
Figure 12: Ad server (Indian TV Revive Ad server)
Figure 13: Religion (New Holly Light)
Figure 14: Health (NetApp Benefits)
Figure 15: Conferences (Red Hat partner conference)
Figure 16: Tech (ComputerWorld’s Brazilian portal)
Malicious cryptomining remains hot
It is clear that right now, cryptomining is the preferred kind of malicious injection. There are many public but also private APIs that make the whole process easy, and unfortunately they are being abused by bad actors.
Compromised sites big and small remain a hot commodity that attackers will try to amass over time. And because patching remains an issue, the number of potential new victims never stops growing. In light of this, website owners should look into other kinds of mitigation when patching is not always an immediate option, and check what some people call virtual patching. In particular, Web Application Firewalls (WAFs) have helped many stay protected even against new types of attacks, and even when their CMS was vulnerable.
Source:https://blog.malwarebytes.com/threat-analysis/2018/05/look-drupalgeddon-client-side-attacks/
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
