Maybe I'm missing something in the description of the exploit, but don't sites that use email address during account creation typically send some sort of link/code to the provided email to verify ownership? So does this vulnerability assume the attacker has access to the victim's email? If that's the case it seems like "pre-hijacking" would be the least of concerns.
- the hackers signs up with xxxx@gmail.com via the normal email/pass way
- the email arrives in xxxx their mailbox but it is ignored (might even be flagged as something they don’t read anyway because, for now, it’s an unknown service)
- the user, at some time in the future, goes to the site and signs up (they think) by clicking ‘sign up with Google’
- the site now merges the former account with the latter and signs in the user; because signing in with gmail, there is no email link that has to be clicked
The site’s ( erroneous ) db entry is now a validated (via sso) account with a manual password; the hacker can now login with the password they set in the first place while the real user logs in via the Google sso link.
> the email arrives in xxxx their mailbox but it is ignored (might even be flagged as something they don’t read anyway because, for now, it’s an unknown service)
Most services don't even offer a way to resolve this.
There is never a "this email does not belong to the person who created the account and should be detached from it" link.
Those who do, don't have a way to prevent it in future.
Some same guy keeps using my email address as their recovery email for Gmail every few days. And I have to detach it again and again. Amazing spam by Google. Nobody can do anything.
I'm curious, have you ever tried contacting that guy and explaining that he shouldn't use your email address?
This design seems like a surprising oversight on Google's part. The correct design is to only add the recovery account if a verification link is clicked (which is in fact what they do for enabling mail forwarding). That way you could simply create a filter to mark the requests from that guy as spam. However, being the recovery address of this guy doesn't seem like such a serious problem – it should be relatively easy to filter the emails that Gmail sends to recovery accounts (something like "from:no-reply@accounts.google.com <guy's email address>").
We simply have both status (not verified) and a type (password) fields; so an type sso login or signup will never encounter a type password record and a not verified record will never let you get logged on. Then we purge not verified records every few days.
I would expect a phone number link request at that point for suspicious activity, which actually is suspicious this time. And that is assuming it's even possible to deactivate the account without going into a black hole phone tree which is what I expect these days. Even if you successfully deactivate it, a service you aren't using now has data on you that won't ever actually be deleted. Trying to fix it feels like it's almost playing into the scammer's hands.
Yes this is so annoying! I think it also sometimes happens when email addresses are communicated through speech instead of writing.
Though I tend to just block the sender domain (because they're always from services that I'm never going to use anyway) and ignore the email just on the off-chance that someone is trying to scam me in some weird way. (Plus I really just don't care enough to deal with it unless the email is clearly important or sent by an actual person)
I've stuck to using only email logins simply for less reliance on google (or any other specific service) and getting unique logins for every new service. I'm glad there's now a security benefit attached to it as well, even if I would have never imagined it myself.
It used to be standard for signup forms to include only the email address. It was thought to decrease friction. At some point, someone decided it was better to ask for a password upfront, then it became the new standard.
Is your email address something like [fullname]@gmail.com? Because in that case it's more likely that someone is either confused about their own email address or just made a typo and left out the number they put after the name they happen to share with you.
It is in the form of [fullname]@gmail.com. It got so bad to the point that I called the guy and we spoke. Now when I see an email from an org in his state, I automatically forward it to him. My email for instance is firstlast@gmail.com, his is firstllast@gmail.com and he forgets to put the 'l'.
I haven’t read the actual report, but I would imagine a scenario like this would be possible:
1. Mallory registers an account for alice@example.com using a password.
2. Alice receives an account activation email, but doesn’t do anything about it.
3. At a later date Alice registers an account on the service using a social login/SSO (e.g. Google, GitHub)
4. Alice properly activates the account (may or may not be required, depending on the service).
5. The service merges the password account together with the SSO account since they have the same email.
6. Mallory can access Alice’s account with their original password from step 1, while Alice continues to use social login, unaware they also have a password set.
Took me several reads to fully understand this but it actually is concerning since there is no user error required here. Although it is a little unlikely and hard to pull off
> Although it is a little unlikely and hard to pull off
As always with this kind of attack they are not targeting specific individuals, they probably do this to millions of accounts and periodically check if they can login to any.
Not really. It’s become a design trend to send a confirmation email but then not require it. Part of reducing user signup friction. Then later you might prompt or push the user to confirm or mark users with unconfirmed emails as a higher abuse risk.
No, many sites let you continue to use your account _before_ you validate your email address.
They let you configure settings and explore before the address is validated. An attacker can use this to poison an account without ever having access to the actual email address.
Read further down. It's about the merging of an SSO account with an email account, where the email address is the same.
django-allauth is an excellent python package, for example, that has put a lot of effort into such things but I can see how plenty of websites roll their own auth code and make a mess of the complexity that is user accounts.
Most sites go through something like Sign Up > enter email and password > account is created, inactive > send email verification.
If you then log in with SSO using the same email, the existing inactive account, with its password, is merged into the new account, which doesn't require email verification anyway. Furthermore, people logging in with SSO don't usually check or even know about the password, they only use SSO.
With this flow, an attacker knowing your email gets to choose your password, if they can guess a site that you want to SSO login to, but haven't yet.
