- 50comments
- 133comments
- 28comments
- 64comments
- 56comments
- 5comments
- 43comments
- —discuss
- 151comments
- 618comments
- —discuss
- 301comments
- 44comments
- 26comments
- 246comments
- 96comments
- 173comments
- 78comments
- 10comments
- 238comments
- 51comments
- 142comments
- —discuss
- 163comments
- 18comments
- 27comments
- 70comments
- 29comments
- 47comments
- —discuss
EDIT: should have finished reading the article!
The name doesn't matter if you keep reading.
Spoiler, because clickbait headlines are disingenuous and annoying:
Would like to know your results if you submitted this to the bug bounty program. Maybe put that at the top?
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.
Is it a bug?
Arguably, everything here is working as intended.
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.
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
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.
This is a poor rebuttal.
Maybe honest ones, however there is no reason a dishonest app that is trying to steal your Google account should stick to best practices.
You have ignored the part about bypassing Google's IP and location based fraud detection. Your idea wouldn't work.
What do you suggest? Lock down allowed webview like iOS, killing actual browsers?
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.
This is why we need U2F.
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.
All this blog post does is highlight why you shouldn't trust WebViews.
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.
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?
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/
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.