Clickjacking the reCAPTCHA in the suspicious activity context

Prolog

This research was supposed to be a part of a bigger report but since I think the impact is quite separable and could affect other services as well I have decided to make a separate report about my concerns related to user safeness.

Recently I have discovered that the user isn’t protected from being attacked by the brute-force approach by default. It opens a way for an attacker to use any exploitable vulnerability to steal as much sensitive victim’s data as possible.

Comes out that the only tool preventing the user from being brute-forced is the tool, that I believe, was intended to protect Google’s servers from being crawled rather than the safety of the user.
I couldn’t find the name of the tool but I think it is commonly known as “Unusual traffic from your computer network” error and from the Google [1] website we can read:

“Unusual traffic from your computer network”

If devices on your network seem to be sending automated traffic to Google, you might see “Our systems have detected unusual traffic from your computer network.”

What Google considers automated traffic

I believe that over the years the tool started to being also considered as user protection and that is why I think that it’s important that the tool is safe to use. Otherwise, in the age of plague of XS-Searches [2] a user needs serious protection from Google!

Brief summary

The report is about bypassing the “Unusual traffic from your computer network” warning with the help of clickjacking which at the moment of writing this article is probably the only mitigation to protect a user from being brute-forced.

Impact

  1. In connection with other vulnerabilities, a large portion of sensitive user’s data (stored at Google services) can be exposed to an attacker.
  2. Services could use this technique to unfairly improve their position in Google rankings by forcing visitors to search for favoring keywords.
  3. An attacker can force certain phrases (dozens of them) to appear as autosuggestions when the victim searches for something. For Example autocompletion facebook⠀⠀⠀⠀ is undetectable by a human eye and it would lead the victim to search for facebook⠀⠀⠀⠀ which can be easily indexed as fakefacebook.com (the “space” here is a Unicode Character “⠀” (U+2800) )

Detecting the reCAPTCHA

The very first step for an attacker is a detection of the suspicious activity warning itself. It allows making a decision about further steps. For example, an attacker can stop the attack for a specific period of time and continue when the captcha disappears – yes, it does disappear (without any help) after ~15 minutes!
I found a few ways to detect the warning and will present two of them: using history.length and window.length as an oracle. I will demonstrate both as the example of creating multiple queries to https://www.google.com/search?q=QUERY1.

By default Google search adds multiple parameters (e.x. ei=... or gs_l=psy-...) to the URL to confirm that the request was made by the user using the original http://google.com website or the URL bar. A leak of these parameters can lead the suspicious activity warning to appear.

  1. window.history

When the warning appears the additional redirect is being made from https://www.google.com/search?QUERY1 to https://www.google.com/sorry/index?QUERY2. It is possible to detect if the redirect was made in several ways. One of the ways using a window.history was described in this article: https://www.owasp.org/index.php/Cross_Site_History_Manipulation_(XSHM) where instead of the iframe a newly opened window let w = open(url); can be used to bypass a possible X-FRAME-OPTIONS: sameorigin header.

  1. window.length

Although the both https://www.google.com/search?q=QUERY1 and https://www.google.com/sorry/index?QUERY2 will have their final window.length property set to 2, by experimenting I noticed that in the second case the maximum length will be reached almost instantly while in the first one it’s achieved in ~8 seconds.
Thanks to this property it is possible to detect if the captcha appeared by either using an iframe or a newly opened window.

Clickcjaking the reCAPTCHA

When searching for the improvements for the above methods and the attack which I discovered with herrera alongside I found out that the clickjacking the reCAPTCHA is possible. The attack itself allows the leakage of private information from user’s Google account (such as emails, bills, purchases, flights and more) by using the XS-Search inside the Google search. The attack in combination with the “bug” I found is as horrendously effective that it allows an immense portion of user’s data to be leaked! Only in a span of two days, for needs of creating these reports, we managed to make thousands of requests…

After looking closely at the response headers that the GET request to https://www.google.com/sorry/index?QUERY2 returns I noticed that the important X-FRAME-OPTIONS: sameorigin header was missing! But is it missing after all? Maybe it isn’t missing but it’s required for some old embedded cross-origin searchers to be working? Nevertheless, it allows an attacker to just embed the captcha in the iframe and then persuade the user to make a click. The website that victim is on can also use the Google reCAPTCHA so when the suspicious activity warning appears the user won’t even notice that he is being under the attack since a captcha appearing on the website is very common these days… But the attacker can go even further and create a website where the user won’t be even aware of captcha clicks he is making. The best kind of website would be the website requiring a lot of clicks like for example the flappy bird game :)

Another downside of the leak of X-FRAME-OPTIONS: sameorigin header is that detecting the captcha appearance is even easier and more effective than any other known by me method. All that have to be done is setting the src of the iframe to the URL of the last request an attacker has made. If the request triggered the warning the redirect 302 is being made and hence the content of the iframe loads and the iframe.contentWindow.length value is equal to1 almost instantly. Otherwise, the content of any other google resource should be blocked due to X-FRAME-OPTIONS: sameorigin being set and in which case the iframe.contentWindow.length is equal to 0.

It’s also worth mentioning that the same iframe can be used for both detecting and clickjacking the warning to save as much time as possible.

Steps to reproduce

To prove that it’s possible to use the same iframe to do the clickjacking and detecting the warning I prepared a simple PoC which seems to be failproof even if the victim leaves the window. It is also possible to detect when the complex captcha appears - in that case, the captcha will appear more than one in a short amount of time.

  1. Open https://terjanq.github.io/Bug-Bounty/Google/clickjacking-reCAPTCHA-qgyb26mecsbb/poc.html.
  2. Click on Flood! button and wait for the captcha to appear. (it attempts to search for 300 words)
  3. Then, the red square should follow the cursor and after a click, it goes back to the center of the screen.
  4. If resolving the captcha was successful then yellow square stays at the center. It goes back to the step3 otherwise.

If you press and hold the grave accent (`) key an iframe will be maximized. Also, keep in mind that in the real attack the iframe would be totally invisible opacity:0 so the victim is unable to spot it

Few observations

When experimenting with the PoC I noticed a few unexpected behaviors:

  1. As mentioned earlier, the “suspicious activity” warning disappears after a fixed amount of time so the attacker can continue the attack when the victim revisits the page even without discovered clickjacking.
  2. All queries used in the PoC got stored in the user activity and therefore it made me invent a brand new attack which I called “autosuggestion attack”. The reason why the attacker can manipulate the autosuggestion is that queries are only blocked by CORS policy after being successfully sent into the Google servers.

three facebooks two removes

  1. If we repeat the search for the same words then they very often are being ignored by the “suspicious activity” mitigation.
  2. If the warning appeared in the window X then by repeating the exactly same causing it query in the window Y we can prepare the clickjack point without knowing the URL of the original captcha and solving it enables another series of available requests in the window X.