Lax SSH Key Management Endangers Enterprise Networks
Secure Shell protocol inventor warns that uncontrolled SSH credentials could cause major security incidents, gives best practices for mitigating the risks.
Eighteen years ago, Tatu Ylönen invented the original Secure Shell (SSH) protocol in response to a password-sniffing attack at the Helsinki University of Technology. Since then, the technology has become ubiquitous. But Ylönen, founder and CEO of SSH Communications Security, now warns that poor SSH key management is a "ticking time bomb" within the enterprise. What's worse, it's a ticking time bomb that regulators like the PCI Security Standards Council haven't quite committed to defusing.
SSH and the automated network
The risks, Ylönen stressed, arise not from flaws in the SSH protocols, but from what he called "negligence in how people manage access for automation."
SSH is a network-level encryption protocol that resides largely beneath the end user's line of sight, in the administrator domain. The protocol has a variety of applications, such as file transfer, backup, system administration, and network administration. Among those applications, SSH's widespread use in router, virtualization, and cloud services management—in particular the provisioning of new virtual machines within cloud infrastructures—makes it increasingly important to the modern enterprise. Machine-to-machine connections now dominate network environments. Those machine-to-machine connections require vast amounts of automation. And therein, Ylönen told me, lies the rub.
"If you automate something in a data center, you have one computer basically logging into another and then doing something to it. This login requires some kind of authorization, usually using SSH. In most organizations, the way those authorizations are configured hasn't been managed at all. Those credentials are a ticking time bomb," Ylönen said.
The risks of unmanaged SSH keys
The dangers posed by poorly managed automated access credentials originate in large part from their vast numbers. Automated SSH access keys, Ylönen told me, typically far outnumber those assigned to individuals within any given organization.
To demonstrate this, Ylönen described a real-world scenario faced by an SSH customer. This customer, a major financial institution, has about 100,000 employees, but over 1 million SSH keys granting access to the institution's production servers. "We're talking about 10 times more key-based access credentials than they have passwords in the organization, and when we counted logins in their environment, including system-level logins into the production servers, we found that 80 to 90 percent of those were automatic," he said.
"You cannot ignore 90 percent of your credentials or 80 percent of your logins and pretend that they don't happen" just because they are automated, he said. Especially not when the keys in question unlock an enterprise's most mission-critical infrastructure.
"Time after time, we're seeing situations where logging in with automated SSH credentials from test systems or development systems allowed us into production, using keys with no additional user authentication. You can break into a test system and get into the production environment from there," Ylönen said. In many cases, the credentials allow this by providing access to one system that possesses automated credentials to then grant access to others, which then open doors to yet more machines or group of machines, and so on, so that an intruder can penetrate everything within minutes.
"You could reconfigure the network, the routers, the virtualization platforms. You could compromise the servers that hold critical data. You could get into an Oracle database on the database level, read everything, modify anything, falsify anything, destroy anything," Ylönen said.
Next page: Vulnerabilities already discovered and best practices for mitigating the risks.