Heartbleed redux with Secure Shell?
Connecting state and local government leaders
Warning flags have been raised over SSH, which helps manage servers, routers and firewalls and is used to provide privileged access to servers and networks.
Is the Secure Shell (SSH) vulnerability going to be this year’s OpenSSL? As with the stock market, it’s a mug’s game to predict the future, but warning flags have been raised in response to reports of problems with major security devices.
It was problems with the OpenSSL version of the Secure Sockets Layer encryption that led to the discovery two years ago of the Heartbleed bug, which many security professionals called one of the scariest things they had seen. It allowed anyone who could get to an infected device to compromise the private keys used to identify service providers and encrypt data traffic.
Eventually, hundreds of thousands of servers around the world were found to be vulnerable to Heartbleed, and even now no one seems sure if all the holes have been plugged.
In December 2015, Juniper Networks said it had found “unauthorized code” in its ScreenOS, the operating system that runs on its widely used NetScreen firewalls. That code would allow a knowledgeable attacker to gain administrative access to NetScreen devices over SSH and Telnet, the company said, and to decrypt VPN connections.
The company has since made several fixes to its software to close down the gap, the latest to the Dual_EC random number generator used in the firewalls. That’s been a long time coming, since Dual_EC has reportedly contained a backdoor inspired by the National Security Agency (that could also be exploited by bad guys).
Now researchers have found suspicious code in Fortinet’s FortiOS firewalls, saying it was also essentially an SSH backdoor. Fortinet, however, downplayed that allegation, saying it was a “management authentication issue” that had been fixed some time ago.
Coincidentally, the National Institute of Standards and Technology recently released a new guidance document on the security of SSH key-based access, which it said is often overlooked by organizations. That would be a bad thing, as NIST also points out, because misuse of SSH keys “could lead to unauthorized access, often with high privileges.” In other words, it’s potentially handing the keys to the kingdom over to people who will gratefully accept the gift -- and then take you for all you are worth.
Backdoor keys are specifically mentioned by NIST as one of the seven categories of vulnerability in SSH, which is widely used to manage servers, routers and other security devices as well as firewalls. It’s also used to provide privileged access to servers and networks.
However, NIST pointed out, SSH public key authentication can also be used to create a backdoor by generating a new key pair and adding a new authorized key to an authorized keys file. That allows someone to get around the access management system and its monitoring and auditing capabilities.
Other vulnerabilities NIST cited include: poor SSH implementation; improperly configured access controls; stolen, leaked, derived and unterminated keys; unintended usage of keys; theft of keys as attackers inside the system move from server to server and steal credentials along the way; and the always present human error.
The recent firewall revelations are by no means the only reported problems with Secure Shell. In the middle of last year, researchers also discovered vulnerabilities with the OpenSSH version of the protocol, which allowed attackers to get around authentication attempt limits and launch brute force attacks on targeted servers.
The big problem with these kinds of vulnerabilities is not necessarily that they exist. If they are quickly noticed and patched, any likely damage is minimized. But the OpenSSL bug went unnoticed for several years, so the door to networks and systems that used that protocol was open all that time. The OpenSSH bug could have been present on versions of the FreeBSD operating system as far back as 2007.
Heartbleed redux? Not so far, it seems, but the year is yet young.
NEXT STORY: Using teamwork to fight DDoS attacks