4 ms·

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

81 points by ethanblake4 6y ago

pmx 6y ago
EDIT: should have finished reading the article!
- kace91 6y ago
  The name doesn't matter if you keep reading.
tidepod12 6y 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).
oogetyboogety 6y ago
Would like to know your results if you submitted this to the bug bounty program. Maybe put that at the top?
- asdfasgasdgasdg 6y 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.
- md_ 6y ago
  Is it a bug? Arguably, everything here is working as intended.
- ffpip 6y 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.
judge2020 6y 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-middle/ https://9to5google.com/2019/04/18/google-block-man-in-the-mi... 1: https://news.ycombinator.com/item?id=25155451 https://news.ycombinator.com/item?id=25155451
throw14082020 6y 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 6y 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 6y ago
  What do you suggest? Lock down allowed webview like iOS, killing actual browsers?
dustinmoris 6y 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.
NovemberWhiskey 6y ago
This is why we need U2F.
- gumby 6y 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.
deleted 6y ago
[deleted]
throw14082020 6y ago
All this blog post does is highlight why you shouldn't trust WebViews.
hausen 6y 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.
superasn 6y 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 6y 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.Platform%3DDesktop&hl=en#6396505:~:text=With%20a%20passphrase%2C%20you%20can%20use,data%20without%20letting%20Google%20read%20it https://support.google.com/chrome/answer/165139?co=GENIE.Pla.... 1: https://www.section.io/engineering-education/encrypting-gdrive-using-rclone/ https://www.section.io/engineering-education/encrypting-gdri... 2: https://cryptomator.org/ https://cryptomator.org/
  - ethanblake4 6y ago
    I only had to click 'allow device' because I had 2FA enabled on that account. For anyone who doesn't, that step is not required.

81 points by ethanblake4 6y ago

pmx 6y ago

EDIT: should have finished reading the article!

kace91 6y ago
The name doesn't matter if you keep reading.

tidepod12 6y 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).

oogetyboogety 6y ago

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

asdfasgasdgasdg 6y 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.
md_ 6y ago
Is it a bug? Arguably, everything here is working as intended.
ffpip 6y 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.

judge2020 6y 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-middle/ https://9to5google.com/2019/04/18/google-block-man-in-the-mi... 1: https://news.ycombinator.com/item?id=25155451 https://news.ycombinator.com/item?id=25155451

throw14082020 6y 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 6y 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 6y ago
What do you suggest? Lock down allowed webview like iOS, killing actual browsers?

dustinmoris 6y 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.

NovemberWhiskey 6y ago

This is why we need U2F.

gumby 6y 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.

deleted 6y ago

[deleted]

throw14082020 6y ago

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

hausen 6y 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.

superasn 6y 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 6y 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.Platform%3DDesktop&hl=en#6396505:~:text=With%20a%20passphrase%2C%20you%20can%20use,data%20without%20letting%20Google%20read%20it https://support.google.com/chrome/answer/165139?co=GENIE.Pla.... 1: https://www.section.io/engineering-education/encrypting-gdrive-using-rclone/ https://www.section.io/engineering-education/encrypting-gdri... 2: https://cryptomator.org/ https://cryptomator.org/
- ethanblake4 6y ago
  I only had to click 'allow device' because I had 2FA enabled on that account. For anyone who doesn't, that step is not required.