Every time a new cybersecurity threat makes the headlines, health IT teams work quickly to safeguard their networks. Though this is a necessary aspect of cybersecurity work, it is not the only one. In the scramble to keep data safe, many healthcare organizations are overlooking a serious chink in their network armor.
Despite a cybersecurity team’s best efforts, it is inevitable that a determined attacker will get inside your network. The goal of the initial breach is to spread the attack, and the best way to do that is to steal credentials such as SSH keys. SSH keys are access credentials for the SSH protocol, similar to passwords, prevalent in most Fortune 500 enterprise computing environments.
Just like passwords, SSH keys allow entry into critical infrastructure and proprietary data. Stealing SSH credentials is the way attackers turn a relatively small breach into one of the large multimillion-dollar catastrophes in the news that can cause a healthcare organization’s stock—and reputation—to tank.
Concentrating person power and resources on the most recent type of attack is a focus on tactics with no overarching strategy. Sun Tzu in The Art of War succinctly and poetically describes the outcome of such activity:
Strategy without tactics is the slowest route to victory.
Tactics without strategy is the noise before defeat. – Sun Tzu
Conversely, cybercriminals have been demonstrating their strategy in a number of recent attacks. The perpetrators are after user credentials, like SSH keys, in an effort to spread the initial breach to critical system infrastructure. This allows an attacker to access machines that would have otherwise been immune to the malware, ransomware or phishing attack. There are many examples of this breach strategy being deployed in the news recently.
Stealing SSH Keys: Nothing New
One example was provided in July by WikiLeaks. The organization released documents said to come from the CIA Vault 7 breach. These documents contain user manuals for tools capable of stealing credentials and metadata from active SSH sessions. These tools can extract SSH keys and their passwords from memory while the SSH session is active. A common defense against SSH key misuse is to password-protect your keys, but an attack like this renders that technique useless. The threat of phishing tools, built by anyone or any government, that can steal credentials such as SSH keys is real. The protocol itself is still safe, but credential theft through human error, phishing or hacking is a growing issue.
Another example is provided by the largest cyberattack ever, the WannaCry ransomware attack. It impacted hundreds of thousands of computers in as many as 150 different countries and a range of business segments including healthcare, retail, government and finance. It is also now coming to light that the ransom demand was a distraction for a much more sinister and invasive attack to steal employee’s credentials. This explains why the attack seemed so sloppy in achieving its perceived goal of collecting ransom; so far only about $129,000 has been collected by WannaCry.
The devastating 2014 Sony Pictures attack, where credentials were again stolen to spread the initial attack, is yet another example of hackers stealing employee credentials. In other words, this is not a new strategy.
What Can Be Done with Stolen Keys
Stealing SSH keys is also not a strategy that requires significant financial backing or a high level of sophistication. The Iranian cyber espionage group known as the CopyKittens has shown far less sophistication when compared to other top hacking groups. They do not use the latest exploits and hacks such as 0-days, and their tools are considered inferior. Yet they have still managed to exfiltrate large volumes of data from government organizations, academic institutions and IT companies across the world. They have done this by using malware that steals credentials and then uses those credentials to steal more credentials to move across the compromised network.
Cybercriminals and their advanced malware have been stealing SSH keys for years because the keys:
- Frequently provide access to credit card payment environments and personal health data.
- Typically grant root or administrator access, thereby allowing installation of malware, compromise of software or even outright destruction.
- Create a long-term backdoor. In addition, they can be used to spread the attack from one server to another, across nearly all servers in a large organization, including disaster recovery data centers and backup data centers.
The Downward Spiral
Poor management of SSH keys can lead to serious issues. Most large organizations have far more SSH keys than they have servers or user accounts. For example, in one typical financial institution, 3 million SSH keys were found granting access to 15,000 servers. That is an average of 200 keys per server. Most organizations have SSH keys granting access that is no longer necessary, not compliant, or redundant. No wonder SSH keys are an attractive target for both insider and external attackers.
After one server is breached, it’s a safe bet that the attacker will find one or more private keys from that initial server. The attacker can then use these discovered private keys to log in to other servers—typically more than one—and again find private keys from these servers. Repeating this quickly spreads the breach and exposes more and more of the target network.
Creating an SSH Key Strategy
It’s clear that malicious actors have a strategy – and you should have one for defeating theirs. Your goal is to mitigate the damage a sustained attack can cause after the initial breach by protecting the credentials used to spread the attack across your network. This strategy protects your network against both external and insider threats. It makes no sense to prioritize security against ever-changing threats, such as the latest hacking exploit or malware, while leaving what the attackers are really after, credentials like SSH keys, unguarded.
Who has access to your most critical infrastructure? This is what you need to understand, first and foremost, to effectively address SSH key management issues in your environment. It’s important to get control of which SSH key-based access may have root access in your environment and, more importantly, how deep the transitive trust of this access extends. The question to be answered here is, “If I breach one root key, how deeply can I penetrate into the environment?”
A second important area of understanding is knowing which SSH key-based trusts are for interactive usage, and which are related to service accounts. Each key-based trust, regardless of its usage, should be assigned back to an individual owner in the environment to establish accountability.
It is essential to create a clear separation of duties in any instance where SSH user key-based trusts are in use. This means having a clear understanding of what key-based connections may be running across development to production environments, and re-establishing clear IP source and command restriction accountability of all key-based access within the production environment.
Mastering Key Management
SSH keys, those oft-forgotten workhorses of network infrastructure, are a critical commodity to cybercriminals. With them, attackers can establish a beachhead in a network and invade further from there. An attack like this can quickly compromise the entire network ecosystem. Today’s cybersecurity strategy must include SSH key management. Healthcare organizations can use the best practices above to protect their data at the deepest level.
About the author:
John Walsh serves as director of product marketing at SSH Communications Security, where he is focused on raising industry awareness of risk and compliance issues of unmanaged credentials. John has more than 15 years of experience in the IT security industry, having held product management, product marketing and software engineering positions at IBM and SSH Communications Security. Prior to joining the company, he worked at IBM, where he obtained a patent, contributed to solutions guides and designed a number of key software features for security products such as SSH, LDAP, Firewall and Java Cryptography. John holds a BS in Computer Science from Binghamton University as well as an MS in Management Information Systems from Marist College.