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  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
- Sending searches from a robot, computer program, automated service, or search scraper
- Using software that sends searches to Google to see how a website or webpage ranks on Google
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  a user needs serious protection from Google!
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.
facebook⠀⠀⠀⠀which can be easily indexed as fakefacebook.com (the “space” here is a Unicode Character “⠀” (U+2800) )
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
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.
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.
When the warning appears the additional redirect is being made from
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.
Although the both
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
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 to
1 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
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.
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.
Flood!button and wait for the captcha to appear. (it attempts to search for 300 words)
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
When experimenting with the PoC I noticed a few unexpected behaviors:
window Xthen by repeating the exactly same causing it query in the
window Ywe can prepare the clickjack point without knowing the URL of the original captcha and solving it enables another series of available requests in the