4 ms·

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/c

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.

georgyo 4y ago
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.
TheGeminon 4y ago
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.
- n4bz0r 4y ago
  Where is Bob? What happened to Bob? Has anyone seen Bob lately?
  - mikevm 4y ago
    Bob is a good guy, M(alicious)allory is a bad girl.
- Gigachad 4y ago
  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
  - xvector 4y ago
    Don't most services require you to confirm your email? Mallory would be unable to get past step 1
    - Gigachad 4y ago
      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.
    - croon 4y ago
      The way I read it it's dormant (unconfirmed) until Alice signs up, at which point it's implicitly confirmed through SSO.
  - jobigoud 4y ago
    > 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.
heliodor 4y ago
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.
tluyben2 4y ago
I have seen sites that are vulnerable to this; - 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.
- xeromal 4y ago
  That's pretty clever. Thanks for sharing the thought process!
- Pxtl 4y ago
  > 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.
  - Gigachad 4y ago
    The cumbersome way would be to confirm the email, do a password reset and then deactivate the account.
    - Pxtl 4y ago
      I'm hesitant to do this because occasionally I've been blocked by some second factor for password resets, but at that point I've confirmed the email.
      - ridgered4 4y ago
tsimionescu 4y ago
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.

georgyo 4y ago

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.

TheGeminon 4y ago

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.

n4bz0r 4y ago
Where is Bob? What happened to Bob? Has anyone seen Bob lately?
- mikevm 4y ago
  Bob is a good guy, M(alicious)allory is a bad girl.
Gigachad 4y ago
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
- xvector 4y ago
  Don't most services require you to confirm your email? Mallory would be unable to get past step 1
  - Gigachad 4y ago
    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.
  - croon 4y ago
    The way I read it it's dormant (unconfirmed) until Alice signs up, at which point it's implicitly confirmed through SSO.
- jobigoud 4y ago
  > 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.

heliodor 4y ago

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.

tluyben2 4y ago

I have seen sites that are vulnerable to this; - 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.

xeromal 4y ago
That's pretty clever. Thanks for sharing the thought process!
Pxtl 4y ago
> 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.
- Gigachad 4y ago
  The cumbersome way would be to confirm the email, do a password reset and then deactivate the account.
  - Pxtl 4y ago
    I'm hesitant to do this because occasionally I've been blocked by some second factor for password resets, but at that point I've confirmed the email.
    - ridgered4 4y ago

tsimionescu 4y ago

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.