This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Testing for Captcha (OWASP-AT-008)"

From OWASP
Jump to: navigation, search
 
(37 intermediate revisions by 4 users not shown)
Line 2: Line 2:
  
 
== Brief Summary ==
 
== Brief Summary ==
Captcha ("Completely Automated Public Turing test to tell Computers and Humans Apart") is a type of challenge-response test used by many web applications to ensure that the response is not generated by a computer. Captcha implementations are often vulnerable to various kinds of attacks even if the generated captcha is unbreakable.
+
CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") is a type of challenge-response test used by many web applications to ensure that the response is not generated by a computer. CAPTCHA implementations are often vulnerable to various kinds of attacks even if the generated CAPTCHA is unbreakable.
This section will help you to identify these kinds of attacks and propose possible solutions.
+
This section will help you to identify these kinds of attacks.
  
 
== Description of the Issue ==  
 
== Description of the Issue ==  
 +
Although CAPTCHA is not an authentication control, its use can be very efficient against:
  
Implementation of good captcha mechanism can be very efficient against:
+
* [https://www.owasp.org/index.php/Testing_for_user_enumeration enumeration attacks] (login, registration or password reset forms are often vulnerable to enumeration attacks - without CAPTCHA the attacker can gain valid usernames, phone numbers or any other sensitive information in a short time)
 +
* automated sending of many GET/POST requests in a short time where it is undesirable (e.g., SMS/MMS/email flooding), CAPTCHA provides a rate limiting function
 +
* automated creation/using of the account that should be used only by humans (e.g., creating webmail accounts, stop spamming)
 +
* automated posting to blogs, forums and wikis, whether as a result of commercial promotion, or harassment and vandalism
 +
* any automated attacks that massively gain or misuse sensitive information from the application
  
* enumeration attacks (login, registration or password reset forms are often vulnerable to this kind of attacks - the attacker can in a short time gain a lot of valid usernames, phone numbers, etc)
+
Using CAPTCHAs as a CSRF protection is not recommended (because there are [[Testing_for_CSRF  (OWASP-SM-005)|stronger CSRF countermeasures]]).
* automated sending of many GET/POST requests in a short time even if it is undesirable (e.g. SMS/MMS/email flooding)
 
 
(e.g. SMS/MMS/email messages,  undesirable
 
 
* any automated attacks than gain any sensitive information from the application
 
  
Captchas should not use:
+
These vulnerabilities are quite common in many CAPTCHA implementations:
  
* as a CSRF protection (the attacker can still steal the generated captcha nad break it in a real time)
+
* generated image CAPTCHA is weak, this can be identified (without any complex computer recognition systems) only by a simple comparison with already broken CAPTCHAs
 +
* generated CAPTCHA questions have a very limited set of possible answers
  
 +
* the value of decoded CAPTCHA is sent by the client (as a GET parameter or as a hidden field of POST form). This value is often:
 +
** encrypted by simple algorithm and can be easily decrypted by observing of multiple decoded CAPTCHA values
 +
** hashed by a weak hash function (e.g., MD5) that can be broken using a rainbow table
 +
                                                                             
 +
* possibility of replay attacks:
 +
** the application does not keep track of what ID of CAPTCHA image is sent to the user. Therefore, the attacker can simply obtain an appropriate CAPTCHA image and its ID, solve it, and send the value of the decoded CAPTCHA with its corresponding ID (the ID of a CAPTCHA could be a hash of the decoded CAPTCHA or any unique identifier) 
 +
** the application does not destroy the session when the correct phrase is entered - by reusing the session ID of a known CAPTCHA it is possible to bypass CAPTCHA protected page
  
 +
== Black Box testing and example ==
 +
 +
Use an intercepting fault injection proxy (e.g., [[OWASP WebScarab Project|WebScarab]]) to:
 +
 +
* identify all parameters that are sent in addition to the decoded CAPTCHA value from the client to the server (these parameters can contain encrypted or hashed values of decoded CAPTCHA and CAPTCHA ID number)
 +
* try to send an old decoded CAPTCHA value with an old CAPTCHA ID (if the application accepts them, it is vulnerable to replay attacks)
 +
* try to send an old decoded CAPTCHA value with an old session ID (if the application accepts them, it is vulnerable to replay attacks)
 
   
 
   
Many image captchas can be identified as weak by simple
+
Find out if similar CAPTCHAs have already been broken. Broken CAPTCHA images can be found here [http://www.cs.sfu.ca/~mori/research/gimpy/ez/ gimpy], [http://libcaca.zoy.org/wiki/PWNtcha PWNtcha], and [http://www.lafdc.com/captcha/ lafdc].
  
<br>
+
Verify if the set of possible answers for a CAPTCHA is limited and can be easily determined.
  
* decoded captcha is encrypted (usually by some "security-by-obscurity"     
+
== Gray Box testing and example ==
"home-made" algorithm) and this value is sent by client as a hidden field   
 
(yeah, it's unbelievable but some web applications really do it in this way).
 
Often this can be easily decrypted by observing of multiple captcha values. 
 
                                                                             
 
* even if it is difficult to decrypt decoded captcha value, many captchas are
 
vulnerable to replay attacks (attacker simply send old values of encrypted   
 
decoded captcha value and decoded value of this captcha)                     
 
                                                                             
 
* many captchas don't destroy the session when the correct phrase is entered -
 
by reusing the session id of a known captcha it is possible to bypass       
 
captcha protected page                                                       
 
                                                                             
 
* many captchas can be identified as weak by simple comparison with already 
 
broken captchas (e.g. http://www.cs.sfu.ca/~mori/research/gimpy/,           
 
http://libcaca.zoy.org/wiki/PWNtcha, http://www.lafdc.com/captcha/)
 
  
<br>
+
Audit the application source code in order to reveal:
  
== Black Box testing and example ==
+
* used CAPTCHA implementation and version - there are many known vulnerabilities in widely used CAPTCHA implementations, see http://osvdb.org/search?request=captcha
 
+
* if the application sends encrypted or hashed value from the client (which is a very bad security practice) verify if used encryption or hash algorithm is sufficiently strong
== Gray Box testing and example ==
 
  
  
 
== References ==
 
== References ==
 
'''Definition'''<br>
 
http://en.wikipedia.org/wiki/Captcha
 
  
 
'''Captcha Decoders'''<br>
 
'''Captcha Decoders'''<br>
PWNtcha - opensource captcha decoder -
+
* [http://cintruder.sourceforge.net/ (Opensource) CaptchaIntruder]
http://libcaca.zoy.org/wiki/PWNtcha
+
* [http://libcaca.zoy.org/wiki/PWNtcha (Opensource) PWNtcha captcha decoder]
Commercial captach decoder - http://www.lafdc.com/captcha/
+
* [http://churchturing.org/captcha-dist/ (Opensource) The Captcha Breaker]
 +
* [http://www.lafdc.com/captcha/ (Commercial) Captcha decoder]
 +
* [http://www.captchakiller.com/ (Commercial - Free) Online Captcha Decoder] Free limited usage, enough for testing.
  
'''Papers'''<br>
+
'''Articles'''<br>
Breaking a Visual CAPTCHA - http://www.cs.sfu.ca/~mori/research/gimpy/
+
* [http://www.cs.sfu.ca/~mori/research/gimpy/ Breaking a Visual CAPTCHA]
 +
* [http://www.puremango.co.uk/cm_breaking_captcha_115.php Breaking CAPTCHAs Without Using OCR]
 +
* [http://securesoftware.blogspot.com/2007/11/captcha-placebo-security-control-for.html Why CAPTCHA is not a security control for user authentication]

Latest revision as of 03:14, 12 December 2012

OWASP Testing Guide v3 Table of Contents

This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.

OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here

Brief Summary

CAPTCHA ("Completely Automated Public Turing test to tell Computers and Humans Apart") is a type of challenge-response test used by many web applications to ensure that the response is not generated by a computer. CAPTCHA implementations are often vulnerable to various kinds of attacks even if the generated CAPTCHA is unbreakable. This section will help you to identify these kinds of attacks.

Description of the Issue

Although CAPTCHA is not an authentication control, its use can be very efficient against:

  • enumeration attacks (login, registration or password reset forms are often vulnerable to enumeration attacks - without CAPTCHA the attacker can gain valid usernames, phone numbers or any other sensitive information in a short time)
  • automated sending of many GET/POST requests in a short time where it is undesirable (e.g., SMS/MMS/email flooding), CAPTCHA provides a rate limiting function
  • automated creation/using of the account that should be used only by humans (e.g., creating webmail accounts, stop spamming)
  • automated posting to blogs, forums and wikis, whether as a result of commercial promotion, or harassment and vandalism
  • any automated attacks that massively gain or misuse sensitive information from the application

Using CAPTCHAs as a CSRF protection is not recommended (because there are stronger CSRF countermeasures).

These vulnerabilities are quite common in many CAPTCHA implementations:

  • generated image CAPTCHA is weak, this can be identified (without any complex computer recognition systems) only by a simple comparison with already broken CAPTCHAs
  • generated CAPTCHA questions have a very limited set of possible answers
  • the value of decoded CAPTCHA is sent by the client (as a GET parameter or as a hidden field of POST form). This value is often:
    • encrypted by simple algorithm and can be easily decrypted by observing of multiple decoded CAPTCHA values
    • hashed by a weak hash function (e.g., MD5) that can be broken using a rainbow table
  • possibility of replay attacks:
    • the application does not keep track of what ID of CAPTCHA image is sent to the user. Therefore, the attacker can simply obtain an appropriate CAPTCHA image and its ID, solve it, and send the value of the decoded CAPTCHA with its corresponding ID (the ID of a CAPTCHA could be a hash of the decoded CAPTCHA or any unique identifier)
    • the application does not destroy the session when the correct phrase is entered - by reusing the session ID of a known CAPTCHA it is possible to bypass CAPTCHA protected page

Black Box testing and example

Use an intercepting fault injection proxy (e.g., WebScarab) to:

  • identify all parameters that are sent in addition to the decoded CAPTCHA value from the client to the server (these parameters can contain encrypted or hashed values of decoded CAPTCHA and CAPTCHA ID number)
  • try to send an old decoded CAPTCHA value with an old CAPTCHA ID (if the application accepts them, it is vulnerable to replay attacks)
  • try to send an old decoded CAPTCHA value with an old session ID (if the application accepts them, it is vulnerable to replay attacks)

Find out if similar CAPTCHAs have already been broken. Broken CAPTCHA images can be found here gimpy, PWNtcha, and lafdc.

Verify if the set of possible answers for a CAPTCHA is limited and can be easily determined.

Gray Box testing and example

Audit the application source code in order to reveal:

  • used CAPTCHA implementation and version - there are many known vulnerabilities in widely used CAPTCHA implementations, see http://osvdb.org/search?request=captcha
  • if the application sends encrypted or hashed value from the client (which is a very bad security practice) verify if used encryption or hash algorithm is sufficiently strong


References

Captcha Decoders

Articles