bugtraq - Re: pam_captcha username harvest vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <AANLkTinm-geFZPTam7MdJeuQmJCVPbs0aBgont84xl46@mail.gmail.com>
Date: Thu, 15 Jul 2010 08:06:36 -1000
From: Ian Maguire <floatingdecimal@...il.com>
To: bugtraq@...urityfocus.com
Subject: Re: pam_captcha username harvest vulnerability

On 7/14/2010 10:04 PM, Jordan Sissel wrote:
> On Tue, Jul 6, 2010 at 11:04 AM, Ian Maguire<imaguire@...erb.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
>
>