9 ms·

Google's login page accepts a vulnerable GET parameter

325 points by ivank 10y ago

libber 10y ago
A non-vulnerability like this is a good example of how easy it is to get press for $important_company + security. Top of hackernews at the moment and fingers crossed there wont be a wave of articles about this in the coming days from tech press who don't fully understand the issue but know clicks when they see them.
- ejcx 10y ago
  Not only to GET press, but also to PRESS the company for $. This is a huge problem I see with bugbounties. People running the bug bounties, who are not appsec security literate, are basically bullied in to thinking that something is a security risk when it is not quite often. I deal with people trying to do this 10-15 times per week. I can totally see how people get pushed in to paying thousands for essentially worthless bugs.
- mixedCase 10y ago
  A non-vulnerability? I understand how you could call it non-serious if you don't work on user-oriented code or think all users have perfect periferic vision all the time. But how do you explain the purpose for the check that fails any non-google domain then?
PuffinBlue 10y ago
I can appreciate their stance on phishing but being able to automatically execute an arbitrary file download that appears to come from Google as part of the login process strikes me as a bad thing, no?
- rezashirazian 10y ago
  It is. It also seems like an easy fix, I'm surprised why this hasn't been done yet.
  - quickben 10y ago
    Probably corporate inertia and big testing/deployment pipeline, etc.
  - innoying 10y ago
    It's not an "easy fix", there could be (and probably are) thousands of different endpoints that can be redirected to after login, whitelisting all of those just doesn't make sense.
    - rezashirazian 10y ago
      That sounds tedious, not necessarily difficult. I wonder if there is a technical challenge that goes beyond the tedious work of going through possible redirects and whitelisting them
- cbsmith 10y ago
  To get that exploit you'd need to send a faulty URL and get the user to follow it. You could just as easily do that with a faulty URL and no Google login. The only risk is if the redirect can access your login session/credentials. If it can't, no exploit.
  - _asummers 10y ago
    The Google login wraps the whole flow in a trojan horse, though. Users are taught to trust the single sign ons from FB/Google, and they're also taught to check the URL. Both of those would be false senses of security in this case. In isolation, this isn't necessarily a security vulnerability. But that it breaks down when users do what they're supposed to do? That's bad.
    - cbsmith 10y ago
      The logo and the host portion of the URL are ensuring that my credentials are going to Google, and not anyone else. The rest of the URL is telling me I shouldn't trust where I'm going. ;-)
- im4w1l 10y ago
  > automatically execute an arbitrary file download Your phrasing could easily be misread. A downloaded program would not automatically run.
  - euyyn 10y ago
    And in modern browsers/OS not even after you click on them, until you clear a "yes, I know this is risky" dialog.
  - PuffinBlue 10y ago
    Replace execute with 'initiate'?
cyberferret 10y ago
That is quite an incredible security flaw. I also appreciate the irony of using a Google service to exploit Google's login itself. It's akin to that scene in "Terminator 2" when the T-800 walks into a gun shop, asks to see all the top shelf guns, then loads up and shoots the shop owner before walking out...
- zachrose 10y ago
  That was Terminator 1 though.
  - ikeboy 10y ago
    Was it really Terminator 1 before any other films came out, though?
    - zachrose 10y ago
      No but it became Terminator 1 retroactively, much in the same way that Kyle Reese retroactively become John Connor's father.
  - caleblloyd 10y ago
    Clerk: "You can't do that" Arnie: "Wrong" https://m.youtube.com/watch?v=TsMAhHtHroE https://m.youtube.com/watch?v=TsMAhHtHroE
belovedeagle 10y ago
Frankly, I don't see any reason why Google isn't right here. This "vulnerability" can only be exploited by appending another one, fishing. It's reasonable to say, "If AB is a vulnerability only if B is a vulnerability, then A is not a vulnerability". That you can't solve fishing [as a service owner, without also owning the browser] is unfortunate but irrelevant.
- eadz 10y ago
  I disagree. The linked google page ( https://sites.google.com/site/bughunteruniversity/nonvuln/open-redirect https://sites.google.com/site/bughunteruniversity/nonvuln/op... ) makes the argument about the mouse hover tooltip, as if that is the only risk of an open redirect. This is much worse, this is a redirect after login. You just logged into google, you entered your 2FA code, and then the next site you arrive at you damn well expect to be google. Additionally, the OP is correct in that there is a whitelist bypass happening here. Why bother to whitelist *.google.com/ if you can bypass it with a redirect.
  - cbsmith 10y ago
    > then the next site you arrive at you damn well expect to be google. Actually, if it is an untrusted URL, I'm not sure why I'd expect that.
    - eadz 10y ago
      I think if google (verified with ssl cert etc) is asking for my password, there was a certain expectation there, but you're right, I should be less trusting ;) Here is the demonstration url from the report https://accounts.google.com/ServiceLogin?service=mail&continue=https://www.google.com/amp/yahoo.com#identifier https://accounts.google.com/ServiceLogin?service=mail&contin... My point isn't about 'open redirects' not being a security issue, it's that the report should be valid because it's a whitelist bypass. continue=yahoo.com is blocked but continue=https://www.google.com/amp/yahoo.com https://www.google.com/amp/yahoo.com is not blocked. both do the same thing as far as the end user is concerned.
sigjuice 10y ago
I guess this should not matter to someone like me who never logs on to google in a web browser? I just use gmail via IMAP.
- sigjuice 10y ago
  I guess I am wrong. Looks like I do have to go through some sort of Google login page when I set up my email for the first time https://imgur.com/a/Vlj09 https://imgur.com/a/Vlj09
  - niftich 10y ago
    This changed sometime in 2014. You used to be able to use IMAP authtype 'simple', but in April 2014, Google released a rather vague blog post [1] about how they're going to deprecate something; please move to OAuth 2.0. The Thunderbird team's bug tracker has some context [2] where they had to move quickly to add functionality to Thunderbird to support the SASL XOAUTH2 for IMAP so that Thunderbird would keep working with Gmail. [1] https://security.googleblog.com/2014/04/new-security-measures-will-affect-older.html https://security.googleblog.com/2014/04/new-security-measure... [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1059100 https://bugzilla.mozilla.org/show_bug.cgi?id=1059100
    - sigjuice 10y ago
      I also Gnus to read my email every once in a while and when I tried it last week, it complained Opening connection to imap.gmail.com via tls... Opening TLS connection to `imap.gmail.com'... Opening TLS connection with `gnutls-cli --insecure -p 993 imap.gmail.com'...done Opening TLS connection to `imap.gmail.com'...done nnimap (gmail) open error: 'NO (ALERT) Please log in via your web browser: https://support.google.com/mail/accounts/answer/78754 (Failure)'. Continue? (y or n) This used to work until a few months ago. It is also possible that something is missing on my computer. My computer was stolen recently and I haven't quite had the time to get to the bottom of this and several other similar things :/
      - 10y ago
cstrat 10y ago
The simple fix would be for google to show their own page after successfully logging in. On this page they would tell the user they are about to be forwarded to another page external to google.
- danielsamuels 10y ago
  That wouldn't solve this problem given that the page they're redirecting to _is_ a Google page, the continue check enforces that.
flashman 10y ago
Signing in on this page will download PuTTY, for example: https://accounts.google.com/ServiceLogin?service=mail&continue=https://www.google.com/amp/is.gd/CoBrwD https://accounts.google.com/ServiceLogin?service=mail&contin...
pwinnski 10y ago
Since Google has decided that https://www.google.com/amp/[any_domain_here] https://www.google.com/amp/[any_domain_here] isn't a vulnerability, then I don't see how combining that with a google login is a vulnerability. OP talks about having the continue page prompt for password, but how is that any different from creating a fake Google password prompt page now? That page would not be on https://accounts.google.com/ https://accounts.google.com/, and it would not have my personal info displayed, so why would I enter my password? Just because the last thing I did was log into Google? Is that supposed to "put me in the mood"? If I'm on page A, and I click a link that prompts me for my google credentials, I've either expected that, so I check to make sure it's Google, or I haven't, so I close that tab. If I enter my username and password, or just my password, and then end up at page B, and it prompts me for my password again, it certainly doesn't know my username like the real Google password prompt page did. It looks different, and raises all sorts of flags. Alternatively, if I'm on page A, and I click on a link that sends me to page B directly, where I'm prompted to enter my username and password, I don't. Why would I? It's not google.com, etc. There's just no way that this seems like any more of a vulnerability than the open redirector already is.
- flashman 10y ago
  I'm not sure I agree. There will be a percentage of users who would see the initial google.com page and not realise the subsequent page was an impostor, especially since Google 'took them there' after they logged in. This doesn't work on you because you have been primed to know what to expect - I reckon at least five percent of people phished this way would not be so observant, and Google should block off-site redirection after login.
- 2bitencryption 10y ago
  I'm on the sign-in page for Google. I check out the URL, it's google.com. The padlock is there. I sign in. Whoops, must have typed my password in wrong. It happens sometimes. So I type it in correctly. ...I just got phished. The problem is that the behavior of this exploit mimics almost EXACTLY the expected behavior. The warning flags to even an educated user are not clear at all. It would be so easy to fall for this.
mangeletti 10y ago
Steps: 1. Send email that looks like it's from AdWords, claiming the user's CC needs to be updated 2. User logs into Google after verifying URL is in fact google.com 3. Google literally sends trusting user to attack site... to enter their credit card number How is this not a serious vulnerability?
- dsacco 10y ago
  First of all, open redirection is not a serious vulnerability. Serious vulnerabilities include remote code execution, SQL injection and cross-slide scripting (depending on the context). Serious vulnerabilities can be used to compromise user accounts without their interaction. Vulnerability severity is always a bit of a touchy subject, but calling open redirection serious is either hyperbolic or report-padding for security consultants. Second, this vulnerability cannot be used to compromise user accounts or data, let alone with or without their interaction. It is a social engineering attack that could work, yes, but the Google Vulnerability Rewards Program is specifically designed to reward researchers for reporting technical security vulnerabilities, not those leveraged through social engineering. Third, this is a rabbit hole. Google's core functionality is redirecting users to third party websites. You can just as easily send someone a link to a Google redirector that occurs in the browser when you click on a search result. It's not feasible to prevent this, and it's not feasible to prevent social engineering in general. Bug bounty programs require a hard line somewhere in order to function. In order for an attack to be acceptable, it must have a clearly demonstrable foundation in a software implementation failure. It must be clearly defined as a logic error, not an error in human reasoning. The only cases where open redirection and social engineering are eligible are those where they are simply peripheral - an actual technical vulnerability that allows these attacks to scale far beyond manual means (an example might be a technical failure in Facebook's linkshim service). I am disappointed in seeing that this story has risen to the top of the HN front page, because I believe there isn't a single security engineer here that would agree this is a technical vulnerability that should be eligible for a reward.
  - mangeletti 10y ago
    > Serious vulnerabilities include remote code execution... I just meant "serious" in the general sense of the word, like the way that a bullet would in the stomach is serious, even though one in the head is more serious. > Google's core functionality is redirecting users to third party websites I'm pretty sure that Google's core functionality is ads, which don't require the user to actually be actually visiting pages Google. Pertaining using Google for social auth, the user is actually expecting to go back to the site they just came from, whereas when they login to update their credit card they're logging in to stay on Google, which means that a page that looks exactly like Google... How long this functionality remains on the site will be a better indicator. My guess is not long, esp after the publicity.
Manishearth 10y ago
Google seems to consider such issues about security UX being severely affected, where expectations are involved, to not be vulnerabilities. This is one of them. "theoretically", it is not a vulnerability, since the actual integrity of the security model is not compromised. However, the UX changes. A user who checks for the green lock in https urls may not check that a "wrong password" page reached via the google login page is on a different domain because they don't expect it to be. Given the existence of google oauth login, I do agree that this isn't really a good expectation, but I suspect that many folks have it (and it's easy to add "login successful, redirecting to <site>" for non-whitelisted endpoints). It's certainly something to improve upon, even if you don't give out a bounty or w/e. I reported a vulnerability of a similar kind months ago, which was similarly classified as not a vulnerability. When Chrome receives an invalid certificate which is invalid due to multiple reasons, it does not show all the reasons or prioritize. This means that if I have a self-signed certificate that also expired half an hour ago, chrome just tells me that it is an expired certificate. The integrity of the security model hasn't been affected here -- the warning is still shown, the user still has to manually click through. But the user may be much more likely to. Recently-expired certificates are relatively common, and seem like a reasonable thing to bypass. Of course, you should always check the cert details and cert tree before bypassing (unless you don't want to login or don't care about things being MITMd on that site), but not everyone understands the cert trees, and not everyone will do this. Of course, it's up to them to not consider security UX fails as vulnerabilities, and UX is pretty hard to get right anyway (Google has some awesome folks working on security ux though!).
- flukus 10y ago
  > A user who checks for the green lock in https urls may not check that a "wrong password" page reached via the google login page is on a different domain because they don't expect it to be. I wonder if you could use that new fangled css that changes the tab color to red, then the red unlocked icon looks like part of the error page styling.
  - Manishearth 10y ago
    That's a good idea. We'd need to apply it to all http:// http:// pages too for it to work though.
gyey 10y ago
I have noticed that a redirect to any site on sites.google.com also works seamlessly on mobile. The amp pages are not working for me and I get an error page, but as someone mentioned they probably don't work on mobile and only on desktop.
tamana 10y ago
The boilerplate FOAD email they send when they decide to end the conversation is dripping with smart. Exclamation points! Bummer!
grrowl 10y ago
It feels like you should phish one of the Google Security Team to really get the point home.
amq 10y ago
If any URL can be passed, and this is not a vulnerability, why validate the argument at all for google.com.*?
milankragujevic 10y ago
Couldn't they just sign the URL with a hash and call it a day? For example, have a parameter continue be "something" and hash be sha256("something"+someRandomStringThatOnlyGoogleKnows)... And on the server check if sha256(continue+random) == hash.
f- 10y ago
One important consideration here is that the phishing attack as described here could be pulled off even if the targeted site did not support redirects - and in general, it would be exploitable without any identifiable fault on the part of the "vulnerable" web app. This property is an artifact of how browsers work, and it's not something that's likely to change soon. Basically, if you visit evil.com, evil.com can always load accounts.some-trusted-domain.com in a new window, give you enough time to examine the address bar and confirm that it's legit - and then sneakily navigate that window to a phishy location that looks the same as our legit login prompt, but is controlled by the attacker. (The evil site can also detect certain events, such as navigation, and deliver the payload only at that point.) For my whimsical demo for Chrome and Firefox (dating back to 2011!), see: http://lcamtuf.coredump.cx/switch/ http://lcamtuf.coredump.cx/switch/ (Disclaimer: I kinda wrote a book about this stuff. Also, I work for Google.)
- bennofs 10y ago
  I agree that you cannot 100% prevent phishing, but I think that the case presented here is slightly different: the "evil URL" is only contained in a parameter to an request to another URL. I don't think that the typical users will look at the things that come after the `?` in the URL, especially since those can be url-encoded an thus just look like garbage.
  - deleted 10y ago
    [deleted]
- mangeletti 10y ago
  Couple notes: 1. You're talking about a pop-up / new tab that somebody clicked while already on an attack site... 2. then loading google.com in this pop-up / new tab and, waiting a few seconds, and then changing the location of the pop-up / new tab The vulnerability in question consists of landing up on google.com, logging in while still on google.com, then google.com sending you directly to an attack site after you finish logging in. The user could come from an official looking email (a known and largely unavoidable problem), or from a link that somebody pasted (e.g. "click here to view my spreadsheet on Google Sheets") into a comment on a different trusted site. The "trusted site" is important to note, because as you might have deduced, no scripts or malicious intent is required on the part of the other site; just a link. In your example, the other site would have to either A) be compromised itself, to facilitate the script, or B) malicious itself. Which of the workflows would you be more likely to fall for, your example or mine?
TomAnthony 10y ago
This has been this way for several years now. I have notes on a Google attack I discovered ~2 years ago that includes an open redirect as a critical part. It allows running arbitrary JS on authenticated users on the click of a link. However, there is one small part of the attack (one character!) which prevents it working so I've never reported it. Interesting that there is such a debate here, as I thought open redirects were generally accepted as out of scope for most bug bounties.
- kuschku 10y ago
  Well, maybe there should be social engineering bounties then. For things like this, or when you can engineer their support to gove you access to their systems.

325 points by ivank 10y ago

A non-vulnerability like this is a good example of how easy it is to get press for $important_company + security. Top of hackernews at the moment and fingers crossed there wont be a wave of articles about this in the coming days from tech press who don't fully understand the issue but know clicks when they see them.

ejcx 10y ago
Not only to GET press, but also to PRESS the company for $. This is a huge problem I see with bugbounties. People running the bug bounties, who are not appsec security literate, are basically bullied in to thinking that something is a security risk when it is not quite often. I deal with people trying to do this 10-15 times per week. I can totally see how people get pushed in to paying thousands for essentially worthless bugs.
mixedCase 10y ago
A non-vulnerability? I understand how you could call it non-serious if you don't work on user-oriented code or think all users have perfect periferic vision all the time. But how do you explain the purpose for the check that fails any non-google domain then?

PuffinBlue 10y ago

I can appreciate their stance on phishing but being able to automatically execute an arbitrary file download that appears to come from Google as part of the login process strikes me as a bad thing, no?

rezashirazian 10y ago
It is. It also seems like an easy fix, I'm surprised why this hasn't been done yet.
- quickben 10y ago
  Probably corporate inertia and big testing/deployment pipeline, etc.
- innoying 10y ago
  It's not an "easy fix", there could be (and probably are) thousands of different endpoints that can be redirected to after login, whitelisting all of those just doesn't make sense.
  - rezashirazian 10y ago
    That sounds tedious, not necessarily difficult. I wonder if there is a technical challenge that goes beyond the tedious work of going through possible redirects and whitelisting them
cbsmith 10y ago
To get that exploit you'd need to send a faulty URL and get the user to follow it. You could just as easily do that with a faulty URL and no Google login. The only risk is if the redirect can access your login session/credentials. If it can't, no exploit.
- _asummers 10y ago
  The Google login wraps the whole flow in a trojan horse, though. Users are taught to trust the single sign ons from FB/Google, and they're also taught to check the URL. Both of those would be false senses of security in this case. In isolation, this isn't necessarily a security vulnerability. But that it breaks down when users do what they're supposed to do? That's bad.
  - cbsmith 10y ago
    The logo and the host portion of the URL are ensuring that my credentials are going to Google, and not anyone else. The rest of the URL is telling me I shouldn't trust where I'm going. ;-)
im4w1l 10y ago
> automatically execute an arbitrary file download Your phrasing could easily be misread. A downloaded program would not automatically run.
- euyyn 10y ago
  And in modern browsers/OS not even after you click on them, until you clear a "yes, I know this is risky" dialog.
- PuffinBlue 10y ago
  Replace execute with 'initiate'?

cyberferret 10y ago

That is quite an incredible security flaw. I also appreciate the irony of using a Google service to exploit Google's login itself. It's akin to that scene in "Terminator 2" when the T-800 walks into a gun shop, asks to see all the top shelf guns, then loads up and shoots the shop owner before walking out...

zachrose 10y ago
That was Terminator 1 though.
- ikeboy 10y ago
  Was it really Terminator 1 before any other films came out, though?
  - zachrose 10y ago
    No but it became Terminator 1 retroactively, much in the same way that Kyle Reese retroactively become John Connor's father.
- caleblloyd 10y ago
  Clerk: "You can't do that" Arnie: "Wrong" https://m.youtube.com/watch?v=TsMAhHtHroE https://m.youtube.com/watch?v=TsMAhHtHroE

belovedeagle 10y ago

Frankly, I don't see any reason why Google isn't right here. This "vulnerability" can only be exploited by appending another one, fishing. It's reasonable to say, "If AB is a vulnerability only if B is a vulnerability, then A is not a vulnerability". That you can't solve fishing [as a service owner, without also owning the browser] is unfortunate but irrelevant.

eadz 10y ago
I disagree. The linked google page ( https://sites.google.com/site/bughunteruniversity/nonvuln/open-redirect https://sites.google.com/site/bughunteruniversity/nonvuln/op... ) makes the argument about the mouse hover tooltip, as if that is the only risk of an open redirect. This is much worse, this is a redirect after login. You just logged into google, you entered your 2FA code, and then the next site you arrive at you damn well expect to be google. Additionally, the OP is correct in that there is a whitelist bypass happening here. Why bother to whitelist *.google.com/ if you can bypass it with a redirect.
- cbsmith 10y ago
  > then the next site you arrive at you damn well expect to be google. Actually, if it is an untrusted URL, I'm not sure why I'd expect that.
  - eadz 10y ago
    I think if google (verified with ssl cert etc) is asking for my password, there was a certain expectation there, but you're right, I should be less trusting ;) Here is the demonstration url from the report https://accounts.google.com/ServiceLogin?service=mail&continue=https://www.google.com/amp/yahoo.com#identifier https://accounts.google.com/ServiceLogin?service=mail&contin... My point isn't about 'open redirects' not being a security issue, it's that the report should be valid because it's a whitelist bypass. continue=yahoo.com is blocked but continue=https://www.google.com/amp/yahoo.com https://www.google.com/amp/yahoo.com is not blocked. both do the same thing as far as the end user is concerned.

sigjuice 10y ago

I guess this should not matter to someone like me who never logs on to google in a web browser? I just use gmail via IMAP.

sigjuice 10y ago
I guess I am wrong. Looks like I do have to go through some sort of Google login page when I set up my email for the first time https://imgur.com/a/Vlj09 https://imgur.com/a/Vlj09
- niftich 10y ago
  This changed sometime in 2014. You used to be able to use IMAP authtype 'simple', but in April 2014, Google released a rather vague blog post [1] about how they're going to deprecate something; please move to OAuth 2.0. The Thunderbird team's bug tracker has some context [2] where they had to move quickly to add functionality to Thunderbird to support the SASL XOAUTH2 for IMAP so that Thunderbird would keep working with Gmail. [1] https://security.googleblog.com/2014/04/new-security-measures-will-affect-older.html https://security.googleblog.com/2014/04/new-security-measure... [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1059100 https://bugzilla.mozilla.org/show_bug.cgi?id=1059100
  - sigjuice 10y ago
    I also Gnus to read my email every once in a while and when I tried it last week, it complained Opening connection to imap.gmail.com via tls... Opening TLS connection to `imap.gmail.com'... Opening TLS connection with `gnutls-cli --insecure -p 993 imap.gmail.com'...done Opening TLS connection to `imap.gmail.com'...done nnimap (gmail) open error: 'NO (ALERT) Please log in via your web browser: https://support.google.com/mail/accounts/answer/78754 (Failure)'. Continue? (y or n) This used to work until a few months ago. It is also possible that something is missing on my computer. My computer was stolen recently and I haven't quite had the time to get to the bottom of this and several other similar things :/
    - 10y ago

cstrat 10y ago

The simple fix would be for google to show their own page after successfully logging in. On this page they would tell the user they are about to be forwarded to another page external to google.

danielsamuels 10y ago
That wouldn't solve this problem given that the page they're redirecting to _is_ a Google page, the continue check enforces that.

flashman 10y ago

Signing in on this page will download PuTTY, for example: https://accounts.google.com/ServiceLogin?service=mail&continue=https://www.google.com/amp/is.gd/CoBrwD https://accounts.google.com/ServiceLogin?service=mail&contin...

pwinnski 10y ago

Since Google has decided that https://www.google.com/amp/[any_domain_here] https://www.google.com/amp/[any_domain_here] isn't a vulnerability, then I don't see how combining that with a google login is a vulnerability. OP talks about having the continue page prompt for password, but how is that any different from creating a fake Google password prompt page now? That page would not be on https://accounts.google.com/ https://accounts.google.com/, and it would not have my personal info displayed, so why would I enter my password? Just because the last thing I did was log into Google? Is that supposed to "put me in the mood"? If I'm on page A, and I click a link that prompts me for my google credentials, I've either expected that, so I check to make sure it's Google, or I haven't, so I close that tab. If I enter my username and password, or just my password, and then end up at page B, and it prompts me for my password again, it certainly doesn't know my username like the real Google password prompt page did. It looks different, and raises all sorts of flags. Alternatively, if I'm on page A, and I click on a link that sends me to page B directly, where I'm prompted to enter my username and password, I don't. Why would I? It's not google.com, etc. There's just no way that this seems like any more of a vulnerability than the open redirector already is.

flashman 10y ago
I'm not sure I agree. There will be a percentage of users who would see the initial google.com page and not realise the subsequent page was an impostor, especially since Google 'took them there' after they logged in. This doesn't work on you because you have been primed to know what to expect - I reckon at least five percent of people phished this way would not be so observant, and Google should block off-site redirection after login.
2bitencryption 10y ago
I'm on the sign-in page for Google. I check out the URL, it's google.com. The padlock is there. I sign in. Whoops, must have typed my password in wrong. It happens sometimes. So I type it in correctly. ...I just got phished. The problem is that the behavior of this exploit mimics almost EXACTLY the expected behavior. The warning flags to even an educated user are not clear at all. It would be so easy to fall for this.

mangeletti 10y ago

Steps: 1. Send email that looks like it's from AdWords, claiming the user's CC needs to be updated 2. User logs into Google after verifying URL is in fact google.com 3. Google literally sends trusting user to attack site... to enter their credit card number How is this not a serious vulnerability?

dsacco 10y ago
First of all, open redirection is not a serious vulnerability. Serious vulnerabilities include remote code execution, SQL injection and cross-slide scripting (depending on the context). Serious vulnerabilities can be used to compromise user accounts without their interaction. Vulnerability severity is always a bit of a touchy subject, but calling open redirection serious is either hyperbolic or report-padding for security consultants. Second, this vulnerability cannot be used to compromise user accounts or data, let alone with or without their interaction. It is a social engineering attack that could work, yes, but the Google Vulnerability Rewards Program is specifically designed to reward researchers for reporting technical security vulnerabilities, not those leveraged through social engineering. Third, this is a rabbit hole. Google's core functionality is redirecting users to third party websites. You can just as easily send someone a link to a Google redirector that occurs in the browser when you click on a search result. It's not feasible to prevent this, and it's not feasible to prevent social engineering in general. Bug bounty programs require a hard line somewhere in order to function. In order for an attack to be acceptable, it must have a clearly demonstrable foundation in a software implementation failure. It must be clearly defined as a logic error, not an error in human reasoning. The only cases where open redirection and social engineering are eligible are those where they are simply peripheral - an actual technical vulnerability that allows these attacks to scale far beyond manual means (an example might be a technical failure in Facebook's linkshim service). I am disappointed in seeing that this story has risen to the top of the HN front page, because I believe there isn't a single security engineer here that would agree this is a technical vulnerability that should be eligible for a reward.
- mangeletti 10y ago
  > Serious vulnerabilities include remote code execution... I just meant "serious" in the general sense of the word, like the way that a bullet would in the stomach is serious, even though one in the head is more serious. > Google's core functionality is redirecting users to third party websites I'm pretty sure that Google's core functionality is ads, which don't require the user to actually be actually visiting pages Google. Pertaining using Google for social auth, the user is actually expecting to go back to the site they just came from, whereas when they login to update their credit card they're logging in to stay on Google, which means that a page that looks exactly like Google... How long this functionality remains on the site will be a better indicator. My guess is not long, esp after the publicity.

Manishearth 10y ago

Google seems to consider such issues about security UX being severely affected, where expectations are involved, to not be vulnerabilities. This is one of them. "theoretically", it is not a vulnerability, since the actual integrity of the security model is not compromised. However, the UX changes. A user who checks for the green lock in https urls may not check that a "wrong password" page reached via the google login page is on a different domain because they don't expect it to be. Given the existence of google oauth login, I do agree that this isn't really a good expectation, but I suspect that many folks have it (and it's easy to add "login successful, redirecting to <site>" for non-whitelisted endpoints). It's certainly something to improve upon, even if you don't give out a bounty or w/e. I reported a vulnerability of a similar kind months ago, which was similarly classified as not a vulnerability. When Chrome receives an invalid certificate which is invalid due to multiple reasons, it does not show all the reasons or prioritize. This means that if I have a self-signed certificate that also expired half an hour ago, chrome just tells me that it is an expired certificate. The integrity of the security model hasn't been affected here -- the warning is still shown, the user still has to manually click through. But the user may be much more likely to. Recently-expired certificates are relatively common, and seem like a reasonable thing to bypass. Of course, you should always check the cert details and cert tree before bypassing (unless you don't want to login or don't care about things being MITMd on that site), but not everyone understands the cert trees, and not everyone will do this. Of course, it's up to them to not consider security UX fails as vulnerabilities, and UX is pretty hard to get right anyway (Google has some awesome folks working on security ux though!).

flukus 10y ago
> A user who checks for the green lock in https urls may not check that a "wrong password" page reached via the google login page is on a different domain because they don't expect it to be. I wonder if you could use that new fangled css that changes the tab color to red, then the red unlocked icon looks like part of the error page styling.
- Manishearth 10y ago
  That's a good idea. We'd need to apply it to all http:// http:// pages too for it to work though.

gyey 10y ago

I have noticed that a redirect to any site on sites.google.com also works seamlessly on mobile. The amp pages are not working for me and I get an error page, but as someone mentioned they probably don't work on mobile and only on desktop.

tamana 10y ago

The boilerplate FOAD email they send when they decide to end the conversation is dripping with smart. Exclamation points! Bummer!

grrowl 10y ago

It feels like you should phish one of the Google Security Team to really get the point home.

amq 10y ago

If any URL can be passed, and this is not a vulnerability, why validate the argument at all for google.com.*?

milankragujevic 10y ago

Couldn't they just sign the URL with a hash and call it a day? For example, have a parameter continue be "something" and hash be sha256("something"+someRandomStringThatOnlyGoogleKnows)... And on the server check if sha256(continue+random) == hash.

f- 10y ago

One important consideration here is that the phishing attack as described here could be pulled off even if the targeted site did not support redirects - and in general, it would be exploitable without any identifiable fault on the part of the "vulnerable" web app. This property is an artifact of how browsers work, and it's not something that's likely to change soon. Basically, if you visit evil.com, evil.com can always load accounts.some-trusted-domain.com in a new window, give you enough time to examine the address bar and confirm that it's legit - and then sneakily navigate that window to a phishy location that looks the same as our legit login prompt, but is controlled by the attacker. (The evil site can also detect certain events, such as navigation, and deliver the payload only at that point.) For my whimsical demo for Chrome and Firefox (dating back to 2011!), see: http://lcamtuf.coredump.cx/switch/ http://lcamtuf.coredump.cx/switch/ (Disclaimer: I kinda wrote a book about this stuff. Also, I work for Google.)

bennofs 10y ago
I agree that you cannot 100% prevent phishing, but I think that the case presented here is slightly different: the "evil URL" is only contained in a parameter to an request to another URL. I don't think that the typical users will look at the things that come after the `?` in the URL, especially since those can be url-encoded an thus just look like garbage.
- deleted 10y ago
  [deleted]
mangeletti 10y ago
Couple notes: 1. You're talking about a pop-up / new tab that somebody clicked while already on an attack site... 2. then loading google.com in this pop-up / new tab and, waiting a few seconds, and then changing the location of the pop-up / new tab The vulnerability in question consists of landing up on google.com, logging in while still on google.com, then google.com sending you directly to an attack site after you finish logging in. The user could come from an official looking email (a known and largely unavoidable problem), or from a link that somebody pasted (e.g. "click here to view my spreadsheet on Google Sheets") into a comment on a different trusted site. The "trusted site" is important to note, because as you might have deduced, no scripts or malicious intent is required on the part of the other site; just a link. In your example, the other site would have to either A) be compromised itself, to facilitate the script, or B) malicious itself. Which of the workflows would you be more likely to fall for, your example or mine?

TomAnthony 10y ago

This has been this way for several years now. I have notes on a Google attack I discovered ~2 years ago that includes an open redirect as a critical part. It allows running arbitrary JS on authenticated users on the click of a link. However, there is one small part of the attack (one character!) which prevents it working so I've never reported it. Interesting that there is such a debate here, as I thought open redirects were generally accepted as out of scope for most bug bounties.

kuschku 10y ago
Well, maybe there should be social engineering bounties then. For things like this, or when you can engineer their support to gove you access to their systems.