I recently reported an issue to Google, which allows an attacker to confirm whether a visitor to a web page is logged in to any one of a list of specific Google accounts (including GSuite accounts). It is possible to check about 1000 email addresses every 25 seconds. Google have confirmed this as working as intended, and not considered a bug.
You can test it out yourself on this demo page.
Firstly, a video of a proof of concept, where I identify an account (myself) against a list of 20 accounts:
Method
I’ve previously written about identifying whether a user is logged in to a certain social network, and this attack is a variation of that method (albeit more serious, IMHO).
Google login pages often pass a continue parameter in the URL that is used to redirect a user to their intended destination after they complete login. However, if you are already logged in then you just get redirected immediately to the URL specified in the continue parameter.
This fact can be abused to craft a URL that will redirect users who are logged in to an image file, and challenge users who are not logged in with a login page. If you now use this URL as the src element in an img tag, you can use the Javascript onload and onerror functions to determine whether the image loaded correctly or not.
If the image loaded, then the user is logged in, and if it errored then the user is not logged in. This is an known issue but has limited capacity to cause any sort of problem.
However, Google succumbs to a far more dangerous variation where the attacker can also supply an additional parameter specifying an email address. The redirect then fires if the email matches, but otherwise not.
At this point an attacker can just dynamically create loads of image tags (no need to even add them to the page, you can do it without attaching them to the DOM) with onload attributes and wait for a match. In my tests I could check about 1000 emails every 23-24 seconds or so. If a user is on your site for a couple of minutes then you could check many thousands of possible emails.
Combined with other ways to partially identify users — from using their geography via IP, targeting them with very-targeted (demographically or otherwise) social ads, identifying their corporate network or many other methods, you could dynamically load lists of targets. You can then match these people against requests and record their IP address, location, device, and all sorts of other information.
You may then use that knowledge to setup the attack above to then do some dynamic spear-phishing.
Disclosure Timeline
- 14th July – I reported this to the security team via their form.
- 17th July – I heard back it was triaged and awaiting attention.
- 18th July – The team came back to me and asked me what my suggestions for handling this would be.
- 18th July – I went back to them with my suggestion for some sort of nonce or salted hash of the email such that a the redirect only worked with that hash and email combo, to stop blind attacks.
- 19th July – The security team confirms they are filing this as a bug.
- 21st July – I sent over a copy of my blog post as additional explanation.
- 9th August – Google team lets me know, after discussion, this is intended behaviour. They suggested there may be rate limiting at a higher rate (I’ve not tried to confirm), and don’t consider it a problem. No action to be taken.
This bug is quite specific, in that you need to have a target or list of target victims. However, I did think it could be quite bad if used.
If you missed it you can test this out here: demo page.
Lastly, a big thanks and shout out to the Google security team, they were responsive, friendly and communicative. 🙂