Easily Exploitable RCE Salt Vulnerabilities Discovered that Require Urgent Attention

Researchers at F-Secure have identified two high severity vulnerabilities in the SaltStack Python-based open source Salt project, which can allow remote code execution as root for a full takeover of vulnerable servers. F-Secure believes the vulnerabilities are likely to be exploited in a matter of hours.

Salt is a popular configuration tool that is used for datacenter and cloud server management to monitor the state of servers and perform updates. Each server uses an agent called minion to connect to a master. Salt installations collect state reports from the minions, which are passed to the master, which then sends actionable update messages to the minions. The updates that are sent out are often configuration changes, but F-Secure explains that they can include commands that can be run in parallel on multiple managed systems, or potentially all systems asynchronously. If an adversary were to compromise the master, it would be possible to send malicious commands to all servers in the cluster at the same time.

F-Secure identified a pair of vulnerabilities in the default communication protocol – ZeroMQ – that allows the master to be remotely compromised, thus placing all servers in the cluster at risk. The first vulnerability, tracked as CVE-2020-11651, is an authentication bypass vulnerability. The second, CVE-2020-1652, is directory traversal flaw due to improper sanitization of input. The vulnerabilities allow a remote, unauthenticated attacker to access the entire filesystem of the master server and push malicious updates to all minions.

F-Secure explained that the master uses two ZEROMQ channels to communicate, one is a request server that minions connect to for providing status reports and the other is a publish server, where the master sends out commands to the minions that they can act on.

The vulnerabilities allow an attacker to connect to the request server port without authentication and push out arbitrary commands to the minions, read and write files anywhere on the master server’s filesystem and also obtain the secret key to authenticate to the master as root. Using these flaws, an attacker can take full control of the master server and all minions that connect to that master server.

Under F-Secure’s responsible disclosure policy, the vulnerabilities were reported to SaltStack and the flaws have been corrected in version 3000.2. SaltStack has also released a patch for the previous version, 2019.2.4.

While some configurations will have been set to receive updates automatically, many will require a manual update. F-Secure conducted a scan and found there are more than 6,000 instances of the vulnerable service that are exposed to the public internet and could be attacked.

F-Secure believes that any competent hacker would be able to develop 100% reliable exploits for the vulnerabilities in less than 24 hours, so updates should be performed as soon as possible.

In addition to updating or patching, F-Secure recommends additional actions should be taken to improve security:

“Adding network security controls that restrict access to the salt master (ports 4505 and 4506 being the defaults) to known minions, or at least block the wider Internet, would also be prudent as the authentication and authorization controls provided by Salt are not currently robust enough to be exposed to hostile networks.”

F-Secure has also provided information on how to detect if Salt servers have already been compromised:

Exploitation of the authentication vulnerabilities will result in the ASCII strings “_prep_auth_info” or “_send_pub”  appearing in data sent to the request server port (default 4506). These strings should not appear in normal, benign, traffic.

Published messages to minions are called “jobs” and will be saved on the master (default path /var/cache/salt/master/jobs/). These saved jobs can be audited for malicious content or job ids (“jids”) that look out of the ordinary. Lack of suspicious jobs should not be interpreted as absence of exploitation however.

Author: Richard Anderson

Richard Anderson is the Editor-in-Chief of NetSec.news