"hackers/cybercriminals"
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.
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.
Surely they could add support for checking that TXT record to "anti-verify" the domain? Ie instead of the "MS=ms12345" value to verify with Microsoft, have some fixed "MS=NOJOY" or whatever to signal to Microsoft you don't want any registrations against your domain.
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
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 foo@mydomain.com). 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 mydomain@gmail.com.
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.
I was able to login to Gmail with myname@hotmail.com and send emails. Emails were however being received only on the outlook.com account. Blew my mind.
Best I could do was run reports and yell at people. But it really would have been nice to stop all attempts to make google accounts for the domain.
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.
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.
Yeah, anytime someone gives me information about me, to prove who they are, is instantly suspect. Same goes for not yet authenticated caller (caller id doesn't count) asking for my details so that they get a proof of who I am. Not going to give extra info to an unknown person, sorry.
I train myself on legit calls to not fall for this, despite some inconvenience.
My hope is that in the future, when the real scummer call will eventually come, I'll be less likely to fall for social engineering tricks, and psychological pressure.
To add, the welcome email doesn't directly say the domain used
Someone can register example.com with google workspace and then they can use "login with google" to log in to your bigboss@example.com 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.
(Perhaps with similar notices published in your local old-school Legal News. There are entire periodicals devoted to the publication of legal notices.)
It doesn't matter if it would fully stand up in court, if the existence of the published prior notices convinced Google or MS that they were risking a nasty Legal Dept. situation.
I noticed all this, of course, because I got email notifications for all of it.
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.
However, the identity provider cannot force you to do that, and there are many examples of apps which do not follow this part of the spec.
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.
Support at google is non-existent. You would never get them proactively calling you about anything. Hell, phoning them and ending up with a human would be a miracle.
This isn't the first time something like this has happened at google. This is like the third "gain access to google resources in an workspace you don't own" exploit in the last year.
This should be expected at this point.
I’ve been thinking afterwords what is actually the most resilient to attack digital identity strategy. Does it actually maybe mean owning your own domain and keeping it with a registrar with heavy authentication procedures and then running your own email services? It’s a huge amount of work and even then do you cloud host and then that’s a weakness. Maybe my email address should have 2FA for both sending and receiving messages, does that even exist in some IMAP extension protocol and some obscure email client.
It all sounds crazy yet if you don’t want to risk Google deciding to erase you or let somebody else take over your primary email address then maybe it’s the only possible option for an advanced threat target.