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


- ian


I 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: