fwknop vs. Weak SSH Keys
28 August, 2008
As is well known, in the version of the OpenSSL library distributed by the Debian Linux
distribution through early 2008, there was a
change
made that had the unintended consequence
of reducing the ability of OpenSSL to gather the necessary entropy from the local system to
create cryptographically strong keys. Fortunately, this problem has since been fixed, but
it affected a large list of applications - including OpenSSH - that linked against the
hobbled version of the OpenSSL library. Even though the vulnerability has been patched and
upgrading a Debian system (or system derived from Debian such as Ubuntu) means that no new
weak keys will be generated, this is only half of the story; it is still critically important
to remove all weak keys from all systems. This applies even to non-Debian
systems to which weak keys were copied from a vulnerable Debian system. Further, any
password that was used over an SSH connection with weak keys (such as to log into a remote
system or a password used to unlock a GnuPG private key) should be treated as if it were
transmitted in the clear.
So, how does fwknop play into all of this?
Let's assume that a key is chosen for fwknop Single Packet Authorization (SPA) message encryption/decryption, and this key is only entered or viewed via console access (so it is never transmitted itself over a weak SSH connection). Let's also assume that SSH connections are made from a Debian system with a weak SSH key to another system, but only after authenticating with fwknop to the remote SSH server. In this case, even if an attacker can sniff all packets associated with both the SSH connection and the SPA packet, it is not a forgone conclusion that the attacker will be able to access the SSH server. If the user has to type in a password over SSH (i.e. a pre-shared key is not used), then the attacker can see it after decrypting the session, but the fwknop hurdle is still in the way. The attacker would not even be able to see that the SSH server is listening to connect to, and because the fwknop key has never been transmitted in the clear, this provides a decent defense. Building up multiple layers of security is sometimes important.
On another note, many people turn to mechanisms like fail2ban to help protect against brute force attempts to guess weak user passwords in systems that allow arbitrary IP addresses to connect to the local SSH daemon. But, in the face of something like the Debian OpenSSL vulnerability, there is no need for any attacker (who can sniff traffic) to guess passwords at all - even strong passwords are effectively transmitted in the clear. To defend against this, a stronger layer of protection is necessary such as Single Packet Authorization.
Finally, the first step in removing weak SSH keys is to find them, and this is the job of the dowkd.pl script.
