Disclosure and Google's Response
This one feels very strange writing, because the vulnerability detailed below is currently exploitable. Google has been notified of this vulnerability, yet they have chosen to do nothing.
GoogleThanks 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.
In hope that public disclosure will encourage Google to do otherwise, here goes.
Summary
Able to poison the functionality of the login submit action, such that either:
- 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
Vulnerability
Google's login page accepts a vulnerable GET parameter, namely 'continue'. As far as I can determine, this parameter undergoes a basic check
- Must point to *.google.com/*
- Open Redirects (pick one)
- Arbitrary File Upload (Google Drive)
- https://www.google.com/amp/[any_domain_here]
- https://docs.google.com/uc?id=[file_id_here]&export=download
Preventative Measures and Remediation
First as a user. Due to Google's stance on open-redirects (even demonstrably unsafe ones – like at login), it is not possible to assume all pages are to be trusted.
For a login process such as Google's: one that is already multi-page by design – this is extremely unintuitive.
- 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.
Google has some different options available. They have taken a sensible initial approach by whitelisting their own domain, but the underlying issue here is that their whitelist is too broad.
*.google.com/* is home to too many services to trust implicitly. Instead they should work on selecting known safe [sub-]domains individually (wildcards in a whitelist aren't a great thing to have if you can help it). Even specify exact paths on those domains if user content is mixed with services they would like to forward to.
The other option of course, is kill the redirect here – last resort stuff, I know. And yes it's a useful feature, but if it can't be made to be safe, then it really should have no place on a login page. The login page is not an appropriate page to put under-developed features, especially when successful abuse of these can result in catastrophic consequences.
Correspondence
I couldn't quite believe that Google had both understood this issue, and simply shrugged it off. So I opened several reports to make sure understanding, or communicating the issue wasn't the error here. In total, three reports were opened with Google; three reports were closed. I have included the final report here, to which I received the most responses.
MeSummary: Able to insert arbitrary step into login process
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.
Browser/OS: all
Attack scenario:
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].
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.
Browser/OS: all
Attack scenario:
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].
GoogleHey - Just letting you know that your report was triaged and we're currently looking into it. You should receive a response in a couple of days, but it might take up to a week if we're particularly busy.
Thanks,
Google Security Team
Thanks,
Google Security Team
GoogleHey,
Go ahead and explain the vulnerability.
Karshan,
Google Security Team
Go ahead and explain the vulnerability.
Karshan,
Google Security Team
MeThe URL (https://accounts.google.com/ServiceLogin?service=mail) accepts a GET parameter 'continue'.
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.
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.
GoogleHey,
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.
Karshan,
Google Security Team
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.
Karshan,
Google Security Team
MeHey,
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).
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).
GoogleHey,
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.
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.
Contact
Questions, clarifications, corrections? Contact me on Twitter @aidantwoods