OpenSSH password guessing attacks may be 10,000 times easier than you thought

An interesting problem with OpenSSH  – let’s call it a feature that turned out to be a vulnerability – has been publicised on the Full Disclosure mailing list.

To explain.

SSH stands for Secure Shell, one of the most widely-used and important remote access tools in the world.

SSH runs on almost all Linux/Unix systems on the internet, so that sysadmins can look after them from afar.

OpenSSH is by far the most widely-used implementation of SSH out there.

So any security news about OpenSSH is worth looking into, whether you run servers yourself, or use servers provided for you by other people.

And full disclosure is a school of thought that is heavily swayed by the well-known “anybody, everybody, somebody, nobody” conundrum:

A job came in that anybody could have done. So everybody assumed that somebody would do it. In the end, nobody did it.

According to adherents of full disclosure, the best way to ensure that security problems don’t get left for somebody but handled by nobody is to reveal all the gory details to anybody, including the crooks, thus putting pressure on everybody to do something.

→ We don’t agree. We accept that public disclosure may be appropriate if a vendor is unwilling to respond to a privately-disclosed security hole within a suitable time. But responsible disclosure – if both the bug finders and the bug fixers are reasonable – gives us all a fighting chance of fixing new problems before the crooks find out about them, leaving public disclosure as a last resort.

Back to OpenSSH.

The OpenSSH software allows numerous ways of logging in.

However, many, if not most, servers these days are configured so that they no longer accept what OpenSSH calls keyboard-interactive login.

That’s where you get a familiar password prompt and simply type in your password to authenticate.

For any server that accepts automated secure connections, typed-in passwords obviously aren’t good enough, because there often won’t be anyone around to type them in.

Instead, you authorise logins using public key cryptography.

You generate a public-private keypair, send the public key to the server operator to install in order to authorise you to login, and then use the private key at your end next time you want to connect.

Simply put, it works like this.

The server sends you a login challenge scrambled with your public key, which only your private key can unlock.

You decrypt the challenge, re-scramble it with your private key, and send it back.

If the public key held by the server correctly unlocks the encrypted login challenge that you just sent back, then the server knows that the person on the other end does, indeed, possess the right private key.

So you are authenticated without needing to use a traditional password.

→ If you are using a private key for interactive logins, you can, and should, protect the private key itself with a password, but you never need to share that password with the server. That way, you still need to enter a password, but only to unlock your own private key.

In other words, once you start using key-based authentication, you no longer need keyboard-interactive, so it’s a good idea to turn it off: you almost always improve security by removing unneeded features.

Nevertheless, some OpenSSH servers (and by this we mean the OpenSSH software that accepts connections, even when it’s installed on a desktop computer so IT can manage it) still permit keyboard-interactive, and that’s where this recently-disclosed issue shows up.

The problem is that when you run the OpenSSH client in order to login, you can give it a command line option that boils down to “pretend I have 12,976 keyboards and let me try logging in on all of them.”

By default, OpenSSH servers have a configuration setting that says LoginGraceTime 120, which translates into “give the guy at the other end 120 seconds to type in his password before you give up and close the connection for safety’s sake.”

So, if you combine the dodgy command line option with the default LoginGraceTime, you get two minutes to try 12,976 passwords (or as many as you think you can squeeze off across the network to the server in the allowed time – that number is flexible).

This bypasses the usual behaviour of the OpenSSH client and server components, which close your login connection out of a mixture of politeness and security concern after 3 or 6 wrong guesses respectively.

In other words, to cut a long story short, if you allow keyboard-interactive logins, an attacker can probably make 3000 to 10,000 times as many guesses at your password over each login connection than you thought possible.

What to do?

Any or all of these will help:

• If you aren’t allowing keyboard-interactive logins, this bug doesn’t apply to you.
• If you choose decent passwords (or use a password manager that generates complex passwords for you), you won’t be in the top 12.976 passwords an attacker is likely to guess, or even in the top 100 billion.
• If you reduce your LoginGraceTime to 15 seconds, you reduce the impact of the bug eightfold. (15″/120″ = 1/8.)
• If you monitor your server logs for bad password attempts, you will probably spot that this, or similar, brute force attacks fairly quickly. You may be able to blocklist the IP numbers of egregious offenders.

Oh, by the way, if you’re the sort of person who manages to lock your keys in the car from time to time, take heed of this warning.

It comes from our friend and colleague Stephen Edwards, who’s a security researcher at Sophos.

We shan’t say how he found this out:

Be careful of the order in which you do things if you're changing SSH settings while you're logged in remotely over SSH.

You don’t want to lock your keys in the router.

– HOW TO PICK A PROPER PASSWORD –

Can’t view the video on this page? Watch directly from YouTube. Can’t hear the audio? Click on the Captions icon for closed captions.