“The impact is the complete execution of remote commands as root on the master and all the servants”
Hackers can break into Salt servers and potentially control other servers from there
The Salt configuration tool fixed two vulnerabilities, the combined effect of which was to expose Salt installations to full control by an attacker. A fix for the issues was released last night, but systems that are not set up for automatic updating can still be vulnerable.
The vulnerabilities were discovered by the security company F-Secure and the assigned CVE numbers CVE-2020-11651 and CVE-2020-11652. They are patched Salt 3000.2 and, for the previous stable version, 2019.2.4. Older versions will have to be corrected manually.
Salt is a SaltStack tool that has both commercial and Open source editions. It allows you to define system components and applications in text as a “salt state” and then apply them to remote systems in a data center or on a public cloud. In Salt terminology, a Master is a central Salt server that issues commands, and a Minion is a remote process that listens for and executes commands. The communication protocol is ZeroMQ.
The first vulnerability, CVE-2020-11651, is an authentication bypass which, according to F-Secure, “unintentionally exposes the _send_pub () method, which can be used to queue messages directly on the server. master publication. These messages can be used to trigger servers to execute arbitrary commands as root. “
As if that were not enough, CVE-2020-11652 is a directory traversal vulnerability in the “wheel” module used to read and write files. “The entries for these functions are concatenated with the target directory and the resulting path is not canonicalized, leading to an escape from the intended path restriction,” added the researchers. “The impact is the complete execution of remote commands as root on the master and all the servants who connect to it.”
The implications are serious, as they potentially give the wrong actor not only control of the servers, but also the ability to configure new resources on clouds such as AWS.
F-Secure refuses to publish a proof of concept exploit because “it would only harm all users who are slow to patch”. That said, it’s not much protection, as the company also said, “We expect any skilled hacker can create 100% reliable exploits for these problems in less than 24 hours.”
The disclosure of the vulnerabilities to SaltStack has been delayed for several days as the company expects that the issues will be resolved. reported via encrypted and signed emails, but the GPG key released for this purpose expired in 2018, said F-Secure. An updated key was finally released and a report was received by SaltStack on March 20.
SaltStack got the CVE numbers in early April and a week ago on April 23 warned users that they should not expose the master servers to the Internet and prepare for an urgent fix.
Salt users had little time to respond, and F-Secure reported the following concern: “An analysis revealed that more than 6,000 instances of this service were exposed to the public Internet. Updating all these installations can prove difficult as we expect that not all of them have been configured to automatically update the Salt software packages. “
It is difficult to patch open source projects without simultaneously revealing the vulnerability, which can be a factor in the timing of disclosure.
Exposing a Salt master to the Internet is not best practice, and firewall security must be implemented. “Adding network security controls that restrict access to the Salt master (ports 4505 and 4506 being the default) to known servers, or at least blocking wider internet, would also be prudent because authentication controls and authorization provided by Salt are not currently robust enough to be exposed to hostile networks, “said F-Secure.
Another disadvantage is that by solving the authentication problem, the developers of SaltStack have introduced a bug. “The _minion_runner method should be minion_runner (without the underscore prefix). This typo breaks the execution method of the publishing module,” the documents said. This may well break the scripts in use. A solution to this problem is promised “in mid-June 2020”.
According to a recent “cloud state” of Flexera report Salt is used by around 17% of companies deploying a cloud. The newly reported vulnerability first shows that automatic updating is worth considering if it is not already enabled, and second, that network security is essential alongside patch management. ®
Webcast: Build the Next Generation of Your Business in the Public Cloud