A look into Drupalgeddon’s client-side attacks
Credit to Author: Jérôme Segura| Date: Fri, 18 May 2018 15:00:00 +0000
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("http://hispaintinghad[.]tk/index/?1641501770611"); window.location.href = "http://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.
Malwarebytes continues to detect and block malicious cryptomining and other unwanted redirections.
Indicators of compromise
Coinhive
-> URIs
cnhv[.]co/1nt9z coinhive[.]com/lib/coinhive.min.js coinhive[.]com/lib/cryptonight.wasm coinhive[.]com/lib/worker-asmjs.min.js?v7 ws[0-9]{3}.coinhive[.]com/proxy-> Site keys
CmGKP05v2VJbvj33wzTIayOv6YGLkUYN f0y6O5ddrXo1be4NGZubP1yHDaWqyflD kAdhxvdilslXbzLAEjFQDAZotIVm5Jkf MKr3Uf5CaT88pcqzAXltkBu4Us5gHWaj NL9TTsyGeVU8FbKR9fUvwkwU4qPJ4Z2I no2z8X4wsiouyTmA9xZ0TyUdegWBw2yK oHaQn8uDJ16fNhcTU7y832cv49PqEvOS PbNDLKIHLCM0hNXOIM7sRTsk66ZuAamf RYeWLxbPVlfPNsZUh231aLXoYAdPguXY XoWXAWvizTNnyia78qTIFfATRgcbJfGx YaUkuGZ3pmuPVsBMDxSgY45DwuBafGA3
Crypto-Loot
-> URI
cryptaloot[.]pro/lib/justdoit2.js
-> Keys
48427c995ba46a78b237c5f53e5fef90cd09b5f09e92 6508a11b897365897580ba68f93a5583cc3a15637212 d1ba2c966c5f54d0da15e2d881b474a5091a91f7c702
EthPocket
eth-pocket[.]com:8585 eth-pocket[.]de/perfekt/perfekt.js
JSECoin
jsecoin[.]com/platform/banner1.html?aff1564&utm_content=
DeepMiner
greenindex.dynamic-dns[.]net/jqueryeasyui.js
Other CryptoNight-based miner
cloudflane[.]com/lib/cryptonight.wasm
FakeUpdates
track.positiverefreshment[.]org/s_code.js?cid=220&v=24eca7c911f5e102e2ba click.clickanalytics208[.]com/s_code.js?cid=240&v=73a55f6de3dee2a751c3 185.244.149[.]74 5.9.242[.]74
Tech scams
192.34.61[.]245 192.81.216[.]165 193.201.224[.]233 198.211.107[.]153 198.211.113[.]147 206.189.236[.]91 208.68.37[.]2 addressedina[.]tk andtakinghis[.]tk andweepover[.]tk asheleaned[.]tk baserwq[.]tk blackivory[.]tk blownagainst[.]tk cutoplaswe[.]tk dearfytr[.]tk doanythingthat[.]tk faithlessflorizel[.]tk grey-plumaged[.]tk haddoneso[.]tk handkerchiefout[.]tk himinspectral[.]tk hispaintinghad[.]tk ifheisdead[.]tk itshandupon[.]tk iwouldsay[.]tk leadedpanes[.]tk millpond[.]tk mineofcourse[.]tk momentin[.]tk murdercould[.]tk mysimplename[.]com nearlythrew[.]tk nothinglikeit[.]tk oncecommitted[.]tk portraithedid[.]tk posingfor[.]tk secretsoflife[.]tk sendthemany[.]tk sputteredbeside[.]tk steppedforward[.]tk sweeppast[.]tk tellingmeyears[.]tk terriblehope[.]tk thatwonderful[.]tk theattractions[.]tk thereisnodisgrace[.]tk togetawayt[.]tk toseethem[.]tk wickedwere[.]tk withaforebodingu[.]tk
The post A look into Drupalgeddon’s client-side attacks appeared first on Malwarebytes Labs.