Do you have trouble logging into your social media accounts or have trouble accessing them? I suggest getting in touch with Angelina if you have any problems with your social media account. She works for META, so I can tell you that she is incredibly dependable and always there to help. I advise you to get in touch with her at AngelinaChristopher1738@gmail.com or via her Instagram account, Angelina_Christopher1738. She is the best solution. Her dependable and timely assistance made me feel relieved instead of frustrated. Please get in touch with her if you need help right away!

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

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

It’s actually a pretty good article. The information that the author has is limited.

This is a big deal, nobody would expect Google to fuck up this badly, least of all the parties who support Google's social login.

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.

So if you own example.com and use bigboss@example.com 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 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.

Your understanding is correct. It happened to me; someone made a Workspace for a domain name I own, and made a user on that workspace to match an email address I have on that domain, and then used "Sign in with Google" on Dropbox. Luckily I don't use Dropbox, so instead of gaining access to my files there, it just resulted in a new Dropbox account being created.

I noticed all this, of course, because I got email notifications for all of it.

Take superbase for example. If you allow multiple oauth providers accounts get automatically linked if they use the same email address. That’s bugging me since day one…

According to spec, when someone uses oauth to try and log into an existing account for the first time, you must require the user to login through their normal method and then prompt them to link the login account.

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.

Curious, which part in RFC 6749 do you refer to or other ones?

I could have sworn I have seen this in the past, but I am not sure exactly where. Thinking about it; it probably would have been part of OIDC and not directly addressed by OAuth... maybe someone can find it for me, or maybe I misspoke when I said it was part of the spec.

I could believe that being in 2.1 as a BCP,but if it's not it's a good idea to add it.

Funny, Google has just locked me out of my work email. Endless loop of "verify it's you" demanding a phone number, even though I use a security key. Entering a number results in "you have tried too many times, try again in a few hours" but that is not true, it seems permanent. Having Workspace super admins reset my password or suspend login challenge for 10 minutes does not work. It will not let me back in.

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.

But but but... Google is so secure! We can trust them to safekeep the data they collect about us! Pinky swear!

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., myname@hotmail.com when myname@hotmail.com was a functioning email ID on outlook.com.

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.

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 “totally_the_admin@bigco.com” 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.

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.

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

Exactly. Google's behavior here is terrible.

> 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

Wait 'til there's a major password manager exploit. The only truly safe option is longish passphrases you can remember.

This already happened with last pass.

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

I suspect that was the intent. Clickbait without being obvious.

> I thought they were talking about the kid who gave Trump a haircut.

The same kid who also injured two bystanders and murdered a third?

"hackers/cybercriminals"

I heard that they found a Gab account of his where he seemed to be sounding, well, quite Democrat-y? (Maybe do your own research)

I heard something. I was trying to sound funny. Didn’t mean to turn it into a political post ha

Ah fair enough :)