Google's Faulty Login Pages

27 Aug, 2016

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/*
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

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.
MeFri, Aug 19, 2016 at 7:11 PMSummary: 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].
GoogleMon, Aug 22, 2016 at 6:38 PMHey - 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
GoogleMon, Aug 22, 2016 at 6:39 PMHey,

Go ahead and explain the vulnerability.

Karshan,
Google Security Team
MeMon, Aug 22, 2016 at 6:53 PMThe 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.
GoogleTue, Aug 23, 2016 at 10:23 PMHey,

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
MeTue, Aug 23, 2016 at 10:34 PMHey,

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).
GoogleTue, Aug 23, 2016 at 11:39 PMHey,

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
1 Jan, 2017

Recently I've been working on a drop in class to manage certain "Secure Headers" in PHP.

By "Secure Headers", I'm of course talking about those mentioned in the OWASP Secure Headers Project.

The project, SecureHeaders is available on GitHub.

Why?

If you're familiar with PHP, you'll know that...[read more]

27 Aug, 2016

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...[read more]
22 May, 2016
Biometric sensors are good at identity. They can tell you exactly who a fingerprint belongs to; who's face is in-front of the camera; even who's DNA was left at a crime-scene. But biometric sensors are not good authenticators.

Replay Attacks

Let's say Bob, thinks it's a good idea to add a voice activated lock to his house...[read more]
4 May, 2016

Preamble

A little over a month ago I contacted my bank (Santander), asking them why they served me their homepage insecurely...[read more]
2 May, 2016
In this post I'll address one specific task: obtaining a manual certificate from Let's Encrypt.

Who is this for?

If you don't have direct command line access, or the necessary permissions to install Let's Encrypt on your webserver; then you won't be able to obtain a certificate using the automated process.
If you can install Let's Encrypt on your webserver, you should. It simplifies the process down to a single command. You'll also enjoy the benefits of being able to setup an auto renew process directly on the machine serving the certificate...[read more]