Shulou(Shulou.com)05/31 Report--

Using HTTP parameter pollution to bypass the example analysis of Google recaptcha verification mechanism, I believe that many inexperienced people are at a loss about this. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Earlier this year, I reported a Google reCAPTCHA CAPTCHA bypass vulnerability that allows reCAPTCHA on Web pages to construct a request for / recaptcha/api/siteverify in an insecure way contaminated by HTTP parameters, in which case an attacker can bypass reCAPTCHA's security authentication mechanism every time. After that, Google fixed the vulnerability from the top-level interface of reCAPTCHA API. Here, let's take a look at how the reCAPTCHA mechanism is bypassed.

Introduction of reCAPTCHA authentication mechanism

ReCAPTCHA is a free verification service provided by Google, which makes it easy for Web application developers to add CAPTCHA authentication (CAPTCHA) mechanism to some websites that require human-computer authentication or other forms of authentication. There are many practical use cases for reCAPTCHA services. For example, sometimes it uses the cookie you logged in to the site for authentication, and sometimes it allows users to manually complete some of the identification tests it provides.

I found this loophole from a visit to a target website. After visiting the target website, like the following figure, the site needs to verify the user's identity. At this point, the Google reCAPTCHA API API is called to display a set of pictures or numbers for the user to choose:

When a user clicks the verification code CAPTCHA to "Verify", a HTTP request to visit the website is triggered, which is roughly as follows:

POST / verify-recaptcha-response HTTP/1.1Host: vulnerable-app.comrecaptcha-response= {reCAPTCHA-generated-hash}

After that, the target website needs to call Google's reCAPTCHA API interface to let the user test the authentication provided by the API, and then verify the user's identity according to the test response. The POST request for calling Google reCAPTCHA API API is as follows:

POST / recaptcha/api/siteverify HTTP/1.1Content-Length: 458Host: www.google.comContent-Type: application/x-www-form-urlencodedrecaptcha-response= {reCAPTCHA-generated-hash} & secret= {application-secret}

Where {application-secret} is used to verify the target website, and {reCAPTCHA-generated-hash} is a response query sent to Google reCAPTCHA API API. If the user's final test is correct, API will return the following response information:

HTTP/1.1 200 OKContent-Type: application/json; charset=utf-8Content-Length: 90 {"success": true, "challenge_ts": "2018-01-29T17:58:36Z", "hostname": "..."}

This response information will eventually be received by the target visiting website, and then processed according to the response information, which will eventually allow the user to access the corresponding website resources.

HTTP parameter pollution

HTTP parameter pollution, or HPP, occurs when a website accepts user input and uses it to generate HTTP requests sent to other systems without verifying the user's output. This is mainly due to different ways of handling different request parameters on different websites.

HTTP parameter contamination may exist in many places, such as client or server, and its risk varies from environment to environment. In some specific scenarios or practical applications, it can lead to data leakage, but in other use cases, it may only be a low-risk vulnerability.

Our Google reCAPTCHA needs to use the HTTP parameter pollution method in the target visit website during the bypass process, so the special requirement construction of this bypass method ultimately lowers Google's classification rating of the vulnerability.

The following is an example of a request for a target website that has the possibility of reCAPTCHA bypass:

Private String sendPost (String CaptchaResponse, String Secret) throws Exception {String url = "https://www.google.com/recaptcha/api/siteverify"+"?response="+CaptchaResponse+"&secret="+Secret; URL obj = new URL (url); HttpsURLConnection con = (HttpsURLConnection) obj.openConnection ()

The string concatenator + is used to connect different url variables.

It is important to note that at the back end of Google's API server, the following two HTTP requests will get the same response message.

POST / recaptcha/api/siteverify HTTP/1.1Host: www.google.com...recaptcha-response= {reCAPTCHA-generated-hash} & secret= {application-secret} POST / recaptcha/api/siteverify HTTP/1.1Host: www.google.com...recaptcha-response= {reCAPTCHA-generated-hash} & secret= {application-secret} & secret= {another-secret-application-secret}

Both POST requests have response and secret parameters. In the second POST request, Google's reCAPTCHA API always takes the first secret parameter, thus ignoring the second secret parameter. Strictly speaking, this is not a vulnerability in reCAPTCHA API itself, but a misuse mechanism, but can be used for in-depth attacks.

Key points of vulnerability exploitation

Web developers need to test their applications in an automated way, so Google provides an easy way to "disable" reCAPTCHA validation in a temporary simulation environment. You can click the Google documentation here to refer to it. In short, if you want to disable reCAPTCHA authentication, use the hard-coded site and key shown below:

Site key: 6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI

Secret key: 6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe

Testing using PoC

Now that we have all the necessary test elements, let's take a look at how to use:

POST / verify-recaptcha-response HTTP/1.1Host: vulnerable-app.comrecaptcha-response=anything%26secret%3d6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe

If the target visiting the site may have HTTP parameter contamination, and its URL link is built by adding the response parameter before the secret parameter, then the reCAPTCHA authentication method in this case may be bypassed.

Note that I want to send a constructed fake response message to the target visiting website, including the following attributes:

Anything: represents only one placeholder

% 26: a url-encoded & symbol character

Secret: the name of the parameter I want to "inject"

% 3D: a = symbol character encoded by url

6Le... JWe: disable the secret key of the reCAPTCHA verification response, which is also the first secret parameter we will use

When combined, the following HTTP request is sent by the target site to Google reCAPTCHA API:

POST / recaptcha/api/siteverify HTTP/1.1Host: www.google.comContent-Type: application/x-www-form-urlencodedUser-Agent: Python-urllib/2.7recaptcha-response=anything&secret=6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe&secret=6LeYIbsSAAAAAJezaIq3Ft_hSTo0YtyeFG-JgRtu

This request contains two secret parameters. Due to the possibility of HTTP parameter contamination in the target visiting website, the first secret parameter can be controlled by the attacker. This parameter 6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe is also officially given by Google to disable the reCAPTCHA authentication method. The second secret parameter is controlled by the target visiting website itself. Assuming that Google's reCAPTCHA API takes the first secret parameter, then reCAPTCHA authentication is indirectly disabled, and the response to the request will always be the following:

HTTP/1.1 200 OKContent-Type: application/json; charset=utf-8Content-Length: 90 {"success": true, "challenge_ts": "2018-01-29T17:58:36Z", "hostname": "..."}

In this way, after the target visits the site to process the request response, the reCAPTCHA is disabled and bypassed, and the attacker will naturally gain access to the site's resources.

Google's fixes from top-level API

Google decided to fix this problem in their REST API, which I think is a very wise move. Google's fix is also simple: if the HTTP request for / recaptcha/API/siteverify contains two parameters with the same name, an error message will be returned. With this fix, you can protect Web applications that are vulnerable to HTTP parameter contamination attacks and reCAPTCHA bypass without any update patches.

Make use of in opposition

There are two necessary requirements to exploit this vulnerability in Web applications: first, there are HTTP parameter contamination vulnerabilities in Web applications when creating reCAPTCHA url: in Github, I used search methods to find that about 60% of Web development architectures integrated with reCAPTCHA authentication are attacked by HTTP parameter contamination.

Secondly, Web applications vulnerable to HTTP parameter contamination need to first create a url with a response parameter, and then create a secret parameter, that is, a url parameter like this: "response= … & secret= …" But it is strange that almost all Web applications that use reCAPTCHA authentication use "secret= … & response= …" This parameter format, I think, may be that Google's documentation and code examples are regulated in this way, and other frameworks probably just copy this format. Google is lucky to be here. If they do the opposite, this vulnerability will affect more websites. GitHub search shows that only 5% to 10% of reCAPTCHA authentication mechanisms have construction requirements that this response parameter comes first and the secret parameter comes after.

So, if I want to exploit this vulnerability in the wild, only about 3 per cent of sites that use reCAPTCHA authentication end up with this vulnerability, which, although less influential and powerful, poses some security threat compared to other vulnerabilities. To sum up, as a developer, please be careful to use string concatenation to build the request string url, and use a dictionary to store keys and key values as far as possible, and then encode them with url. As a security tester, HTTP parameter contamination is a good penetration testing method.

After reading the above, have you mastered the method of using HTTP parameter pollution to bypass the example analysis of Google recaptcha authentication mechanism? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.