Project

General

Profile

Bug #4875

Security issue with OpenSSH "ChallengeResponseAuthentication yes" (implies KbdInteractiveAuthentication yes)

Added by Maurice Smulders about 4 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
07/23/2015
Due date:
% Done:

0%

Estimated time:
Affected Version:
All
Affected Architecture:

Description

http://www.infoworld.com/article/2951100/security/bug-exposes-openssh-servers-to-bruteforce-password-guessing-attacks.html?phint=newt%3Dinfoworld_sec_rpt&phint=idg_eid%3Db84f5f9e3385a848ce73284e054d7ff1#tk.IFWNLE_nlt_sec_2015-07-23

https://kingcope.wordpress.com/2015/07/16/openssh-keyboard-interactive-authentication-brute-force-vulnerability-maxauthtries-bypass/

This allows the max login count to be bypassed, and lots of simultaneous dictionary password attacks can be done against SSH. The setting on pfsense is
"ChallengeResponseAuthentication yes" in /etc/ssh/sshd_config which implies that the KbdInteractiveAuthentication is yes.

This makes openssh vulnerable, and as sshd_config is generated, just fixing the actual file is not sufficient...

sshd (7.09 KB) sshd Modified /etc/sshd Maurice Smulders, 07/23/2015 08:36 PM

Associated revisions

Revision 29f5f85e (diff)
Added by Chris Buechler about 4 years ago

Lower LoginGraceTime to 30s, should be plenty long for users, and mitigates the password login attempt bypass bug in OpenSSH. Ticket #4875

Revision f674922e (diff)
Added by Chris Buechler about 4 years ago

Lower LoginGraceTime to 30s, should be plenty long for users, and mitigates the password login attempt bypass bug in OpenSSH. Ticket #4875

History

#1 Updated by Maurice Smulders about 4 years ago

Current workarounds are:

1) Do not allow password authentication for ssh. The default setting for sshd in public key authentication is "ChallengeResponseAuthentication no" (System:Advanced, "Secure Shell")

2) edit /etc/sshd to always set these to no.

$sshconf .= "UseDNS no\n";
$sshconf .= "X11Forwarding no\n";
$sshconf .= "ChallengeResponseAuthentication no\n";
$sshconf .= "KbdInteractiveAuthentication no\n";
if (isset($config['system']['ssh']['sshdkeyonly'])) {
$sshconf .= "# Login via Key only\n";
$sshconf .= "PasswordAuthentication no\n";
$sshconf .= "PubkeyAuthentication yes\n";
} else {
$sshconf .= "# Login via Key and Password\n";
$sshconf .= "PasswordAuthentication yes\n";
$sshconf .= "PubkeyAuthentication yes\n";
}
$sshconf .= "# override default of no subsystems\n";

#2 Updated by Kill Bill about 4 years ago

Have you actually tested this? Because, mind you, you'll get banned from the firewall: https://doc.pfsense.org/index.php/Sshlockout

#3 Updated by Chris Buechler about 4 years ago

  • Status changed from New to Resolved
  • Priority changed from Very High to Normal
  • Target version set to 2.2.4

if/when it gets fixed upstream we'll patch it. You have the same option that everything else does - disable password auth under System>Advanced if you're concerned about it. That's enough, no need to change anything beyond that. It's not an endless number, it's up to the grace time's worth of attempts, at which point the session will end and sshlockout will have the offending IP locked out.

We talked about lowering the grace time early this week, and haven't seen any reason not to do so. That's been reduced to 30 seconds for 2.2.4 and newer.

This isn't as big of a deal as some are making it out to be. If your password's guessable in even hundreds of thousands of tries, you're doing it wrong. Not likely to get more than a few thousand out of this. And if you have SSH open to the Internet, you shouldn't be allowing password logins at all anyway.

resolved as best we can.

Also available in: Atom PDF