6Le…JWe: the secret key which disables reCAPTCHA response verification.secret: the name of the parameter I want to “inject”.%26: an URL encoded ampersand character.Note that I’m sending a specially crafted response to the vulnerable web application, which contains: If the application was vulnerable to HTTP parameter pollution AND the URL was constructed by appending the response parameter before the secret then an attacker was able to bypass the reCAPTCHA verification. Recaptcha-response=anything%26secret%3d6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe Now that we have all the ingredients, let’s take a look at the exploit: POST /verify-recaptcha-response HTTP/1.1 Secret key: 6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe.Site key: 6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI.This is well documented and explained in the documentation, to sum it up, if you want to disable reCAPTCHA verification please use the hard-coded site and secret key shown below: Web developers need to test their applications in an automated way, with that goal Google provided an easy way to “disable” reCAPTCHA’s verification in staging environments. This is not a vulnerability, but was used in the exploit. The reCAPTCHA API always used the first secret parameter on the request and ignored the second one. This HTTP request will look like: POST /verify-recaptcha-response HTTP/1.1 The user solves the CAPTCHA and clicks “Verify”, which will trigger an HTTP request to the web application. When the web application wants to challenge the user, Google provides an image set and uses JavaScript code to show them in the browser as follows: The following introduction is for the use case where the vulnerability was found. reCAPTCHA is a complex beast with a lot of use cases: sometimes it will trust you based on your existing cookies, sometimes it will require you to solve multiple challenges. ReCAPTCHA is a Google service that allows web application developers to add a CAPTCHA to their site with minimal effort. The security issue was fixed “upstream” at Google’s reCAPTCHA API and no modifications are required to your web applications. The bypass required the web application using reCAPTCHA to craft the request to /recaptcha/api/siteverify in an insecure way but when this situation occurred the attacker was able to bypass the protection every time.
I reported a reCAPTCHA bypass to Google in late January.
0 kommentar(er)
