websecurity@lists.webappsec.org

The Web Security Mailing List

View all threads

CAPTCHA Reuse Attacks

Z
Zacharias
Sat, Feb 11, 2012 6:59 PM

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

--

Κρέων
ἐν τῇδ᾽ ἔφασκε γῇ· τὸ δὲ ζητούμενον
ἁλωτόν, ἐκφεύγειν δὲ τἀμελούμενον.
Οιδίπους Τύρρανος [110]

Creon
In this our land, so said he, those who seek  Shall find; unsought, we lose
it utterly.
Oedipus Rex [110]

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 -- --------------------------------------------------------------------- Κρέων ἐν τῇδ᾽ ἔφασκε γῇ· τὸ δὲ ζητούμενον ἁλωτόν, ἐκφεύγειν δὲ τἀμελούμενον. Οιδίπους Τύρρανος [110] --------------------------------------------------------------------- Creon In this our land, so said he, those who seek Shall find; unsought, we lose it utterly. Oedipus Rex [110] ---------------------------------------------------------------------
PL
Pavol Luptak
Sun, Feb 12, 2012 10:45 PM

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]
---------------------------------------------------------------------

--


[Pavol Luptak, Nethemba s.r.o.] [http://www.nethemba.com] [tel: +421905400542]

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]
PH
Pete Herzog
Mon, Feb 13, 2012 2:01 PM

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 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 >
PL
Pavol Luptak
Mon, Feb 13, 2012 5:35 PM

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


[Pavol Luptak, Nethemba s.r.o.] [http://www.nethemba.com] [tel: +421905400542]

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 -- ______________________________________________________________________________ [Pavol Luptak, Nethemba s.r.o.] [http://www.nethemba.com] [tel: +421905400542]
PH
Pete Herzog
Tue, Feb 14, 2012 10:18 AM

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

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