In the never-ending fight against cybercrime, is your agency focused on strategy or on tactics?
The federal government is under mandate to keep its own and its citizens’ data secure — that’s a given. What tends to happen, though, is that IT security teams are so focused on defeating the latest malware variant that they pay no heed to a foundational network issue that could be much more serious.
Why SSH Keys are Important
When attackers break into 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 large computing environments.
These keys enable attackers to get into your critical network infrastructure and data. Stealing SSH credentials is the way attackers turn a relatively small breach into one that is not merely embarrassing for the government (see the CIA Vault 7 breach, below) but could put government secrets, national security and/or private citizens’ data in jeopardy.
So then, it doesn’t make sense to limit cybersecurity activities to overcoming the latest type of malware, ransomware or phishing attack. That’s a focus on tactics with no overarching strategy. According to Sun Tzu in The Art of War, this is the noise before defeat:
Recent Examples of Attacks Linked to SSH Keys
Currently, WannaCry holds the record for the world’s largest cyberattack. 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 employees’ 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.
This attack vector was not invented by WannaCry. There are other examples of hackers stealing employee credentials, such as the devastating Sony Pictures attack where credentials were stolen to spread the initial attack.
And just recently, WikiLeaks 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.
Why Hackers Steal SSH Keys
As the perpetrator(s) of WannaCry handily demonstrated, attackers don’t have to be sophisticated or well funded to breach and steal credentials. 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.
The theft and collection of SSH keys has been going on for years because they:
- Usually grant root or administrator access, thus allowing installation of malware, compromising of software or even outright destruction.
- Offer a long-term backdoor and can be used to spread the attack from one server to another, across nearly all servers, including disaster recovery data centers and backup data centers.
- Typically provide access to credit card payment environments and financial data environments.
What’s at Stake
The ratio of servers or user accounts to SSH keys portends how well a network is managed.
Most large network environments have far more of the latter than they have of the former. 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 login 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.
Gaining Understanding
Government IT teams should create a strategy in which the first order of business 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.
SSH key management starts with understanding who has access to your most critical infrastructure. 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?”
Another important point to understand is 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.
For compliance as well as security purposes, it is critical to ensure the clear separation of duties 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.
Strategy with Tactics
SSH keys are, for all intents and purposes — including nefarious ones — the keys to your kingdom. Once a malicious actor has even one set of keys, he or she can access one area of the network and expand across your entire environment. This is a root-cause issue that must be addressed if government networks are to be truly secure. Yes, accomplish the tactics of defeating the latest ransomware or phishing scam, but do it within the larger cybersecurity strategy that includes robust SSH key management.
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.
