Closed DPStokesNZ closed 5 years ago
Working as intended.
1) It's a trade-off. With code and password both prompted the attacker doesn't know if they got the password right. If you only ask for code when password is right, you are enabling finding the password, and then brute-forcing the OTP over a long time.
2) If you still want code to only be asked when password is correct then use requisite
instead of required
in your pam config:
required
failure of such a PAM will ultimately lead to the PAM-API returning
failure but only after the remaining stacked modules (for this
service and type) have been invoked.
requisite
like required, however, in the case that such a module returns a
failure, control is directly returned to the application or to the
superior PAM stack. The return value is that associated with the
first required or requisite module to fail. Note, this flag can be
used to protect against the possibility of a user getting the
opportunity to enter a password over an unsafe medium. It is
conceivable that such behavior might inform an attacker of valid
accounts on a system. This possibility should be weighed against
the not insignificant concerns of exposing a sensitive password in
a hostile environment.
OK, thanks. Was just curious why it behaved differently on other OS.
That's strange. It shouldn't behave differently. If it does that sounds like there's something wrong with PAM or the PAM configuration on those hosts. I pasted from the manpage of pam.d
.
Some variation in PAM between the OSes then - unlikely that two different hosts prepared by two different people would have the same configuration issue. I'd prefer to see the Debian/Ubuntu behaviour personally.
GA on EL7 (CentOS Linux release 7.6.1810 (Core) prompts valid GA users with verification even if account password is entered incorrectly. Example:
The
Verification code:
prompt is only supplied for users with valid~/.google_authenticator
files, so there is the potential for brute force login attempts with random usernames to reveal valid usernames on the host.Steps to reproduce:
sudo yum -y update
sudo yum -y install epel-release
sudo yum -y install google-authenticator qrencode
/etc/ssh/sshd_config
to allowChallengeResponseAuthentication yes
/etc/pam.d/sshd
to use GA, i.e.:echo "echo 'auth required pam_google_authenticator.so' >> /etc/pam.d/sshd" | sudo -s
sudo systemctl restart sshd
google-authenticator -t -f -d -r 3 -R 30 -w 3 -Q utf8
Expected behaviour:
Possible relevant packages:
Additional information:
pam_google_authenticator.so
but the symptoms persisted.setenforce 0
orsetenforce 1
. Interestingly, for it to work for the compiled version, I had to generate a .te and .pp file andsemodule -i
the .pe - a step that wasn't required for the RPM installed version. Edit: I've looked at the install scripts for the RPM, there are none, so there is definitely no manipulation of SELinux happening with the EPEL-supplied RPM. There is a/home/[^/]+/\.google_authenticator~ unconfined_u:object_r:auth_home_t:s0
definition in/etc/selinux/targeted/active/file_contexts.homedirs
which appears to be being supplied by theselinux-policy-targeted
package. However,~/.google_authenticator
created by the compiled version has auser_home_dir_t
context by default. Restoring, i.e.:restorecon
, the context of that file does not alone solve the "problem", as later versions of GA also attempt to write a temporary file~/.google_authenticator~XXXXXX
which is prohibited by SELinux.Debug output from
/var/log/secure
:NB: the default permissions for
~/.google_authenticator
are 0400 upon creation, but having them as either 0400 or 0600 doesn't not change the behaviour.Finally, I was unable to reproduce the issue with a Ubuntu 18.04 LTS host I have nor could an acquaintance produce the issue on a Debian host, so it appears to be specific to EL7.
Happy to provide a minimal EL7 host for testing if required.
Regards, Duncan.