We’re drawing on our security knowledge to provide a series on the fundamentals of securing devices and networks. The previous item in our series was an introduction to why asset management is important for securing networks. In this segment, we introduce SSH and remote servers.
SSH isn’t perfect though, and it depends on users to keep its servers secure.
SSH servers are found in everything from linux servers, to VOIP phones, to security cameras. Very often, SSH servers are installed to allow administrators to access a remote shell, from which they can update software and change system settings.
SSH servers are designed to be secure, but users play a role in maintaining that security. The most common problem arises when a user’s password is easily guessed or cracked. For example, using the password, “password” creates an opening for an intruder. The user’s traffic would still be encrypted, but a malicious actor could sign in as the user and change settings or view sensitive data. From this vantage point, the attacker could hop from machine to machine. For more information, read our post on lateral attacks .
The other problem that arises is when vulnerabilities are found in SSH servers. Going back to the browser analogy, let’s say this blog post is stored on a server somewhere in the world. While you didn’t have to input a password to get to this content, you would need special access to edit it. If the server containing this blog post were running an unpatched SSH server open to the public, an attacker could connect in and maliciously change the text. An edited blog post isn’t terrible, but imagine if that server were in a critical position and responsible for something like keeping time .
In October, libssh patched a vulnerability that allowed an attacker to successfully authenticate without providing credentials. This means that any SSH server that uses libssh needs to be updated, or attackers will continue to be able to log into that server. Keeping SSH servers updated isn’t trivial. Administrators are often dependant on manufacturers provide the patch, which takes time. After a patch is released, administrators need downtime on the machine in order to update it. Unfortunately, downtime is often impractical, and machines continue to run vulnerable servers.
If you’d like to use SSH, you’ll need an SSH client. On computers running OSX (Macs) and Linux, you already have one installed. You can open up a terminal window and type ‘ssh ‘ followed by ‘username@<server-ip-address>’ to log into an SSH server. If you’re running windows, you’ll likely need to install an application like PuTTY .
Try SSHing into your home networking devices and find out if they respond. Imagine how many computers, devices, and machines at work have SSH servers running. Then get out there and secure them.
Come back soon for the next item in our series and, in the meantime, check out our write up on
implants and supply chains.
