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

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