Bugtraq mailing list archives
Re: pam_captcha username harvest vulnerability
From: Ian Maguire <floatingdecimal () gmail com>
Date: Thu, 15 Jul 2010 08:06:36 -1000
On 7/14/2010 10:04 PM, Jordan Sissel wrote:
On Tue, Jul 6, 2010 at 11:04 AM, Ian Maguire<imaguire () superb net> wrote:pam_captcha is visual text-based CAPTCHA challenge module for PAM that uses figlet to generate the CAPTCHAs. Project site: http://www.semicomplete.com/projects/pam_captcha/ A site with a screen shot: http://www.michaelboman.org/how-to/securing-ssh-access-with-pam-captcha I found a security problem with the pam_captcha. If you enter a username that is not a valid user followed by the correct CAPTCHA, you do not get prompted for a password. You simply get prompted for another CAPTCHA. However, if you enter a username that is a valid user followed by the correct CAPTCHA, you will get prompted for a password. This means an attacker, or a script/bot could easily harvest a list of valid usernames simply by whether or not it prompts for a password after a valid captcha entry. I have duplicated this behavior in FreeBSD 8.0 which uses BSD's OpenPAM. From what I have seen this module is not compatible with Linux-PAM. I don't know enough C Fu to propose a patch. Until it is patched the solution is to disable pam_captcha in your pam config file. The creator of this module seems to think that using this module isn't really even necessary. http://www.semicomplete.com/blog/geekery/pam_captcha_research.html - ianI can't reproduce the behavior you describe on FreeBSD 8.0 nor on Ubuntu 9.10. It seems more likely that what you experience is actually misconfigured sshd/pam. With pam_captcha 1.3 on a fresh FreeBSD 8.0-RELEASE and this /etc/pam.d/sshd config: auth sufficient pam_opie.so no_warn no_fake_prompts auth requisite pam_opieaccess.so no_warn allow_local auth requisite pam_captcha.so randomstring #auth sufficient pam_krb5.so no_warn try_first_pass #auth sufficient pam_ssh.so no_warn try_first_pass auth required pam_unix.so no_warn try_first_pass My sshd_config has this: ChallengeResponseAuthentication yes PasswordAuthentication no UsePAM yes What I see: Successful pass of the captcha with an invalid username results in being given another captcha or an abort (if this is multiple failures) and PAM logs the fact that there was a failure due to invalid user.
This behavior you are describing is exactly the problem. When you enter a valid username, followed by a successful captcha entry, it prompts you for a password. However, if you enter an invalid username, followed by a successful captcha entry, it prompts you for another captcha instead of a password. Since the behavior is different when it is an invalid username, it is trivial to harvest a list of valid usernames. For example, if you are using pam_captcha, an attacker can immediately know if you allow root ssh logins simply by attempting to ssh in as root, and noticing whether, or not there is a prompt for a password after a valid captcha entry. They can do this with any username. Make a script to automate it, and they can harvest a list of valid usernames.
For example, if you don't disable "PasswordAuthentication" then pam failures could (captcha or other failures) will give up after a few tries and move on to Password auth (no captcha) auth instead. Are you sure this isn't something misconfigured on your side? Can you publish your sshd_config and pam configs?
This was on a fresh install of FreeBSD 8.0 with no modifications to the sshd config, so I won't bother sharing that one. The only the change I made to the pam config was adding the pam captcha line at the beginning. I'll paste the /etc/pam.d/sshd config below: # # $FreeBSD: src/etc/pam.d/sshd,v 1.16.10.1.2.1 2009/10/25 01:10:29 kensmith Exp $ # # PAM configuration for the "sshd" service # # auth auth requisite pam_captcha.so randomstring auth sufficient pam_opie.so no_warn no_fake_prompts auth requisite pam_opieaccess.so no_warn allow_local #auth sufficient pam_krb5.so no_warn try_first_pass #auth sufficient pam_ssh.so no_warn try_first_pass auth required pam_unix.so no_warn try_first_pass # account account required pam_nologin.so #account required pam_krb5.so account required pam_login_access.so account required pam_unix.so # session #session optional pam_ssh.so session required pam_permit.so # password #password sufficient pam_krb5.so no_warn try_first_pass password required pam_unix.so no_warn try_first_pass
-Jordan
Current thread:
- pam_captcha username harvest vulnerability Ian Maguire (Jul 06)
- Re: pam_captcha username harvest vulnerability Jordan Sissel (Jul 15)
- <Possible follow-ups>
- Re: pam_captcha username harvest vulnerability Ian Maguire (Jul 15)