ThomasHabets
commented
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.
DPStokesNZ
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_authenticatorfiles, 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 updatesudo yum -y install epel-releasesudo yum -y install google-authenticator qrencode/etc/ssh/sshd_configto allowChallengeResponseAuthentication yes/etc/pam.d/sshdto use GA, i.e.:echo "echo 'auth required pam_google_authenticator.so' >> /etc/pam.d/sshd" | sudo -ssudo systemctl restart sshdgoogle-authenticator -t -f -d -r 3 -R 30 -w 3 -Q utf8Expected behaviour:
Possible relevant packages:
Additional information:
pam_google_authenticator.sobut the symptoms persisted.setenforce 0orsetenforce 1. Interestingly, for it to work for the compiled version, I had to generate a .te and .pp file andsemodule -ithe .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:s0definition in/etc/selinux/targeted/active/file_contexts.homedirswhich appears to be being supplied by theselinux-policy-targetedpackage. However,~/.google_authenticatorcreated by the compiled version has auser_home_dir_tcontext 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~XXXXXXwhich is prohibited by SELinux.Debug output from
/var/log/secure:NB: the default permissions for
~/.google_authenticatorare 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.