Re: [AntiSnatchOr] Drupal <= 6.20 insecure Captcha defaults PoC

[Michele Orru <antisnatchor () gmail com>]

2011/2/14 MustLive <mustlive () websecurity com ua>:
> Hello Michele!
>
> Few days ago I saw your advisory about Drupal's captcha. It's interesting
> advisory, but I have one note concerning it - your research is very close to
> mine ;-) (it concerns similar holes which I found before you).

I didn't found anything in FD or other public lists mentioning
this issue before, so.... :)
> First, you are talking Drupal captcha and saying that Drupal <= 6.20 are
> vulnerable. But it's not fully correct - Drupal Captcha module it's not core
> module, but third party one, so these holes have no relation to Drupal. It's
> how Drupal developers answered me in December, when I informed them about
> holes in their Captcha (I'm not using Drupal, so I didn't know is core this
> module or not). And so the hole in captcha concerns only Captcha module for
> Drupal (and sites on any version of Drupal with such module can be
> vulnerable) - so correctly to write about vulnerability not in Drupal, but
> exactly in Captcha module.
>
> Second, in your PoC (bruteforce exploit for Drupal) you're talking about
> Brute Force hole. But in title you said about insecure Captcha (which is
> Insufficient Anti-automation). These are different classes of
> vulnerabilities, like in WASC TC - Brute Force (WASC-11) and Insufficient
> Anti-automation (WASC-21). So your title is not fully correct.

I don't care too much about WASC classification, as you probably do.
wasc-21 can lead to wasc-11, so I don't want to bother on classifying
these things.

> > This means the following: if I will be able to correctly solve the first
> > Captcha challenge in the login form, but the login credentials are
> > invalid, there will be no new Captcha challenge to solve in the login form
> > presented after the HTTP response. In this situation is possible to
> > automate a dictionary/bruteforcing attack.
>
> This a little different from my hole - in my hole I'm bypassing captcha
> without any correct solving of challenges, i.e. complete bypass (and
> "persistence option" will not help against my attack). But your advisory is
> still close to mine ;-).
>
> Third, concerning the dates.
>
> At 2010-12-10 I announced different vulnerabilities in Drupal
> (http://websecurity.com.ua/4749/), found in summer. Including Insufficient
> Anti-automation vulnerabilities concerning captcha (as I'll write in my
> advisory, there are IAA holes as in captcha, as in Drupal itself).
> At 2010-12-11 I informed Drupal about these vulnerabilities in Drupal.
> At 2010-12-11 John Morahan from Drupal security team answered me. And in
> particular he stated, that Drupal Captcha is separate module.
> At 2010-12-12 I draw John's attention, that IAA holes existed not only in
> captcha module, but in Drupal itself (so it concerned Drupal too).
> At 2010-12-15 I announced new vulnerabilities in Drupal
> (http://websecurity.com.ua/4749/), found in summer. Including Brute Force
> (as concerning captcha module, as Drupal itself).
> At 2010-12-16 I informed Drupal about these vulnerabilities in Drupal.
>
> So as you can see I announced and informed developers more than month before
> you. Did they told you, that I informed them about similar attacks and very
> close holes in December? Looks like they didn't. Which is strange, it's
> unlikely that they forgot after just a month about it or that the whole
> Drupal security team had amnesia in January.
>
> All these holes in Drupal (from my 4 advisories concerning Drupal) will be
> disclosed soon. It was planned for February, so at this week I begun
> disclosing these holes.

They didn't told me anything: I've been in contact with Jakub Suchy and
Mori Sugimoto. They said that the issue I've reported qualified for public
disclosure.

Probably they didn't told me about you because they don't give a shit
about you, as all of us that write in FD do :)

Have a good day mr. MustLive
> So, Michele, good luck in your security researches.
>
> Best wishes & regards,
> MustLive
> Administrator of Websecurity web site
> http://websecurity.com.ua
>
> [Full-disclosure] [AntiSnatchOr] Drupal <= 6.20 insecure Captcha defaults
> PoC
> Michele Orru antisnatchor at gmail.com
> Thu Feb 10 12:15:01 GMT 2011
>
>
> > Drupal <= 6.20 insecure Captcha defaults PoC
> >
> >  Name: Drupal <= 6.20 insecure Captcha defaults PoC
> >  Systems Affected: Drupal <= 6.20 with Captcha <= 2.3
> >  Severity: Medium
> >  Vendor: http://drupal.org
> >  Advisory: http://antisnatchor.com/Drupal_insecure_Captcha_defaults_PoC
> >  Author: Michele "antisnatchor" Orru` (michele.orru AT antisnatchor DOT
> > com)
> >  Date: 20110210
> >
> > I. BACKGROUND
> > Drupal is a world-wide used open-source CMS written in PHP:
> > being really flexible and easy to extend, is the de-facto
> > choice for many small and big websites/portals that need a robust
> > framework on which model their business.
> >
> > II. DESCRIPTION
> > Many Drupal users use Captcha challenges (specially with reCaptcha) in
> > their
> > websites to protect sensitive resources from bots and spammers.
> > In fact, we've always red and seen Captcha (Drupal or not) implemented
> > to protect sensitive forms from online dictionary and bruteforcing
> > attacks.
> >
> > The default configuration of Persistence options for the Captcha module
> > in Drupal are insecure: the persistence option is set to "Omit
> > challenges in a
> > multi-step/preview workflow once the user successfully responds to a
> > challenge."
> >
> > This means the following: if I will be able to correctly solve the first
> > Captcha challenge in the login form,
> > but the login credentials are invalid, there will be no new Captcha
> > challenge to solve in the login
> > form presented after the HTTP response. In this situation is possible to
> > automate a dictionary/bruteforcing attack.
> >
> >
> > III. ANALYSIS
> > I've attached a two hours made Ruby PoC that automates a password guessing
> > attack to a known username. The code is commented enough, but basically
> > having
> > the cookie, the form anti-xsrf token and the captcha token/sid the
> > bruteforcing
> > can be automated. These values should be changed in the code, in a way
> > that
> > the first request is valid and contains the right captcha sid and
> > cookie: the next
> > captcha/form tokens will be parsed and added to the HTTP requests
> > automatically.
> >
> > An examle of the output:
> > /opt/local/bin/ruby -e
> > $stdout.sync=true;$stderr.sync=true;load($0=ARGV.shift)
> > /Users/antisnatchor/WORKS/BEEF/drupal-intruder/drupal_captcha_intruder.rb
> > +Initial xsrf token [form-43fb0bcbcb140066a782a3fc23ab1ab7]
> > +Initial captcha token [d853d6df05f6c6a956a46f20c8fe20aa]
> > +Dictionary attack with [4] passwords
> > +Testing password [test1]
> > +Request headers =
> >
> > {"Cookie"=>"SESS7fa63be60e31be67df6f271d7756698c=tgg548ajq53m4pb0ne18nsunm0;
> > has_js=1;", "Referer"=>"http://antisnatchor.com/user";,
> > "Content-Type"=>"application/x-www-form-urlencoded",
> > "User-Agent"=>"Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
> > rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13"}
> > +Code = 200
> > +Message = OK
> > +New xsrf token [form-f83fba9470bf8e3bfa035291b94fcc32]
> > +New captcha token [aa6e143f8c43c6b1ec87b59f6ab5bf6d]
> > +Testing password [test2]
> > +Request headers =
> >
> > {"Cookie"=>"SESS7fa63be60e31be67df6f271d7756698c=tgg548ajq53m4pb0ne18nsunm0;
> > has_js=1;", "Referer"=>"http://antisnatchor.com/user";,
> > "Content-Type"=>"application/x-www-form-urlencoded",
> > "User-Agent"=>"Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
> > rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13"}
> > +Code = 200
> > +Message = OK
> > +New xsrf token [form-6fba4b48adf6cec02539075edb4fb5f6]
> > +New captcha token [3e36c79be84a0cdf3a5eefbd0715ecdd]
> > +Testing password [test3]
> > +Request headers =
> >
> > {"Cookie"=>"SESS7fa63be60e31be67df6f271d7756698c=tgg548ajq53m4pb0ne18nsunm0;
> > has_js=1;", "Referer"=>"http://antisnatchor.com/user";,
> > "Content-Type"=>"application/x-www-form-urlencoded",
> > "User-Agent"=>"Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
> > rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13"}
> > +Code = 200
> > +Message = OK
> > +New xsrf token [form-a14e4668b0a8b7fa826bb04d1aa8590a]
> > +New captcha token [c9a90bbd487de5733b7231ff832c5dd6]
> > +Testing password [antisnatchor666!]
> > +Request headers =
> >
> > {"Cookie"=>"SESS7fa63be60e31be67df6f271d7756698c=tgg548ajq53m4pb0ne18nsunm0;
> > has_js=1;", "Referer"=>"http://antisnatchor.com/user";,
> > "Content-Type"=>"application/x-www-form-urlencoded",
> > "User-Agent"=>"Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
> > rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13"}
> > +Code = 302
> > +Message = Moved Temporarily
> > +Succesfully authenticated user[admin] with password [guessme]
> >
> > A little note: to try it you need a few ruby gems like nokogiri you'll
> > probably
> > don't have normally.
> >
> >
> > IV. DETECTION
> >
> > 6.20 and earlier versions are vulnerable.
> >
> > V. WORKAROUND
> >
> > Proper configuration of Drupal flood protection module should mitigate
> > this issue.
> > Also changing the Captcha persistence options to "Always add a
> > challenge" will
> > mitigate attacks.
> >
> > VI. VENDOR RESPONSE
> >
> > No fix available.
> >
> > VII. CVE INFORMATION
> >
> > No CVE at this time.
> >
> > VIII. DISCLOSURE TIMELINE
> >
> > 20110116 Initial vendor contact
> > 20110118 Initial Drupal security team response
> > 20110124 Mitigation discussion
> > 20110210 Public Disclosure
> >
> > IX. CREDIT
> >
> > Michele "antisnatchor" Orru'
> >
> > X. LEGAL NOTICES
> >
> > Copyright (c) 2011 Michele "antisnatchor" Orru'
> >
> > Permission is granted for the redistribution of this alert
> > electronically. It may not be edited in any way without mine express
> > written consent. If you wish to reprint the whole or any
> > part of this alert in any other medium other than electronically,
> > please email me for permission.
> >
> > Disclaimer: The information in the advisory is believed to be accurate
> > at the time of publishing based on currently available information. Use
> > of the information constitutes acceptance for use in an AS IS condition.
> > There are no warranties with regard to this information. Neither the
> > author nor the publisher accepts any liability for any direct, indirect,
> > or consequential loss or damage arising from use of, or reliance on,
> > this information.

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/