I got hit by this. On June 6 I got an email from Google saying welcome to Google workspace for my domain.

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.

Thanks for taking the time to explain the issue. I found the article confusing and vague.

So if you own example.com and use [email protected] as log in to greatonlinegame.com ...

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.

Maybe we need the IdP equivalent of CAA records. If I have a domain that doesn’t use a given IdP, I want everyone who might rely on that IdP to know that the IdP in question has no authority on that domain.

A related topic. I saw Google create hotmail accounts on the Gmail platform e.g., [email protected] when [email protected] was a functioning email ID on outlook.com.

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.

A Google account was being created without Gmail in this case.

So these attackers could gain access to any account with email with a domain not currently registered to a Google Workspace? This seems like a huge breach of trust. (Especially given that it gave access to outside of Google accounts).

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

From what’s stated they could create a new account but not gain access to an existing account. So they create “[email protected]” and then login via google elsewhere and try to use that as a way to gain further access to bigco accounts, presumably by some manual support.

> The vector here is they would use one email address to try to sign in, and a completely different email address to verify a token

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 get occasional probes from Google services against my domain, clearly made by bad actors who are trying to break into it. It's not "lose your domain with a slip of the finger" territory, but it's still not great.

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.

For Google and Microsoft, you have to add some TXT records to verify your domain.

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.

Idea: DNS TXT records are free-form. What if you used those to publish some (very short) "Legal Notices", stating that certain things were not authorized, and should be assumed fraudulent?

(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.

What do you mean probing your domain from Google?

I assume trying to sign up for Google services (business email etc.) for his domain

Exactly.

When I was an admin for a Google Apps Domain, you couldn't even stop people from making a google account that aliases a google apps account.

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.

This was done to me. They even called me imitating google security team by using google assistant feature and using a free trial to register my own phone number as the business name then calling via Google to get assistant to call me repeatedly showing up as google. Eventually I picked up as I was also get simultaneously account recovery requests on my gmail. AND they sent me DKIM verified emails that appear to come from google themselves. I recorded the phone conversation if LE might be interested. The combination of there existing an account on workspaces, verified emails, and spoofed google caller ID from numbers that superficially appear to be actually google numbers - you have to read closely that they are Google Assistant numbers! was pretty convincing initially, they had be for a few minutes on the call. And they tell you your account is having it’s phone number changed, we need to do something now or it will take a long time to recover it. I didn’t fall for it but then I pretended I was and put on a big show. I have a long recording with their voice and timestamps of everything.

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.

> ... 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!

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.

> through Google’s “Sign in with Google”

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.

I used to feel similar. But then I realized that my browser's password manager also can't get hacked (or if it does they have full browser access anyways) and it is actually easier to sign in with a pre-filled username and password (just click login) than going through the third-party auth flow (and remembering which one you used).

I really like Spotify's approach. In previous years it was confusing as if you signed up under a social you didn't have a user/pass to login with; but now they just break out all login methods and let you link Google/Facebook or just set a standard email/pass.

this backfired on me a few years ago, my nvidia shield was connected to my account and then a friend on wifi linked to it, and it nuked both our accounts. lol

had that too. did not react. after some time got a mail "workspace closed"

Uhh, I also received an email like that. I was suspecting something fishy but hoped that they just expect someone to click a link. Any idea what they could have done? I never auth with google. And the email domain is not mine but email provider's.

To add, the welcome email doesn't directly say the domain used