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

[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: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: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:Dictionary?

[tehlinux]

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