OpenSSH Potentially Vulnerable To Password Brute Force Attack

Update: 13th August 2015:
OpenSSH has released v7.0 which addresses the issue discussed in this post.

In late July a security issue with the most widely used SSH (Secure Shell, defined) implementation namely OpenSSH for Linux based systems was documented on the Full Disclosure mailing list. SSH uses port 22, TCP (see Aside (below) for a definition) or UDP (see Aside 1 of this post for a definition).

The issue involves the now less used method of keyboard-interactive login (where you type your password using a keyboard when prompted by the server). Many SSH sessions today are set up using automated secure connections (since they are automated no person is present to type the password). Instead public key cryptography (asymmetric encryption) allows you to verify your identity to the server as follows:

In order to do this, you initially create 2 keys a public and a private key. You send the public key to the server. When you wish to log into that server it will send a challenge (a cryptographic nonce) encrypted with the public key that you previously provided. You then use your private key to decrypt that nonce, re-encrypt it with your private key and send it back. The server then uses the public key to decrypt what you have sent. This verifies to the server that you do indeed possess the correct private key and are authorized to use the server. Guides on how to set up this feature are provided here and here.

Why Should This Issue With OpenSSH Be Considered Important?
On some OpenSSH installations especially FreeBSD systems have keyboard-interactive authentication enabled by default. When this is the case, you can specify via command line parameters to OpenSSH to allow for example 10000 individual keyboard devices to try to respond to the password being requested by the server you are attempting to access. This means that you will have 10000 attempts to guess the password of the server. This would allow you to execute a brute force attack to try to obtain the password.

If the password is quite weak, 10000 attempts will be more than enough to obtain/guess that password. The server does only allow you (by default) to have 2 minutes for the “login grace time” to allow you to enter your password, thus the attack would also be limited to this time, however 10000 guesses within 2 minutes is possible. When the password is obtained an attacker can then use your server with the same level of access that you have for any purpose they wish.

=======================
Aside:
What is TCP?
Transmission Control Protocol (TCP) is a connection oriented transport protocol within the larger TCP/IP ((Internet Protocol) suite which provides reliable data transmission (due to error checking and re-sending of packets corrupted or not received) and preserves the order of packets that are transmitted from a source device to a destination device. TCP/IP is a suite of protocols that provides worldwide connectivity between the devices that make up the Internet.

With TCP the connection between 2 devices must be set up and torn down. This in contrast to UDP that provides a connectionless data transmission service.
=======================

How Can I Protect Myself From This Issue?

• If you are using automated server logins rather than manual keyboard entry logins you are not affected by this issue.
• Consider reducing the LoginGraceTime. This article explains how to set it to a recommended value.
• Ensure that the password being used to access your server is strong. Advice on creating strong passwords is available in a previous blog post.
• Consider implementing the advice within this SSH hardening guide.
• Monitor the logs of your servers to check for multiple failed logins to detect such brute force attacks.
• Set ChallengeResponseAuthentication and KbdInteractiveAuthentication to “no”.

While OpenSSH 6.9 is currently available, the upcoming version 7.0 does not appear to include revised default settings to eliminate the issue discussed above. The above suggestions should keep you safe from this potential brute force attack.

Update: 13th August 2015:
OpenSSH has released v7.0 which addresses the above issue discussed in this post.

Thank you.