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

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.

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: 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.