top | item 25717156

I stole the data in millions of people’s Google accounts

81 points| ethanblake4 | 5 years ago |ethanblake4.medium.com

19 comments

order

tidepod12|5 years ago

Spoiler, because clickbait headlines are disingenuous and annoying:

> As many of you may have suspected, this post is not entirely truthful. I have not released this fitness app onto the Play Store, nor have I collected millions of master tokens. ... But yes, these methods do work. I absolutely could release such an app, and so could anyone else (and maybe they have).

judge2020|5 years ago

The meat of this story is that, instead of showing the Google oauth flow which would say “sign in to continue to <app>” with the list of permissions shown to the user, he embedded a web view that is actually a URL for setting up a new android device. This is exactly the reason Google is doing things like restricting embedded browser sign-ins[0], which HN was particularly critical about[1].

0: https://9to5google.com/2019/04/18/google-block-man-in-the-mi...

1: https://news.ycombinator.com/item?id=25155451

throw14082020|5 years ago

This isn't even a vulnerability. Mobile applications should be using the system browser, not a WebView. This blog post is proud of abusing the users trust. I can also make an application which opens an OAuth page to a fake-google.com which looks exactly like Google. I guess you can still trick Grannies with his app.

Finally the author admits... > Nothing I did would technically be considered an ‘exploit’

and of course, admits he lied about the title and multiple sentences in his blog... > As many of you may have suspected, this post is not entirely truthful.

Poor form.

ubercow13|5 years ago

This is a poor rebuttal.

>Mobile applications should be using the system browser, not a WebView

Maybe honest ones, however there is no reason a dishonest app that is trying to steal your Google account should stick to best practices.

>I can also make an application which opens an OAuth page to a fake-google.com which looks exactly like Google

You have ignored the part about bypassing Google's IP and location based fraud detection. Your idea wouldn't work.

the_gipsy|5 years ago

What do you suggest? Lock down allowed webview like iOS, killing actual browsers?

hausen|5 years ago

The title isn't truthful to the content. @dang, can you please change it? Should be something along the lines of "how to steal data from Google accounts." As the author states waaay down in the article, they didn't actually do it, they're merely showing how.

dustinmoris|5 years ago

Great article and very clever. Luckily I never use SSO providers to log anywhere precisely because of issues like this. Since Safari remembers all my accounts anyway I have little reason to use Google or something else to log myself everywhere in.

superasn|5 years ago

Even though the post is a bit clickbaity there is still one thing I learned from it and if somebody cyber security expert can confirm this:

- there exists a powerful token (like a master key) using which a person can read all my emails, drive, etc bypassing the email alert and unknown device check?

judge2020|5 years ago

If you mean the one that's used on your phone to access everything, yes, although it doesn't bypass the email alert (the linked clickbait goes into how they have to click "allow device" on their already-signed-in phone). When you log into either the Google.com website or into an Android device your token needs permission to do everything you'd expect to do as a user - gmail, drive, etc. This attack is basically a browser MITM which captures that token and (theoretically) ships it off to a server for malicious usage/storage.

Or, if you mean "can Google employees read my email", then they can since almost no Google service is end-to-end encrypted (although you can e2ee Chrome sync[0]). Gmail, Drive, and Docs are completely unencrypted unless you use encryption on top of it (like with rclone[1] or cryptomator[2]).

0: https://support.google.com/chrome/answer/165139?co=GENIE.Pla....

1: https://www.section.io/engineering-education/encrypting-gdri...

2: https://cryptomator.org/

oogetyboogety|5 years ago

Would like to know your results if you submitted this to the bug bounty program. Maybe put that at the top?

asdfasgasdgasdg|5 years ago

This type of attack is already known, so it wouldn't be eligible for any kind of bounty. It is why Google is switching to disallowing auth from embedded browsers, and only allowing known-good + standards-compliant browsers to do auth instead.

ffpip|5 years ago

These type of attacks are already known and out of scope for the bounty.

Users giving their password on random popups asking for it is not something google can control.

md_|5 years ago

Is it a bug?

Arguably, everything here is working as intended.

throw14082020|5 years ago

All this blog post does is highlight why you shouldn't trust WebViews.

NovemberWhiskey|5 years ago

This is why we need U2F.

gumby|5 years ago

What's clever here is that it hijacks a full, legitimate login (including asking for the second factor, using proper IP addresses et al) then gains the full access token.

Doesn't matter what security the user has added: if they are willing to type their credentials into a web view they lose their trust.

pmx|5 years ago

EDIT: should have finished reading the article!

kace91|5 years ago

The name doesn't matter if you keep reading.