Anyway the incident shook me as they also gave me my personal information to prove they are real and it was accurate and kept saying look we aren’t asking you for information we are telling you yours so you see we are Google Security!
It has triggered for me a giant project to carefully review all my attack surfaces across all accounts and systems.
Someone can register example.com with google workspace and then they can use "login with google" to log in to your [email protected] account at greatonlinegame.com, even though your account did not use "login with google".
Did i get it right?
And if i did, i wonder...
Why aren't these logins separate on greatonlinegame.com? If I did it i'd allow a login only by the method that was used to create the account, unless the user configures it otherwise.
That means that, even if you don't want anything to do with Google at all, others could have impersonated you by registering a Google Workspace trial account on your email address, "verifying" their account through this vulnerability, and logging in to third-party sites (that support Google login) by using your email address.
Is there a best practice around confirming adding social login to a pre-existing account? (Like entering current password or email confirmation?)
From the article:
> In the case of the reader who shared the breach notice from Google, the imposters used the authentication bypass to associate his domain with a Workspace account. And that domain was tied to his login at several third-party services online. Indeed, the alert this reader received from Google said the unauthorized Workspace account appears to have been used to sign in to his account at Dropbox
Fun fact, Google doesn't allow you to contact support if you are locked out. It also doesn't allow you to post for help on their community forums.
I guess Google gets to decide if I am allowed to use email. My employer apparently doesn't get a say in the matter.
I was able to login to Gmail with [email protected] and send emails. Emails were however being received only on the outlook.com account. Blew my mind.
There doesn't appear to be a way to tell Google, "I own this domain, just block all of these bogus requests" other than signing up for the services in question (which I don't want to do!)
Scammers will be scammers, but this is also pretty shitty behavior on Google's part.
Is this like the PayPal XSRF vulnerability where any issued XSRF token was considered valid regardless of the user trying to use it?
I’d expect Google to have some standard way to handle this stuff.
I used to use these “social logins” exclusively. Whether they were FB, Apple, or Google. Because big tech couldn’t get hacked and it was convenient.
But quickly realized how much of a pain it was to deal with when issues at various service providers arose. It complicated operations for small businesses. Often I lost accounts because their support just gave up on trying to diagnose issue.
But also if those IdPs deemed your account in violation of some vague policy, or maybe they just don’t like you because of “freeloading”. Then you will quickly lose out on access to numerous services.
Some services have sane account management practices and allow you to dissociate the account from a SSO provider. But most I have encountered are just clueless. Some services, the system is designed so bad that I cannot change the email.
I remember l1 support for some company stating emails are immutable because it’s more secure that way. Such bullshit.
this bypass event is yet another reason to avoid using Google/Apple/Facebook as SSO provider. These companies have time and time again proved they are pregnable.
Fortunately, thanks to password managers it makes creating complicated passwords with hundreds of services much easier.
To add, the welcome email doesn't directly say the domain used
I don't have Google workspace for this domain and use an alternate email provider. I was curious so tried to signin and was told that the admin account was an email on my domain (eg [email protected]). Ok, created that account so I could receive email, except then Google said that I had to use the backup recovery email which happened to be [email protected].
Google said that non verified workspaces (eg not verified through txt or cname records) would be automatically deleted after 7 days.
14 days later the workspace was still there.
I had to go through a convoluted manual form and process to get my workspace domain back and then properly register it so this would not happen again.
I provided the following feedback which seems like common sense, but I guess it ain't that common:
1) you shouldn't be able to create a workspace with a custom domain without verifying it via DNS records from the start. No 7 day grace which actually was broken and for all I know was infinite grace period.
2) the established admin account with a custom domain email address should be eligible to perform recovery. Not some arbitrary secondary Gmail account.