We know that SSH keys are highly desirable to cyber criminals, largely based on the unfettered privileged access that they grant. But often it can be difficult to collect more than anecdotal evidence of their misuse. Last week, we saw two new vulnerabilities in SaltStack (CVE-2020-11651 and CVE-2020-11652) that illustrated the desirability of SSH keys to cyber criminals. One vulnerability was in an open-source remote task and the other in a configuration management framework.
Worried about audit failures due to SSH risks? Here’s some advice.
Immediately following the public disclosure of these vulnerabilities in SaltStack, adversaries started targeting vulnerable SaltStack servers to conduct various malicious activities. But what’s most interesting to me is that attackers are targeting valuable SSH keys, which would allow attackers to persist on the machine and laterally move to other targets.
Because SaltStack software is used to automate the management and configuration of any infrastructure or application at scale, compromised SSH keys have the potential for widespread impact by remote, unauthenticated attackers.
According to F-Secure researchers, the SaltStack vulnerabilities would 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.”
A SaltStack engineer reported that two software vulnerabilities were already being exploited by the following:
- nspps RAT/Backdoor (just recently discovered)
- h2miner (cryptominer)
- XMrig (cryptominer)
An array of sites, applications, and servers have been affected by the attack, including DigiCert, Cisco, LineageOS (Andorid-based mobile os used on smart devices), Node.js blogging platform Gh0st (includes big-name customers such as Mozilla, NASA, and DuckDuckGo among its 750,000 registered users).
In the case of DigiCert, the attackers, who were able to gain access to a Certificate Transparency (CT) server's signing key, didn’t not abuse the opportunity to sign their malware and executed only crypto-mining activities.
The SaltStack attack is a great reminder of how critical and dangerous commodity malware can be and how attackers who manage to stealthily compromise machine identities, such as SSH keys or signing keys, can then monetize these by selling them to more sophisticated adversaries like nation-states Advanced Persistent Threats (APT) for further exploitation (cyberespionage and cyberwarfare).
The attackers' motivations vary from crypto mining, to remote access and information stealing. Similarly to other attacks reported recently, the use of passwordless SSH keys and unmanaged known hosts files allow the malware to act in a manner similar to worms.
All three types of malware steal SSH keys and known hosts information to remain persistent on the infected machine and move laterally to further targets.
In addition to SSH keys, the malware is able to exfiltrate the following:
- Entire home folders for all users
- Environment variables
- Mining wallets
- Bash history files and profile scripts
- Remote desktop config files and cookies
- All salt keys and execution histories
- Redis databases
- Shadow files
- And more
Venafi Threat Intelligence Researcher, Yana Blachman, warned, “Organizations and their security teams are not aware of where their SSH keys are located, how they are used, and to what and whom they provide access across the network. In most organizations, there is no governance on SSH identity creation and no incident response playbook or remediation process.”
Fortunately, SaltStack is actively addressing these vulnerabilities. As reported in Help Net Security, “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.”
What should organizations do to protect their SSH machine identities against exploits such as this? First, they should discover all SSH machine identities in their environment, who they belong to and what they are used for. Then they should map all trust relationships and identify and remove any orphaned and duplicate authorized SSH keys. They should also ensure passphrase protection, key length and algorithms. Furthermore, they should assign ownership of all access granting keys, and monitor and analyze key-based access usage
In addition, organizations should take the following steps to reduce the risk of future exploits:
- Control SSH identities and authorized keys
- Control SSH configuration files and known hosts files to prevent any tampering
- Implement clearly defined SSH key management policies
- Define SSH hardening configurations
- Create inventory and remediation policy
- Establish continuous monitoring and audit process
- Automate the whole process
Do you know who’s using your SSH keys?