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.

Google 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.

In hope that public disclosure will encourage Google to do otherwise, here goes .

Summary

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 Able to poison the functionality of the login submit action, such that either:

Vulnerability

Must point to *.google.com/* The application fails to verify the type of Google service that has been specified. This means that is is possible to seamlessly insert any Google service at the end of the login process. A couple Google service's come to mind that might be interesting: Open Redirects (pick one)

Arbitrary File Upload (Google Drive) It is possible to specify both an open redirect https://www.google.com/amp/[any_domain_here] And also an arbitrary file, provided public link sharing is enabled after uploading it to Google Drive https://docs.google.com/uc?id=[file_id_here]&export=download Google's login page accepts a vulnerable GET parameter, namely 'continue'. As far as I can determine, this parameter undergoes a basic checkThe application fails to verify the type of Google service that has been specified. This means that is is possible to seamlessly insert any Google service at the end of the login process. A couple Google service's come to mind that might be interesting:It is possible to specify both an open redirectAnd also an arbitrary file, provided public link sharing is enabled after uploading it to Google Drive

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.

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)

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. For a login process such as Google's: one that is already multi-page by design – this is extremely unintuitive.

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.

Me



Steps to reproduce:

1. Exploit is on the legitimate login page [

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]. Summary: Able to insert arbitrary step into login processSteps 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: allAttack 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].

Google Hey - 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

Google Hey,



Go ahead and explain the vulnerability.



Karshan,

Google Security Team

Me



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



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. The 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: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: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.

Google



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



Karshan,

Google Security Team Hey,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

Me Hey,



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).

Google Hey,



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