Thanks for clarification. One question though: As far as I have tested openssh, it logs every unsuccessful authentication attempt on the very moment it becomes unsuccessful, not after the connection is closed (after timeout or when reaching max auth attempts). Is this true or not even for this attack or not? Because if it is true, if there is a IDS system that bans IP after X failed logins, there should not be any problem. But if logging is deferred for any reason, then IDS can not detect the attack in timely manner. b. On 23 July 2015 at 01:03, mancha <mancha1 at zoho.com> wrote:> On Wed, Jul 22, 2015 at 07:41:54PM +0000, Scott Neugroschl wrote: >> I read an article today about keyboard interactive auth allowing >> bruteforcing. >> >> I'm afraid I have minimal understanding of what keyboard-interactive >> really does. What does it do, and should I have my clients set it to >> off in sshd_config? > > Hi. > > A bug in the keyboard-interactive codebase allows querying a > keyboard-interactive device more than once per auth request. > > By sending a comma-delimited keyboard-interactive device list with > repeats (e.g. "pam, pam, pam, ..."), one can circumvent an OpenSSH > server's MaxAuthTries restriction. > > That's the crux of the issue. > > Attached patch fixes. > > --mancha > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >
On Jul 22, 2015, at 4:54 PM, Bostjan Skufca <bostjan at a2o.si> wrote:> Thanks for clarification. > > One question though: > As far as I have tested openssh, it logs every unsuccessful > authentication attempt on the very moment it becomes unsuccessful, not > after the connection is closed (after timeout or when reaching max > auth attempts). Is this true or not even for this attack or not? > > Because if it is true, if there is a IDS system that bans IP after X > failed logins, there should not be any problem. But if logging is > deferred for any reason, then IDS can not detect the attack in timely > manner.I would expect the attempts to each be logged immediately in most cases, so it?s true that something scanning the logs should be able to add new IDS rules without waiting for the connection to close. I?m not all that familiar with the scripts that do that, though. It?s possible in some cases that established connections might not be subject to the new rules, even if they are added quickly. It?s quite common to have an ?early? rule in the list that allows established connections to speed up the processing, for instance. If that?s the case, additional password attempts on that already open connection could still be let through. In the example presented, this could allow 30,000 password attempts before the connection is closed unless some other timeout kicked in before that. As Damien said, though, anything in PAM itself which adds failure delays would still apply, though, as would any kind of account lockout on too many bad attempts. -- Ron Frederick ronf at timeheart.net
On 23 July 2015 at 04:33, Ron Frederick <ronf at timeheart.net> wrote:> On Jul 22, 2015, at 4:54 PM, Bostjan Skufca <bostjan at a2o.si> wrote: > > Thanks for clarification. > > > > One question though: > > As far as I have tested openssh, it logs every unsuccessful > > authentication attempt on the very moment it becomes unsuccessful, not > > after the connection is closed (after timeout or when reaching max > > auth attempts). Is this true or not even for this attack or not? > > > > Because if it is true, if there is a IDS system that bans IP after X > > failed logins, there should not be any problem. But if logging is > > deferred for any reason, then IDS can not detect the attack in timely > > manner. > > I would expect the attempts to each be logged immediately in most cases, > so it?s true that something scanning the logs should be able to add new IDS > rules without waiting for the connection to close. I?m not all that > familiar with the scripts that do that, though. It?s possible in some cases > that established connections might not be subject to the new rules, even if > they are added quickly. It?s quite common to have an ?early? rule in the > list that allows established connections to speed up the processing, for > instance. If that?s the case, additional password attempts on that already > open connection could still be let through. >I don't think adding new rules is necessary, if this behaviour produces average log messages about failed logins. In the example presented, this could allow 30,000 password attempts before> the connection is closed unless some other timeout kicked in before that. > As Damien said, though, anything in PAM itself which adds failure delays > would still apply, though, as would any kind of account lockout on too many > bad attempts. >Trying 30.000 passwords takes time, even over 1Gbps lan connection. It is true there is some time buffer and usually, if attacker is really fast, s/he might get more attempts before IDS kicks in, but usually we are talking about sub-second delays here. BTW does anyone know a decent ssh scanner that is fast, so I can test my OSSEC HIDS installation for what is described in paragraph above? Tnx. b.> -- > Ron Frederick > ronf at timeheart.net > > > >