SaltStack Salt vulnerabilities actively exploited by attackers, patch ASAP!
Two vulnerabilities in SaltStack Salt, an open-source remote task and configuration management framework, are being actively exploited by attackers, CISA warns.
About SaltStack Salt
Salt is used for configuring, managing and monitoring servers in datacenters and cloud environments.
The Salt installation is the “master” and each server it monitors runs an API agent called a “minion”. The minions send state reports to the master and the master publishes update messages containing instructions/commands to the minions. The communication between the master and its minions is secured (encrypted).
About the vulnerabilities
Discovered by F-Secure researchers, CVE-2020-11651 (an authentication bypass flaw) and CVE-2020-11652 (a directory traversal flaw) can be exploited by remote, unauthenticated attackers.
According to the researchers, the vulnerabilities allow attackers to “connect 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.”
The attackers can thusly achieve remote command execution as root on both the master and all minions that connect to it.
The vulnerabilities affect all Salt versions prior to 2019.2.4 and 3000.2, which were released last week.
“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,” the researchers added.
Active exploitation
F-Secure warned that there are over 6,000 Salt masters exposed to the public Internet, so they chose not to publish a PoC.
But, they said, “any competent hacker will be able to create 100% reliable exploits for these issues in under 24 hours,” and they were right: a few days later a researcher reported their honeypots already being targeted.
Even though SaltStack did send an advanced notice about the critical nature of the flaws and the need for a quick update and additional mitigation actions to their users, not everybody reacted promptly.
During the weekend, attackers successfully leveraged the flaws to gain access to the infrastructure of the LineageOS project, the Ghost blogging platform, and one of the Certificate Transparency logs (CT2) operated by DigiCert. In all three cases, the attackers’ goal was to install cryptominers.
UPDATE (May 4, 2020, 5:10 a.m. PT):
“Upon notification of the CVE, SaltStack took immediate action to remediate the vulnerability, develop and issue patches, and communicate to our customers about the affected versions so they can prepare their systems for update. Although there was no initial evidence that the CVE had been exploited, we have confirmed that some vulnerable, unpatched systems have been accessed by unauthorized users since the release of the patches,” Alex Peay, SVP, Product and Marketing, SaltStack, told Help Net Security.
“We must reinforce how critical it is that all Salt users patch their systems and follow the guidance we have provided outlining steps for remediation and best practices for Salt environment security. It is equally important to upgrade to latest versions of the platform and register with support for future awareness of any possible issues and remediations. As the primary maintainers of the Salt Open Project, trusted by the world’s largest businesses to automate digital infrastructure operations and security, we take this vulnerability and the security of our platform very seriously. More information about our response and handling of CVEs is available in our Knowledge Base.”
UPDATE (May 4, 2020, 9:45 a.m. PT):
“Yesterday, May 3, DigiCert announced that it is deactivating its Certificate Transparency (CT) 2 log server after determining that the key used to sign SCTs may have been exposed via critical SALT vulnerabilities. We do not believe the key was used to sign SCTs outside of the CT log’s normal operation, though as a precaution, CAs that received SCTs from the CT2 log after May 2 at 5 p.m. U.S. Mountain Daylight Time (MDT) should receive an SCT from another trusted log,” a DigiCert spokesperson told Help Net Security.
“Three other DigiCert CT logs: CT1, Yeti and Nessie, are not affected as they are run on completely different infrastructure. The impacts are limited to only the CT2 log and no other part of DigiCert’s CA or CT Log systems.”
The spokesperson added that DigiCert has been planning for some time to shut down CT2, in order to move the industry toward their newer and more robust CT logs, Yeti and Nessie.
“We notified the industry of our intention to terminate signing operations of CT2 on May 1 but pushed back the date based on industry feedback. This timeline has now been moved up, with the CT2 log in read-only mode effective May 3,” they explained.
“Because of Google’s implementation of CT that requires SCTs be posted in multiple logs in order for a certificate to be valid, active TLS certificates posted to the CT2 log should continue to work as expected if issued before May 2 at 5 p.m. MDT.”