4

SSH passwords should not have been enabled for login over the Internet. Although the Infrastructure Team had attempted to configure the sshd daemon to disable password-based logins, having UsePAM yes set meant that password-based logins were still possible.

From: https://blogs.apache.org/infra/entry/apache_org_04_09_2010

I take this to mean that they set this in /etc/ssh/sshd_config:

  • PasswordAuthentication no
  • UsePAM yes (the default)

I found a relevant question where the answer cites the following from the sshd config file:

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
  • So an attacker can bypass PasswordAuthentication no and PermitRootLogin without-password using ChallengeResponseAuthentication if UsePAM is enabled?
  • Is that what probably happened here, or am I misunderstanding what the Apache blog describes?
  • What is the point of disabling PasswordAuthentication or setting PermitRootLogin to without-password then? I mean, in what scenario does it make sense to use these if it can be bypassed?
  • Can one test if ChallengeResponseAuthentication is set on a server without valid credentials? Can external attackers tell that a server is a juicy target if they don't have credentials to try with?
Luc
  • 31,973
  • 8
  • 71
  • 135

1 Answers1

2

My best guess is that they made a mistake/typo, with this in mind I won't touch on your specific questions.

To help my case here is a comment I ripped out from the article you linked

"You should learn more about OpenSSH sshd configuration and do not put wrong statements like "having UsePAM yes set meant that password-based logins were still possible". There is nothing wrong with UsePAM yes, but you probably did not set both PasswordAuthentication and ChallengeResponseAuthentication to no."

notsoslimshady
  • 21
  • 3
  • Thanks! It has been a few weeks so I can't say for sure, but I guess I must have missed that quote. Do you happen to know if one can test whether password login is still possible via some way? It would help to know what command/tool was used to be able to bypass `PasswordAuthentication no` so that I can check my own systems for it. – Luc Mar 22 '19 at 09:02
  • I did some testing on my server, currently the only accepted auth is public key, if I try to connecting without the corresponding private key on my client I get a Permission denied with no chance of input. I enabled challenge response and was able to log in with the pam users password, same result with only enabling password auth. It appears by default challenge response will accept a password, but its purpose is to be configurable ( see access.redhat.com/solutions/336773 ). If both are set to no, or the challenge is configured to not ask for a password it shouldn't be possible to login via pw – notsoslimshady Mar 22 '19 at 11:13
  • To further expand on the previous comment, without being prompted for input the only way I could imagine to exploit it, is if there existed some handcrafted packets that could trick the ssh daemon into prompting for a password. But I have never heard anything like this nor believe such a packet(s) is likely to exist – notsoslimshady Mar 22 '19 at 11:37
  • Replying to your most recent comment, I'm sure that if the server allows for it, someone will write a client that can do handcrafted packets. That's what I'm really looking for: what does the server allow? Heck, even PHP appears to have written its own client: http://php.net/ssh2 Who knows what that allows one to do? It's also not difficult to take the standard openssh client, modify the source, and make it do funny stuff that way. – Luc Mar 22 '19 at 12:50
  • Modified/not published source is anyone's guess to what vulnerabilities may have been introduced. Take a look at openssh.com/security.html for a list of known/patched vulnerabilities. If a handcrafted packet auth bypass was a problem it has not been revealed, in addition if it was known by an attacker they would likely use it sparsely on high value targets to avoid revealing the exploit. It looks like there had not been an auth bypass issue since 2000. If your running your own SSH server and have security concerns, consider threat mitigations such as port knocking, it hides the ssh service – notsoslimshady Mar 22 '19 at 13:53