Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Bug Security

Bug Exposes OpenSSH Servers To Brute-Force Password Guessing Attacks 157

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.
This discussion has been archived. No new comments can be posted.

Bug Exposes OpenSSH Servers To Brute-Force Password Guessing Attacks

Comments Filter:
  • two minutes could allow for thousands of retries, which could be enough to guess common or weak passwords using dictionary-based attacks.

    I really donâ(TM)t think dictionary attacks are going to work for any serious servers . Just take this random password for example O0k9uehry&6$83

    • Re:Dictionary? (Score:5, Informative)

      by IgnitusBoyone ( 840214 ) on Wednesday July 22, 2015 @02:47PM (#50162571)

      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/... [wikipedia.org]. The dictonary may well be based of stats and possible characters not used in english grammer.

      • yes yes exactly . .. .. Ry&z89*oPl
        • by KGIII ( 973947 )

          You shift with your left hand and are right handed. Not really all that random. Decent CPUs can use deterministic algorithms to guess probable outcomes and create a dictionary based attack that would, eventually, find your password quicker than you might think. Not that I am an expert or anything but I have been cramming a bunch of articles on the subject into my head in an effort to pass time.

          • Not so random. Found a FreePbX phone system that requires ssh for phone traffic to pass to the VoIP provider. VoIP provider calls once a month saying a quarter of their total bandwidth comes from one number on the clients phone system and changes the private key used to authenticate. VoIP doesn't require ssh, so after figuring out all calls are being routed to a man in the middle, ssh gets disabled and phone quality improves, VoIP provider is happy. If the hackers only knew how to maintain good call quality

            • by KGIII ( 973947 )

              I have a friend who likes to opine that his connection to his ISP has been much more stable since the NSA started getting involved. I'd point out that it may be due to technical improvements but it is more amusing to hear him go off on his rant. He jokes about giving control of the whole infrastructure to them. At least, I hope he is joking.

    • by tehlinux ( 896034 ) on Wednesday July 22, 2015 @03:27PM (#50162931)

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

      • My password is 'gullible', so it should be safe.
        • by KGIII ( 973947 )

          You have no idea how many people I have told that there is no such word as gullible who have then gone on to look it up in a dictionary. It is sad and glorious all at the same time. I had a dictionary in my office and used it way too frequently for this joke. I used it a number of times while interviewing candidates. It was not a deal breaker but it was close. "No, really. It is not a word. Look it up..." It was far too easy to get the word gullible into a conversation. If you get bored and have a dictionar

      • You jest, but that's the exact purpose of many "How strong is your password?" websites.
        They get a nice dictionnary of real-life uncommon passwords.
        On a related note :
        https://xkcd.com/792/ [xkcd.com]

    • The classic dictionary attack is a way of figuring out what a password is from a hash. "You keep using that word ...."
      • by allo ( 1728082 )

        no.
        Dictionary or brute-force has nothing to do with the kind of attack (against a hash or against a live service)

        maybe you're mixing it up with rainbowtables.

        • Rainbow tables is a way to optimize a dictionary attack.
          • by allo ( 1728082 )

            no, they are a way to optimize a hashbreaking attack. A Dictionary attack against a webservice cannot be done with rainbowtables.

            • A coworker just tossed her copy of Merriam Websters at another coworker. While this was obviously a dictionary attack, it's not the classic dictionary attack where a hashed list of passwords and the associated user names is stolen and the passwords are reversed using a dictionary of common passwords, in the hope (or knowledge) that a user of interest will have credentials that will be revealed in this way.

              A repetitive attack against a service is so easy to prevent it's not even worth talking about.
              • by allo ( 1728082 )

                Dictionary Attacks are just a class of attacks, which use dictionaries instead of brute-force (a-z aa-z ba-z, ...).
                So they can be either online or offline.

    • My question is, how does this apply to DenyHosts [sourceforge.net]?

      My guess would be that I'm still safe... try root at all, instant ban. Try an invalid account, grace one time (even I make a typo sometimes). Try a valid account more than 3 times? Banned. Unless, of course, this attack somehow bypasses the mechanism DenyHosts uses to detect those invalid logins... but I don't know that I saw enough information in the article to answer that question.

      • by steveg ( 55825 )

        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.

      • by meadow ( 1495769 )
        My current count for blocked hosts is 19432: sudo egrep '(^ALL|^SSHD)' /etc/hosts.deny |cut -d" " -f2 |sort -n |wc -l
  • by epine ( 68316 ) on Wednesday July 22, 2015 @02:40PM (#50162515)

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

    Protecting sshd using spiped [daemonology.net]

    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.

    • by Anonymous Coward

      Try port knocking

      • by ancientt ( 569920 ) <ancientt@yahoo.com> on Wednesday July 22, 2015 @08:25PM (#50164899) Homepage Journal

        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.

        • by theurge14 ( 820596 ) on Wednesday July 22, 2015 @11:56PM (#50165659)

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

          • by Urkki ( 668283 )

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

            I wouldn't even call it elaborate. But it is different, so it is distinct extra security layer which offers unique protection. Cracking it basically requires that attacker can sniff low level traffic between client and server, and knows to watch for port knocking sequences. The important property of port knocking is, attacker without privileged knowledge doesn't know if server expects port knocking sequence, and attacker doesn't know if they failed critically and got that IP blocked. So it effectively block

        • I simply disable all SSH access to all hosts except one.

          I call that a jump box.

          I then disabled all authentication except public key (I already had ChallengeResponseAuthentication and KbdInteractiveAuthentication set to no).

          I enabled key, TCP and X11 forwarding.

          I just use the jump box to get to all my internal hosts using public key authentication with password authentication as a fall-back.

          In a pinch it can even act as a "poor man's VPN" by forwarding TCP to internal hosts.

          Mostly, I use it in conjunction wi

    • by Duckman5 ( 665208 ) on Wednesday July 22, 2015 @03:03PM (#50162723)

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

      Protecting sshd using spiped [daemonology.net]

      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.

      • by Anonymous Coward

        Non standard port in the emphemeral range, with no password authentication, key only. Saw 1 NMAP scan attempt on that port in a total of 6 months use, still check the logs daily.

        With key based authentication, is there any real risk to leaving a port unfiltered? Disregarding the paranoia that a rootkit will quickly leave you fucked.

        • by Anonymous Coward

          Unfiltered ports leads to better OS fingerprinting which leads to more specific attacks.

      • by Anonymous Coward

        So the only difference is that you sent yourself openssh failed login logs but not openvpn failed login logs?
        Your openvpn is still on public IP. What does this have to do with security?

  • On my edge router, I use TCPWRAPPERS to block access to a number of quasi-public services, like SSH. If the attacker isn't coming from the limited number of IP addresses allowed, the attempts get stopped and logged. Too many rejects, and they land in my edge ACL for all services, not just SSH. (Going on the theory that a bad apple hitting SSH probably has other bad habits.)
  • by 140Mandak262Jamuna ( 970587 ) on Wednesday July 22, 2015 @02:51PM (#50162597) Journal

    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.

  • by Gaygirlie ( 1657131 ) <(gaygirlie) (at) (hotmail.com)> on Wednesday July 22, 2015 @02:57PM (#50162665) Homepage

    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.

    • Any half-way competent system administrator who has an SSH server open to the internet should well and truly have some method of brute force attack prevention already. SSH attracts hordes of bots moreso than a Windows XP machine attracted the Blaster worm in it's heyday.

      It would have actually been interesting to propose a race. What would attempt to be breached first, a WIndows machine vulnerable to blaster, or an Linux machine with an SSH server that has login root and password password.

    • I like fail2ban. I started installing it on servers when I discovered a firewall getting so many SSH connections it couldn't hold anymore.

      The only reason I found that was happening is my Nagios instance threw up a flag upon no longer being able to SSH into the firewall.

      If you monitor for stability you will see security issues. If you code for security you will see stability. They tend to go hand in hand.

    • you sure about that?

      I mean, the point of the entire bug(more like a feature tbh) is that it gets around conventional checks for multiple failures(which is why you wouldn't be able to do this much of bruteforcing on normal connection because you would be banned).

      the original blog post is unclear about that.

    • by antdude ( 79039 )

      Old DenyHosts work too!

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

    • by tomxor ( 2379126 )

      What you describe are automated attacks, yes the majority are from China... they are only looking for low hanging fruit which is why the attempts don't look very clever, but they don't have to be. They don't care about your server, they care about getting as many servers as easily as possible, and you do that by automation and wide spread attacks.

      It's still good to stop these attempts from littering your logs and taking up resources so you can spot directed attacks by an actual person, not using default por

      • They don't care about your server, they care about getting as many servers as easily as possible, and you do that by automation and wide spread attacks.

        I should have been more verbose, I am fully aware that they don't care about my server specifically. Indeed they would almost certainly try a lot harder if they did.

        Don't be so cocky with your massive log of failed access attempts, everyone gets those

        I am aware that it is quite common. I was not intending to come across as "cocky", I'm not sure why you came to that conclusion.

        you should consider what happens when something with a brain tries to hack your server with a modicum of effort.

        If someone wants badly enough to get in, they will get in. Indeed as you said most of the Chinese attempts are just looking for highly vulnerable systems that they can easily get in to. I have my system open in t

    • Have you considered a rate limiting system like fail2ban which blocks servers for a set time after a set number of failed logins?

      Most of the time I see IP addresses come in, try root with a few password combinations and disappear back into the ether. But a few times I've seen bots attempt full dictionary attacks filling up my log files with useless SSH login errors. Fail2ban stopped that in its tracks and with a 15minute penalty for 3 login attempts I now see the number of logins reduced to the hundreds rat

    • Your data correlates with mine and I've been logging for years [I have 450,000 log entries at present and I have a non-published IP address, not tied to any DNS, so my traffic will be lower--just so I can login to my desktop from Starbuck's using my laptop]. More on this logger and my security config below.

      Apparently, the keyboard interactive problem has been known [by Redhat] since at least July 2013, see https://access.redhat.com/solu... [redhat.com] and it sets ChallengeResponseAuthentication to "no" to specifically

      • Your data correlates with mine and I've been logging for years [I have 450,000 log entries at present and I have a non-published IP address, not tied to any DNS, so my traffic will be lower--just so I can login to my desktop from Starbuck's using my laptop].

        I am comfortable stating that the script kiddies are most likely attacking my system by IP address alone, not by its domain name. I say this because I have yet to see a single one of their IP addresses show up in both my system and httpd logs. Of course, they may have seen the website and then attacked it by name from another system but that seems like more effort than it would be worth. I have also searched for their IP addresses before and found other blog entries from other people online - generally

        • Once again, we seem to be in complete agreement. I did the enhanced logging for amusement [That's why the logger never did a fail2ban equivalent]. Sometimes, I do "tail -f logfile" to watch the fun in realtime.

          For a while, I've been considering paring down and packaging up my scripting environment for this and publishing it on github. The sshd patch and setup/modification of the config files [including changing the selinux attributes :-(] is all done by a perl script (as is the logger).

          The only wrinkle i

          • Once again, we seem to be in complete agreement. I did the enhanced logging for amusement [That's why the logger never did a fail2ban equivalent]. Sometimes, I do "tail -f logfile" to watch the fun in realtime.

            It is nice to see someone not calling me crazy over doing such things. I wouldn't do this in a production environment, and suspect you likely wouldn't either. Sometimes free entertainment is a funny thing in what some people find entertaining, I guess :)

            I was considering adding automatic whois lookup, with abuse@blah.com scraping, and then send the applicable part of the logs automatically [with a copy to the FBI :-) :-) :-)]

            Have you had any luck getting responses from Chinese ISPs when you report abuse? I used to do it fairly regularly but for years now it seems like I might as well just send the report to /dev/null instead. While the lack of response doesn't mean they ar

            • I never did post anything back to an ISP. I assumed the result would be what you saw in practice. Also, if it were "state sponsored", they would ignore it. If it were somebody trying to find a portal that would circumvent the "Great Firewall of China" [which I'd be in favor of], posting back might just "out" them [to the government].

              I just got sshd patched/reinstalled. I just reverified that it disallows login/pw from public IP but allows login from local LAN on accounts that have no pubkey. So, I open

  • we hit the max title length, but the second part is "and so is the existence of bugs in any non-trivial piece of software".

    Re-using the existing connection is of course useful to fend off the traditional killing techniques for rapid-fire password guessers (such as http://home.nuug.no/~peter/pf/... [home.nuug.no] and similar), but you still have to come up with the set of bytes that will let you authenticate. Which leads to the other thing --

    The clowns I have been writing about ("The Hail Mary Cloud" -- http://bsdly.bl [blogspot.ca]

  • by Anonymous Coward

    Every computer exposed to the internet should have an account lockout policy in place. For example, pam_tally can limit speed between password attempts and also lock the account on X number of bad passwords. Furthermore, some sort of intrusion detection should be in place. Fail2Ban, for example, is an exceptional added layer of security which will ban the IP upon failed attempts.

    In short, "yawn" over this security bulletin. This is non-news.

    • by steveg ( 55825 )

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

    • by ledow ( 319597 )

      Locking genuine accounts because of automated spam against them? That's just not going to wash for any public service that contains common usernames, i.e. every school on the planet with a user John Smith.

      You can't just lock every user out because of a handful of random user checks. That's the point of passwords, if you don't have the password, you can't get in.

      Reject early, yes.
      Reject with limits, yes.
      Reject multiple attempts from the same IP, yes.

      But this is a BYPASS of such mechanisms. On one connecti

      • by KGIII ( 973947 )

        I was assuming, perhaps erroneously, that they meant to say that they blocked the IP address(es) of the attacking parties. That still, of course, has problems but they are lesser problems and fewer problems than locking the account itself out. I can not imagine that locking the account out would be a good idea really.

  • the project denyhosts could help with that, by blocking the IPs that have too many fails. ref: http://denyhosts.sourceforge.n... [sourceforge.net]
    • Fail2ban has worked well for me over the years. It's pretty easy to set up given it's sane, sensible defaults. Not comparing it to denyhosts, haven't use that. Just noting an alternative...

      www.fail2ban.org

  • Linux not affected? (Score:3, Informative)

    by wwalker ( 159341 ) on Wednesday July 22, 2015 @03:36PM (#50163015) Journal

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

  • Limited use of connections, tar-pitting, etc. are only for really bad passwords and provide only limited protection even there. Anybody that understands security already has passwords that are not guessable in practice.

  • The faster they can blow through their dictionary the better. If 24 of these Advanced Persistent Chinese crackers get born every day going after me, and they can blow through their dict. in an hour I'll have 24 of them to deal with a day. If I make them spend 2 years doing it, then I'll have to deal with over 9000 knocking on my door.

  • Because DragonFly defaults to public key only operation. No passworded access is allowed unless the user explicitly enables it, and we've recommended against enabling it for years now.

    -Matt

  • Port knocking is one way to avoid being a target of ssh attacks, but legacy port knocking has its own shortcomings. SPA (Single Packet Auth) has solved most of those problems. Fwknop is the only maintained spa implamentation that I know of. More info at https://www.cipherdyne.org/fwk... [cipherdyne.org]

  • undoing a bad mod.

"Oh my! An `inflammatory attitude' in alt.flame? Never heard of such a thing..." -- Allen Gwinn, allen@sulaco.Sigma.COM

Working...