Disclosure and Google's Response
- An arbitrary step is appended to the end of the login procedure (e.g. a "password incorrect, please try again" page, which steals credentials upon the user re-entering them)
- An arbitrary file is sent to the user's browser each time the login form is submitted, without unloading the login page
- Etc... vectors only limited by breadth of Google services that could be misused under the guise of a login step
- Must point to *.google.com/*
- Open Redirects (pick one)
- Arbitrary File Upload (Google Drive)
Preventative Measures and Remediation
- Always check the URL – before entering credentials – including at each stage of the login process
- Avoid login after clicking links that don't come directly from Google – bad links could be anywhere: even Google search results
An example use case would be behind the ruse of user protected content that requires sign-in (e.g. content on Google Drive)
- If it looks like Google sent you a file at sign-in, don't run it. Regardless of what it is named, you can't trust it.
Steps to reproduce:
1. Exploit is on the legitimate login page [https://accounts.google.com/ServiceLogin?service=mail]
However, due to a certain keyword contained in the description of this vulnerability, I have been unable to communicate it to a real person in previous reports (instead I am sent information about [keyword] not being considered a vulnerability). Despite trying to communicate I know this, and I am not trying to report [keyword] as a vulnerability, rather I am leveraging [keyword] to do something different.
Please respond to me and I will gladly explain the vulnerability to a real person.
A user who is linked to the legitimate login page for Google, may have a step inserted into the login process [e.g. that steals credentials].
Google Security Team
Go ahead and explain the vulnerability.
Google Security Team
Basic experimentation with this reveals that the parameter is safety checked before loading the page. For instance, setting the value to http://example.com results in an error page, instead of login (this makes sense, because you don't want an arbitrary page inserted at the end of the login proccedure).
However, the application logic fails to check that domains specified are not Google services that may pose a risk.
E.g. it is possible to specify the value of this parameter, as shown: "continue=https://www.google.com/amp/example.com#identifier" (https://accounts.google.com/ServiceLogin?service=mail&continue=https://www.google.com/amp/example.com#identifier)
Using an existing open redirect, it is now possible to send a user to an arbitrary page after login. This opens up the following series of events:
User follows link -> user sees singin prompt -> user verifies domain to be legitimate Google login page -> user types their username -> page redirects -> user types their password -> page redirects -> sorry, incorrect password -> user re-types their password -> page redirects to Google service.
In the stage where a user is told their password is incorrect, they would have been unknowingly and seamlessly redirected to an attacker's website while in the process of logging in to the legitimate google.com.
Additionally, further experimentation reveals that the domain docs.google.com is also an accepted value in this continue parameter.
This allows me to directly link to an almost arbitrary file hosted in Google Drive, with public link sharing enabled. By specifying the direct download path, I am able to encourage the browser to download an arbitrary file without even leaving the legitimate login page – potentially leading a user to believe Google wants them to run the file, and definitely appearing that Google just sent the file (due to not leaving the login page).
During limited experimentation, I was able to successfully specify both *.html, and *.exe files and have them download without leaving the login page.
If I understand correctly the only attack scenario you have in mind is phishing, we invest in technologies to detect and alert users about phishing and abuse. Take a look at https://sites.google.com/site/bughunteruniversity/nonvuln/open-redirect. If you can come up with a convincing attack vector let me know.
Google Security Team
Take a look at the latter part of my description, it can aid in distribution of arbitrary files too.
That said, clearly Google intended this not to happen (inferred by presence of the check that's performed on the parameter).
I'm not saying the open redirect is a vuln. I'm aware of Google's categorisation on that. However, clearly this is more than phishing when an adversary may integrate it into the legitimate login process.
The page you linked to even notes that URL whitelist bypass is classed as a vuln. (the whitelist being bypassed in this scenario is the one that is in place on the continue param).
Thanks for your bug report and research to keep our users secure! We've investigated your submission and made the decision not to track it as a security bug.
This report will unfortunately not be accepted for our VRP. Only first reports of technical security vulnerabilities that substantially affect the confidentiality or integrity of our users' data are in scope, and we feel the issue you mentioned does not meet that bar :(
Bummer, we know. Nevertheless, we're looking forward to your next report! To maximize the chances of it being accepted, check out Bughunter University and learn some secrets of Google VRP.