Critical SaltStack Flaws Allow Full RCE as Root on Cloud Servers

Critical SaltStack Flaws Allow Full RCE as Root on Cloud Servers

Recently, the open source SaltStack that is used to help enterprise IT organizations orchestrate and automate difficult IT tasks was confirmed contains high-level security vulnerabilities that allow full remote code execution as root on servers in data centers and cloud environments. The vulnerabilities were identified as two different classes with allocated CVE IDs CVE-2020-11651 and CVE-2020-11652 by F-Secure researchers earlier this March and disclosed a day after SaltStalk release a patch (version 3000.2) that addresses the problem.

"One becomes an authentication bypass where functionality is accidentally exposed to unauthenticated network clients, the other becomes a traversal directory where untrusted inputs (e.g., Parameters in network requests) are not properly sanitized, permitting unrestricted access to the entire system master file server. " said the Cyber Security Researcher of the Lab-F-Secure Organization.

Salt is a powerful Python-based automation and remote execution engine that's designed to allow users to issue commands to multiple machines directly. Slat employs an architecture that automates the process of pushing out configuration and software updates from a central repository using a "master" node that deploys the changes to a target group of "minions" (e.g., servers). To communicate, the master and minions use two ZeroMQ channels, and according to F-Secure researchers, the pair of flaws reside within the tool's ZeroMQ protocol.

The authentication bypass can be achieved because the ClearFuncs class processes unauthenticated requests and unintentionally exposes the “_send_pub().” This is the method used to queue messages from the master publish server to the minions, and can be used to send arbitrary commands. Such messages can be used to trigger minions to run arbitrary commands as root. Also, “the ClearFuncs class also exposes the method _prep_auth_info(), which returns the root key used to authenticate commands from the local root user on the master server and make a remote call administrative commands on the master server. This is how unintentional exposure provides a remote un-authenticated attacker with root-equivalent access to the salt master.”

As for the directory traversal, the “wheel” module contains commands used to read and write files under specific directory paths, and the bugs allow attackers to the request server port to bypass all authentication and authorization controls and publish arbitrary control messages, read and write files anywhere on the master server filesystem and steal the secret key used to authenticate to the master as root.

In order to avoid attackers to exploit these vulnerabilities, it is highly recommended for Salt users to update the software packages to the latest version. Also, for a better precaution, Salt user can do additional security control and remediation. In this article we provide you two remediation approaches that might help you:

General Remediation

  • Restrict who can directly log into your Salt master system.
  • Use SSH keys secured with a passphrase to gain access to the Salt master system.
  • Track and secure SSH keys and any other login credentials that you and your team need to gain access to the Salt master system.
  • Use a hardened bastion server or a VPN to restrict direct access to the Salt master from the internet.
  • Don't expose the Salt master any more than what is required.
  • Harden the system as you would with any high-priority target.
  • Keep the system patched and up-to-date.
  • Use tight firewall rules.

SaltStack Remediation

  • Use Salt's Client ACL system to avoid having to give out root access to run Salt commands.
  • Use Salt's Client ACL system to restrict which users can run what commands.
  • Make use of Salt's event system and reactor to allow minions to signal the Salt master without requiring direct access.
  • Run the salt-master daemon as non-root.
  • Disable which modules are loaded onto minions with the disable_modules setting. (for example, disable the cmd module if it makes sense in your environment.)
  • Look through the fully-commented sample master and minion config files. There are many options for securing an installation.
  • Run masterless-mode minions on particularly sensitive minions. There is also Salt SSH or the modules.sudo if you need to further restrict a minion.
  • Monitor specific security releated log messages. Salt salt-master logs attempts to access methods which are not exposed to network clients. These log messages are logged at the error log level and start with Requested method not exposed.

As a trusted IT security expert partner in Indonesia Defenxor is intended to encourage enterprises and organizations to always keep updated and be aware of the latest IT security issues. Through this article we hope we can help you notice the current IT challenges and how to address them. Find out how Defenxor can help you improve and manage your IT security system by contacting our team.