Hello all,
I was tasked to test a web form for vulnerabilities a few months back. to
cut a long story short:
The form was protected with a CAPTCHA that totally screwed up with my
scanning. So I thought I 'ld research a bit on the CAPTCHA integration
prior to the CAPTCHA implementation (OCR etc.) since the latter was a bit
far fetched for the engagement at hand. To cut a log story short I:
(1) found the codeproject CATCHA control that was used to perform test
(2) saw that the CAPTCHA generating page had a two fold purpose: (i)
generate the CAPTCHA image and (ii) store the CAPTCHA value in a session
variable
(3) saw that the source code sample was only resetting the CAPTCHA value
stored in the session ONLY upon a failed attempt.
At the end you had a session variable set at a CAPTCHA value that you knew
a priori. So provided that
(1) you never called the CAPTCHA generating page again and
(2) you excluded the variable passing the CAPTCHA value to the server from
the ones checked by the scanner
you could complete the scan and get viable results back.
Both prerequisites above are very easily met with Burp.
More info at
http://www.pigadas.com/blog/2012/02/10/correct-captcha-re-use-attacks/
Cheers,
./Z
BTW, I would like to hear your opinions about CAPTCHA's effectivness...
Till now, all my tested CAPTCHAs were successfully cracked by some automated
tools (captchakiller, decaptcher.com, www.deathbycaptcha.com, ..) including
Google ReCAPTCHA....OK, the best decaptchers are paid (but $1.39 for 1000
solved CAPTCHAs is not so much), so it seems that CAPTCHA is a usable
protection against poor hackers only, maybe stupid spambots...
Pavol
On Sat, Feb 11, 2012 at 08:59:35PM +0200, Zacharias wrote:
Hello all,
I was tasked to test a web form for vulnerabilities a few months back. to
cut a long story short:
The form was protected with a CAPTCHA that totally screwed up with my
scanning. So I thought I 'ld research a bit on the CAPTCHA integration
prior to the CAPTCHA implementation (OCR etc.) since the latter was a bit
far fetched for the engagement at hand. To cut a log story short I:
(1) found the codeproject CATCHA control that was used to perform test
(2) saw that the CAPTCHA generating page had a two fold purpose: (i)
generate the CAPTCHA image and (ii) store the CAPTCHA value in a session
variable
(3) saw that the source code sample was only resetting the CAPTCHA value
stored in the session ONLY upon a failed attempt.
At the end you had a session variable set at a CAPTCHA value that you knew
a priori. So provided that
(1) A you never called the CAPTCHA generating page again and
(2) you excluded the variable passing the CAPTCHA value to the server from
the ones checked by the scanner
you could complete the scan and get viable results back.
Both prerequisites above are very easily met with Burp.
More info at
http://www.pigadas.com/blog/2012/02/10/correct-captcha-re-use-attacks/A
Cheers,
./Z
--
---------------------------------------------------------------------
I*I*II*I 1/2
a 1/4*I 1/2 I*a?*I'a 3/4 1/2 a 1/4*I*I+-I*I-oIu I^3a?*A. I*a 1/2, I'a
1/2^2 IP:I.I*I?I*I 1/4IuI 1/2I?I 1/2
a 1/4*I>>I*I*I*I 1/2, a 1/4*I-oI*IuI*I^3IuI^1I 1/2 I'a 1/2^2 I*a 1/4*I
1/4IuI>>I?I*I 1/4IuI 1/2I?I 1/2.
I*I^1I'I-I*I?I*I* ICURI*I*I*I+-I 1/2I?I* [110]
---------------------------------------------------------------------
Creon
In this our land, so said he, those who seekA Shall find; unsought, we
lose it utterly.
Oedipus Rex [110]
---------------------------------------------------------------------
The Web Security Mailing List
WebSecurity RSS Feed
http://www.webappsec.org/rss/websecurity.rss
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
WASC on Twitter
http://twitter.com/wascupdates
websecurity@lists.webappsec.org
http://lists.webappsec.org/mailman/listinfo/websecurity_lists.webappsec.org
--
[Pavol Luptak, Nethemba s.r.o.] [http://www.nethemba.com] [tel: +421905400542]
Hi Pavol,
People's experiences vary, however our research places CAPTCHA (and
similar) as an effective tool against automated scans despite that it
increases the attack surface of the web application. It's use
therefore may best be used when creating new content or accounts but
not for logging in to an existing account. Additionally, if you have a
service that is barraged by robots or other automated reapers, it
"may" help especially if it will increase the resources necessary by
the attacker more than your own. For example, SSH CAPTCHA meets those
requirements.
The economics of CAPTCHA may not be worth it either though. On the
user side, SEO's claim it basically kills user participation, slashing
the number of people who join things or sign-up to things to deathly
low numbers. But that's hearsay as I haven't seen any stats on that.
With that in mind, I'm sure there is also an indirect effect on
increased help desk support as well. But I'm just extending the SEO
logic here.
I suspect, there is no broad answer since the effectiveness of CAPTCHA
is dependent on the environment it's placed in and the process it is
within. Most likely the situation where attackers would use cracking
methods or pay per click from other sentient beings (who knows,
perhaps some day dolphins will be exploited for this purpose) you will
want to apply a few from the 9 additional operational controls instead
or as well.
Sincerely,
-pete.
--
Pete Herzog - Managing Director - pete@isecom.org
ISECOM - Institute for Security and Open Methodologies
www.isecom.org - www.osstmm.org
www.hackerhighschool.org - www.badpeopleproject.org
On 2/12/2012 11:45 PM, Pavol Luptak wrote:
BTW, I would like to hear your opinions about CAPTCHA's effectivness...
Till now, all my tested CAPTCHAs were successfully cracked by some automated
tools (captchakiller, decaptcher.com, www.deathbycaptcha.com, ..) including
Google ReCAPTCHA....OK, the best decaptchers are paid (but $1.39 for 1000
solved CAPTCHAs is not so much), so it seems that CAPTCHA is a usable
protection against poor hackers only, maybe stupid spambots...
Pavol
Hi Pete,
On Mon, Feb 13, 2012 at 03:01:15PM +0100, Pete Herzog wrote:
People's experiences vary, however our research places CAPTCHA (and
similar) as an effective tool against automated scans despite that
it increases the attack surface of the web application. It's use
therefore may best be used when creating new content or accounts but
not for logging in to an existing account. Additionally, if you have
a service that is barraged by robots or other automated reapers, it
"may" help especially if it will increase the resources necessary by
the attacker more than your own. For example, SSH CAPTCHA meets
those requirements.
The economics of CAPTCHA may not be worth it either though. On the
user side, SEO's claim it basically kills user participation,
slashing the number of people who join things or sign-up to things
to deathly low numbers. But that's hearsay as I haven't seen any
stats on that. With that in mind, I'm sure there is also an indirect
effect on increased help desk support as well. But I'm just
extending the SEO logic here.
Firstly, thanks a lot for your response!
I'm just trying to perceive it from the pentester's point of view - nowadays
almost all CAPTCHAs can be easily cracked in fully automated way...
so the original idea of CAPTCHA (to distinguish between humans and computers)
becomes a bit obsolete :) (consequently user enumeration using registration
forms is often possible...)
In case of registration forms we usually propose (to our customers) to bind
the new user with his/her mobile number (and require to confirm a randomly
generated SMS token) that is probably more efficient way to protect against
user enumeration than CAPTCHA, but this cannot be used everywhere (due to the
text messages expenses or it can be considered to be a privacy issue).
The other simple solution is just to make some rate-limitation (max number of
registration forms or "forgotten password" forms sent from one
IP address/subnet that makes impossible user enumeration).
[Pavol Luptak, Nethemba s.r.o.] [http://www.nethemba.com] [tel: +421905400542]
Pavol,
I'm just trying to perceive it from the pentester's point of view - nowadays
almost all CAPTCHAs can be easily cracked in fully automated way...
so the original idea of CAPTCHA (to distinguish between humans and computers)
becomes a bit obsolete :) (consequently user enumeration using registration
forms is often possible...)
Humans are pattern-matching creatures. So are computers. So any
pattern you make that's also recognizable to the "average" person can
be programmed to be recognized by a computer. I think we've reached
the point where pattern matching or logical conclusions reachable by
the average person is the same or better by computer. So if CAPTCHA
gets more complicated then it will also get more difficult for most
people. And it doesn't have to be that much more complicated. I think
all of us can admit to having failed a CAPTCHA or two in our internet
lifetimes.
So I don't think CAPTCHA can really play a valid part as a
significant, machine hurdle. As you mentioned with using an out of
band technique- which is really just the extension that assumes at
this point that computers don't "own" mobile phones and can get an
SMS. Or else it's a case of economics and effort that the asset they
can steal is less valuable than the cost of being able to receive an
SMS. But that may be going too as more people use Internet-based SMS
or have them forwarded to their e-mail accounts.
Basically, you can only choose a method that works for now with the
intention of changing when people's habits change. The best thing you
can do is measure the reasons to trust any particular method and go
with the one you can trust the most. (OSSTMM will show you how to
measure trust).
Sincerely,
-pete.
--
Pete Herzog - Managing Director - pete@isecom.org
ISECOM - Institute for Security and Open Methodologies
www.isecom.org - www.osstmm.org
www.hackerhighschool.org - www.badpeopleproject.org