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>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 15 Jul 2010 01:04:15 -0700
From: Jordan Sissel <jls@...icomplete.com>
To: Ian Maguire <imaguire@...erb.net>
Cc: bugtraq@...urityfocus.com
Subject: Re: pam_captcha username harvest vulnerability

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.

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?

-Jordan

Powered by blists - more mailing lists