Bug Exposes OpenSSH Servers To Brute-Force Password Guessing Attacks

itwbennett writes: OpenSSH servers with keyboard-interactive authentication enabled, which is the default setting on many systems, including FreeBSD ones, can be tricked to allow many authentication retries over a single connection, according to a security researcher who uses the online alias Kingcope, who disclosed the issue on his blog last week. According to a discussion on Reddit, setting PasswordAuthentication to 'no' in the OpenSSH configuration and using public-key authentication does not prevent this attack, because keyboard-interactive authentication is a different subsystem that also relies on passwords.

Comments

actually had this on my list today

[epine]

The unofficial official FreeBSD security posture: two layers, where the outer layer has a singular purpose in life.

Protecting sshd using spiped

Like many system administrators, I used to restrict access to port tcp/22 on most of my servers based on source IP address; this provided some protection from "zero-day" exploits against OpenSSH, as well as eliminating the annoying "log spam" caused by brute force attacks. This worked fine as long as I always connected from the same location, but heading off to conferences meant that I needed to either tunnel SSH connections over other SSH connections or make temporary changes to my firewall rules.

Re:actually had this on my list today

[Duckman5]

The unofficial official FreeBSD security posture: two layers, where the outer layer has a singular purpose in life.

Protecting sshd using spiped

Like many system administrators, I used to restrict access to port tcp/22 on most of my servers based on source IP address; this provided some protection from "zero-day" exploits against OpenSSH, as well as eliminating the annoying "log spam" caused by brute force attacks. This worked fine as long as I always connected from the same location, but heading off to conferences meant that I needed to either tunnel SSH connections over other SSH connections or make temporary changes to my firewall rules.

Yeah. I used to have my SSH available on my public IP but finally got sick of getting emailed security loss that were a mile long with login attempts from Asian and Arabian countries I'd never been to. It was convenient being able to SCP files and everything without a hassle, but it wasn't worth the security risk.

Now, I just have our private access only and have to connect to my OpenVPN server first. Haven't gotten a single failed login attempt notification since. It's just really lame that it's come to this. You simply cannot have more than a bare minimum of ports open to the public or they WILL try to hack you.

Re: actually had this on my list today

[ancientt]

YES. Port knocking solved this years ago. For those unfamiliar with the concept, the idea is simple enough: my computer doesn't even let you try to log in unless you first hit a specific combination of ports first. For example, your IP address gets no response to an attempt to connect to SSH unless you first try to open ports 2234, 5039, 16, 38 and 27 in that order. (You don't get a response on those either, but my computer records those attempts and when you do hit them in that order, it opens up the real SSH port to your IP address for a connection attempt.) Add on an extra layer of security by having some ports that cause an automatic ban, so hitting port 2232 or port 2235 would mean your computer wouldn't get any access even if you otherwise hit all the required ports in the right order.

The best part is that you don't need any special software to set this up. Iptables is already built in and a bash script is sufficient to process the logs created by Iptables and unblock or ban when appropriate. The client just needs to get to a web page with links to the server and ports in the right order, so nothing more sophisticated than a browser is necessary. The worst part is that your firewall will block non-standard outbound traffic if it's sophisticated enough and if you're in a corporate environment, making changes to it may not even be an option.

I don't like alternate possible suggestions either. If you put up a web page to first authenticate people before opening SSH for connections, then the web server becomes the week point and I think SSH has a better track record of being secure than any web server I can think of. If you put up a VPN to authenticate people before allowing SSH attempts, then the VPN becomes the week point, and again, I don't know if VPNs are any more likely to be secure than SSH itself.

Any time you put two layers of authentication in front of allowing access, it should be more secure than having one alone, but with zero day exploits happening on pretty much everything, I'm inclined to think the first layer should be the one most likely to be immune. If that's SSH, and I think there is a reasonable argument SSH has a better track record than most any other authentication method, then using any other piece of software that people can connect to in front of it makes the potential for a breach higher.

I'm actually in favor of layered security and I use fail2ban (as others have suggested) and I put together a script to automatically ban "evil ips" when they repeatedly try unsuccessfully to connect to my machines, but really I feel that's more for my benefit of having less logs of automated attempts than being a serious deterrent to any half brained targeted hack attempt.

Re: actually had this on my list today

[theurge14]

So essentially an elaborate method of sending a clear text sequence of numbers (port numbers) to the server to allow access.

Re:LibreSSL

[invictusvoyd]

And embrace Microsoft products and their vulnerabilities of the year

Re:Dictionary?

[IgnitusBoyone]

Dictonary doesn't really mean English Dictonary, but a sorted list of common passwords and variations. Then just cycling through all of the entries. https://en.wikipedia.org/wiki/.... The dictonary may well be based of stats and possible characters not used in english grammer.

Re:LibreSSL

[TemporalBeing]

Time to leave OpenSSL and its vulnerability of the week behind.

This has nothing to do with OpenSSL other than that OpenSSH uses OpenSSL. This is a bug in OpenSSH itself.

Re:LibreSSL

[NotInHere]

H and L only differ on the 6th bit. You can't expect from everybody to have all bits right!

As many attempts withing 2 minutes

[140Mandak262Jamuna]

However, OpenSSH servers with keyboard-interactive authentication enabled, which is the default setting on many systems, including FreeBSD ones, can be tricked to allow many authentication retries over a single connection, according to the researcher. “With this vulnerability an attacker is able to request as many password prompts limited by the ‘login grace time’ setting, that is set to two minutes by default,” Kincope said.

It is bad, but not so bad. At least the connection resets after 2 minutes by default.

Fail2ban

[Gaygirlie]

As always, you should use Fail2ban or a similar tool anyways in addition to all the other security-measures. Fail2ban prevents you from taking advantage of this bug.

Few Hackers Smart Enough to Take Advantage of it

[damn_registrars]

I have a web server at home running openssh, open to the world (for reasons that are not critical here). I regularly have various idiots trying to hack in to it, which I find amusing.

The majority of attempts are done on root. It is not unusual to have thousands of attempts in 24 hours. They'll never get in that way; not because the root password is difficult (it is difficult enough that a few thousand guesses would not likely be sufficient) but rather because like any sane person I don't allow root to log in through ssh.

Occasionally I see "white pages" attempts, going through long lists of common names. They make usually no more than 3 attempts at each name (I presume one attempt is blank, haven't bothered to see what the others are). The problem with that strategy is that they pretty well never hit a valid name. Being as my ssh server won't respond any differently to a valid name than to an invalid one, they never get any useful feedback on that endeavor.

Now, important systems (say at large corporations) are probably targeted by more dedicated attempts than what gets directed at my server. I mostly see script kiddies from China who give up after 24-36 hours. These kids certainly won't benefit from this bug.

That said, I will still patch my server.

Re:Any professional tools available?

[Gaygirlie]

trying to move away a bit from the open source stuff just to avoid nasty surprises like this.

You don't know if there are more or fewer bugs in proprietary stuff since most bugs and vulnerabilities aren't made public and as such I do have to ask if this is really an informed decision on your part and not just bias -- you're seeing a lot more exposed bugs and vulnerabilities in F/OSS - stuff because they're more openly publicizing such details, thus you start to believe that there are more bugs and vulnerabilities in F/OSS - stuff to begin with.

Re:Any professional tools available?

[bigfinger76]

I'd recommend a decent admin. An admin who, having to leave password authentication enabled for whatever reason, fails to secure his machines with good passwords (which is what this bug exploits) isn't competent to administer such "mission critical" hardware.

Re:Few Hackers Smart Enough to Take Advantage of i

[just_another_sean]

I see this all the time too. PubKey authentication only, Fail2Ban and no root logins help to keep the log clutter to a minimum.

After finally weening myself off of using the root account locally I now just lock root completely. "sudo passwd -l root". Doesn't disable root so "sudo su -" still works but you can't login directly as root when the password is locked.

Although there is less traffic in the logs now I still get some entries before F2B kicks in and I find some of the non-root attempts very amusing... oracle, admin, ftp, PlcmSpIp, zhangyan

Some are obvious service user account attempts and some are just weird!

Re: Any professional tools available?

[bill_mcgonigle]

The ssh.com people are still selling theirs as I recall. Go ahead and ask them for indemnification against breaches, though - I'm sure they could use a good laugh on a Wednesday.

Re:Dictionary?

[tehlinux]

The first entry in my dictionary is now 'O0k9uehry&6$83'. Check and mate.

Linux not affected?

[wwalker]

It's appears to be a non-issue for CentOS 6/7 as ChallengeResponseAuthentication is set to "no" by default, which also sets KbdInteractiveAuthentication to "no" (the suggested work-around).

Re:Any professional tools available?

[badger.foo]

Some very simple tests based on cut and paste from http://arstechnica.com/securit... indicate that on a default install of OpenBSD with a randomly picked username, you'll get 3 tries only before the connection shuts down.

Re:Dictionary?

[steveg]

Denyhosts depends on login failures being logged to /var/log/auth (or similar) and it only checks those logs periodically (maybe once a minute?) The article indicates this bug allows a large number of attempts per *connection*. Does ssh even log the failure if the connection is not closed? I don't know the answer to that. In any case, it can make a lot of attempts in the interval between checks of the log.

Re:Account Lockout and Intrusion Detection

[steveg]

Locking accounts? Wow, that could never be used for a denial of service attack.

Re:Dictionary?

[TeknoHog]

My password is 'gullible', so it should be safe.

Re:LibreSSL (MOO!)

[Demonoid-Penguin]

A strong, unique password (aka a secret) is the only thing that matters

A secret matters. A secret password is not the only thing that matters. The modern default for sshd is already protected against the attack in the story - I put the relevant default setting in the post you didn't read when replying id_rsa.pub is stored on the remote system (as ~/.ssh/authorized_keys) - the only way an attacker can have access to that is if they already have access to the remote system. If they have access to the system the game is already over.

Certificates are nothing but long passwords that people can't remember and thus need to store in plaintext.

Certificates are nothing but long and complex, far more than any password could be, that people can't remember so they don't make the common mistake of using weak passwords bruteforced by the attack in the main story (which only works if you've fucked with default sshd) , and thus need to store in plaintext if you stupidly don't use a passphrase

TFTFY.

If an attacker can read the public key stored in ~/.ssh/authorized_keys on the remote machine it's game over because they have access. If they have access it's still game over if you used a password.

If the attacker has access to the local system and you use passphrases to protect your ssh keys - it's still likely game over, just as it is if you use passwords only (because they can install spying processes).

The longer and more complex the secret string is the harder it is bruteforce - regardless of whether it's a password you type or one that supply by and encryption process. To say that one you type is more secure is just silly.

Claiming that good security is based on using authentication you can remember just shows how poor your understanding of security is. That's the most common failing - not a strength. Maybe if you read and understood Bruce Shneier's articles and forums instead of regurgitating sections you clearly don't understand, you'd have more credibility (you have none on his forums either).
Why do you think Bruce recommends using encryption keys for authentication? (Hint: he's a cryptographer)
Why do you think Bruce recommends people use a password manager rather on relying on the weakest link in the chain of security (the meatbag at the end)? He wrote a password manager for that reason. If you can remember the password it will be broken.

The problem is you don't realize what a password actually is in relation to security. [...]

You've posted the same sort of babble on Bruce's forum before - it's been debunked many times, you've been called out as a dangerous fool there. And I'll call you the same here.