Sergey Nivens - Fotolia

How can enterprises stop the OpenSSH vulnerability?

An OpenSSH vulnerability allows hackers to easily access passwords with a brute force attack. Expert Michael Cobb explains how to mitigate this flaw.

I read about an OpenSSH vulnerability that lets hackers easily bypass authentication restrictions and launch brute force attacks to crack passwords. How can you mitigate this flaw? Should I be concerned about using open source encryption software like OpenSSH?

OpenSSH is a free suite of security-related network-level utilities based on the SSH protocol. Used on most Linux-based systems, as well as many network infrastructure devices, it provides encryption for network services like remote login and remote file transfer with multiple authentication methods. By default, an SSH server allows a user six attempts to login before it closes the connection, and an SSH client allows only three password entries. However, a recently discovered authentication vulnerability by researcher KingCope allows attackers to perform as many authentication requests as possible during the Login Grace Time -- the default setting is two minutes -- on some OpenSSH servers where keyboard-interactive authentication is enabled. The proof-of-concept exploit code is just a simple command:

ssh -lusername -oKbdInteractiveDevices=`perl -e 'print "pam," x 10000'` targethost

While trying to brute force a strong password within two minutes is unlikely to prove successful, brute-force password attacks against SSH-enabled machines are still a common occurrence, which suggests that hackers still find enough servers using easy-to-guess passwords to make it worthwhile, particularly as keyboard-interactive authentication is enabled by default on OSes such as FreeBSD. Hackers cycling through the most commonly used passwords have much better odds of finding the right one as this authentication vulnerability allows them many password guesses.

Red Hat, OpenBSD and CentOS systems don't seem to be affected by this authentication vulnerability, but FreeBSD and Mac OS are as they don't insert a delay between authentication failures. While not a serious vulnerability, until there is an official patch and best practice to follow, administrators should take the following steps to make the exploit impractical:

  • Disable password authentication;
  • Use a cryptographic key for authentication -- only computers with the private key can access the Internet-facing server;
  • Use keys at least 2,048-bits in length;
  • Use a strong password to protect the private key;
  • Reduce the grace period to 20 or 30 seconds;
  • Limit the number of login attempts; and
  • Do not disable delay between login failures.

A tool such as Fail2ban can also be used to protect against this OpenSSH vulnerability and to reduce the rate of incorrect authentications and update firewall rules to reject suspect IP addresses for a specified amount of time.

Ask the Expert:
Want to ask Michael Cobb a question about application security? Submit your questions now via email. (All questions are anonymous.)

Next Steps

Learn how to get control over your organizations privileged identity management

Find out how enterprises should react to compromised biometric information

Check out the best ways to secure cloud authentication

This was last published in December 2015

Dig Deeper on Penetration testing, ethical hacking and vulnerability assessments