Hacker News Reader

Comment by belovedeagle | Hacker News Reader

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.

View on HN

I disagree. The linked google page ( 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.

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

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&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 is not blocked.

both do the same thing as far as the end user is concerned.

continue=https://www.google.com/amp/yahoo.com is taking me to a Google error page that says yahoo.com is invalid amp code.

Weird, it worked perfectly for me just now.

I am being redirected to a page that will let me change my google account recovery options.

My guess is that posting this thing on HN has caused them to fix it.

OR maybe I'm being phished.

the /amp/ hack only works for desktop and not mobile. I was on mobile and that's why I got the Google error page.

> at you damn well expect to be google.

That's not really true though. Google serves as an identity provider providing login into 3rd party websites. Plus there's also OAuth prompts when 3rd party services want to use your Google data.

> at you damn well expect to be google.

If it's again asking for a password, it must be Google.

No, that's not true. Think of every time you click on a "sign in with Google" link. If you're not signed in, it will take you to this login page. The redirect will only send back a token, and only for that site.

I totally agree. I don't even see how the impact is even more than the open-redirects which already exist. You could do this exact same exploit against tons of providers (Facebook, Twitter, etc) via the standard OAuth flow and the 'redirect_url' parameter.

Because I go to a page, check the green padlock and all that noise, it's all legit, enter my credentials, oops I typed them in wrong, try again, right now I'm logged in properly... I would say I am dramatically less likely to exercise as much caution on the "Ooops wrong credentials" page having checked the original one.

Perhaps it's just safer to use a password manager for everything.

Somewhere, Tavis Ormandy is cringing.

Does he have a statement regarding password managers?

He's been finding bugs galore in them recently.

https://mobile.twitter.com/taviso/status/769391927892598784

Edit: this one is better

https://mobile.twitter.com/taviso/status/769378052254015488

I'm the type of person who can't fathom actually falling for a phishing attack. As a tech-savvy software developer, it is extremely unlikely I will ever be successfully attacked via a phishing email, text message, blog/forum link, etc. If the initial link I follow could possibly be questionable, I look at the domain before logging in. I must be part of much less than 10% of the population that is at least that informed and vigilant.

I hadn't considered login redirects. This attack vector is one I can see myself falling for. Sign in on the legitimate google.com domain. Whoops, I just mistyped my Google password - not a rare occurrence. An exact replica of the "incorrect password" page has me type in my password again. Then they have a replica of the two-step authentication screen. I enter in the valid TOTP code, and now I've just given a third-party full access to my Google account.

This should absolutely be considered a serious threat. Hell, the only thing we freaking teach non-tech-savvy people to do is to look at the domain name. This attack vector completely bypasses that common understanding of how to detect phishing. There is absolutely no way I should land on a 3rd party domain after authenticating, without at least an interstitial page informing me I am heading off of Google's properties. Any redirect chain specifically from login should require landing on a Google domain, or have an interstitial. This doesn't need to be done globally for all redirects - just from login.

Oh well, I learned something new today. Re-check the domain you are on every time you type in credentials. You can't rely on your initial entry page being on the right domain, you have to be paranoid to the point of insanity every time you touch your keyboard.

And the best part is you don't know it happened because after you've filled in the fake page, they redirect you again to a Google page you did need to be signed in for, and you're now logged in (from the first page).

If people ever send you Google Docs links, you're likely vulnerable unless you are as vigilant on the "Wrong Password" page as you were on the initial one.

It's worst than that. Below (or somewhere in this thread) you'll find some example posted by kuschku: you don't land in someone else domain, you're still in the Google domain, you'll just find out that you're viewing someone's else page if you see the full URL.

If you're that confident that you have either already been phished or haven't had someone try. It happens, you make a mistake, you click too fast. A little humility goes a long way.

> "If AB is a vulnerability only if B is a vulnerability, then A is not a vulnerability"

Stringing together multiple (seemingly) insignificant vulnerabilities to pivot through a system or own a user is hacking 101. I'm not sure how you'd fix this, but given Google's prevalence as an authentication provider, it's definitely not worth being glib about.

Try this variant:

(link removed, see video below)

And tell me your parents/grandparents/etc will not mistake that for the real thing.

(you can enter whatever you want into the phishing form, it will just take you back to this post – but someone with less morals could do entirely different things)

EDIT: Video for mobile users (this page doesn’t work on mobile): https://cdn.kuschku.de/ServiceLogin/video.mp4

Perfect example. Everything that I can see in my cell looks right, including informations from the green padlock, just opening (and understanding! ) the whole URL would make one NOT enter the password.

And that’s the thing, thanks to Let’s Encrypt, the padlock on the fake site also stays, everything looks normal.

If you now also register something like accountsgoogle.com or a similar page, people likely wouldn’t even notice.

This is like it’s made for phishing.

This is what I get: "Sorry, this page is not valid AMP HTML"

Do you happen to be on mobile? This particular site only works on desktop, at the moment. I’ll do a screenrecording for you mobile users in a moment.

https://cdn.kuschku.de/ServiceLogin/video.mp4

Yes, I'm on mobile. That must be it.

The sexism is really out of line.

Well, it wasn’t intentional (and I’m female myself anyway), but [long family story omitted] I edited it out.

Ironically, Chrome is now blocking that as a phishing site!

Yes, and now I have to deal with Google to unblock it.

One of the reasons why I hate automated systems judging things.

Thanks, Google...

Please tell me this is sarcasm. The system is working...

The system would be working if it was an actual phishing page.

If it is an example, which is non-malicious, and even says "Don’t enter your password", and doesn’t even store the data from the input fields, it’s not.

It could easily check if any JS is executed, or if the form fields ever get sent anywhere (both is not the case).

The only bit you're missing here is redirecting the user back to a Google page you do need to be logged in for, so they think everything is ok and don't think twice about what just happened

I was hoping I could avoid getting flagged as phishing site if I'd make the form ignore all content and redirect back here.

Turns out I was wrong.

Temporary: please take the page back, it worked for me... Keep the video for those who can't.

I can’t, it’s hard already to get rid of the phishing flag Google has set for the domain.

Agreed. Open redirect aside, this is simply social engineering; someone convinces the victim to navigate to a crafted URL hoping for some eventual exfiltration of credentials. This kind of issue is a good demonstration that it's not (just) the payload of the URL that's important -- in this case the deception may be more difficult to spot -- but also who's asking to go there and why.

That's a weak excuse for this horrible security hole.

Google is facilitating phishing with this terrible behavior. It means that someone trying to phish a Google user can send someone to a totally valid google.com URL and it will still result in their credentials being stolen. That's the #1 thing that you teach non-technical people to avoid phishing; "Make sure the site you're on is the one you think you're logging into."

Because Google has chosen to be sloppy and dumb that simple instruction is not enough to protect people.

Google is 100% wrong here. This is a blatant hole and just a lazy, sloppy stupid, way too broad whitelist.

Agreed, and not trying to be pedantic, but it might be more accurate to say: "If AB is a vulnerability only if B is present, then A is not a vulnerability".

Reply on news.ycombinator.com