I discovered this flaw 3 years ago and sent it to many bug bounty programs. Almost all were closed as informative/not a security issue and I was paid $50 for one after 6 months as a low priority.
This issue will most likely never get fixed as I already let most of the companies in this article know it was a problem...and they just don't care.
This reminds me of credit card fraud and how companies (like VISA) dont seem to care either. As long as they are not held liable for the losses (or it does not cause a drop in users) why would they?
Is there a class-action lawsuit possibility in both cases?
IT security is an insurance problem, and the insurers may stipulate you need a pentest, which makes it not their problem and not your problem - just keep paying those premiums and the liability gets passed to the end-user ;)
There is no class-action lawsuit, that's just business...
It’s because one of the researchers works at Microsoft. I will assume they have contact who work at all the aformentioned companies, contact that allow the security report to escalate to the appropriate channels. I have reported the same security problems too in the past to several companies, and the majority of them have been closed as “informative/non-actionable” too.
> Fortunately, all the affected services were notified of the vulnerabilities and have implemented the necessary fixes.
this is right after they list the affected services
> Top services affected
> In their study, the researchers examined 75 services that ranked among Alexa’s list of top-150 high-traffic domains. At least 35 were affected by one or more account pre-hijacking attacks, including Dropbox, Instagram, LinkedIn, WordPress.com, and Zoom. Fortunately, all the affected services were notified of the vulnerabilities and have implemented the necessary fixes.
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.
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.
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
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.
Sigh. In the last month, I've had to close a new Robinhood account, a new Facebook account, a new Spotify account, and new credit monitoring account - all created with an email address I generally don't use and the attackers phone number (used for initial verification).
Someone registered a Spotify account with my email address at one point, but they apparently didn't give them a phone #. I just requested a password-reset link and changed it, no 2FA needed.
They have my credit card number, but not my phone number, and I guess that's enough for them...
Credit card numbers are worse than passwords when it comes to toxic data.
Why are we, on a daily basis, distributing all the information necessary to fraudulently impersonate us, and we're all OK with that. Then shrug it off 'oh yea they have my home address, credit card number, name, age, mugshot and email address... but at least they can't hijack my phone number'.
Until identity as a concept on the internet catches up with 30 years of cryptography advancements then we're all still stuck in the authentication vs authorization dark ages, the problem is because there's enough critical mass that outside of large enterprise roll-outs it means we're either stuck rubbing two-sticks together caveman style or accepting Apple or Microsoft as our new god (pls upload disk encryption keys to server, and unlock them with your face etc, trust our "secure cloud" while we MITM your login and credentials)
I have a 27 year old email address that's on every spammer's list, and it's in a lot of password breaches because I used to not be diligent about changing it.
So you'd think I'd see this happen... but it hasn't happened to that email.
I assume it mostly happens to gmail, both for the SSO requirement of this attack (of which google is a major provider), and people mistyping their own addresses.
Blindly relying on premade auth libraries puts you in a better position than almost any custom built solution.
Even if you built it right. Some junior dev will misunderstand it years later and introduce issues. While they won’t be submitting bad PRs to an auth library.
> Services that allow sign-up without proof of email (eg. by clicking a link in a verification email) ownership are just obnoxious in general.
I feel the opposite. Many services that force sign-up with proof of email (eg. by clicking a link in a verification email) ownership are obnoxious. It's annoying to have to give a valid email address to sign up for an account just to use a service that wouldn't be required to regularly send things to my inbox otherwise.
This site does it right. Allow account sign up without any email address at all, and then allow users who want email from the site (even if just for something like password recovery) to add their address post-signup.
Most of the time if someone signs up for something with an email address that isn't theirs (successfully or not) it's because they either mistyped their real address or they just don't want that service to send them spam or sell their address to others who'll spam them.
I'd guess that when people are asked to give an email address where none should be needed people often try using a random address because they want to avoid the spam, only to find out they needed to click a link. which likely also generates a lot of unwanted junk in people's mailboxes, but it's hard to blame users who are just trying to protect themselves and don't know a better way.
People tried things like "10 Minute Mail" or signing up for a bunch of anon email accounts at various free services like yahoo, excite, hotmail, and gmail but these days many free email services demand ID to create an account (or an existing email address that does) or addresses at those domains are blocked by websites who want something real to spam.
For me, if whatever@example.com doesn't work I just won't use that service.
It's great if they don't require any email, but if they get one & intend to use it, what prevents them from spamming someone who doesn't even control the account?
I get those quite often. As far as I've been able to tell, they're typically someone else sharing my first and last name, and they're using a Gmail address without the '.' in my usual first.last@gmail.com address. Gmail doesn't care about the period, so firstlast@gmail.com gets to me as well. And only me... You might think that if trying to access utilities, or apply for a job, you might use an address you can actually receive messages on.
That happens to me too. My suspicion is that the sign ups are happening via telephone and the agent handling the sign up is fucking up the spelling or leaving off the disambiguating elements, digits or whatever.
Yeah, usually, though when I tried to sign up to Doordash my account already had someone else's details filled, and even though I corrected them to my details, I could never place an order; Doordash had pre-banned me. Many calls to customer service couldn't fix it, despite promises each time.
Now that I'm aware of this security flaw, I'm not sure whether that instance was incompetence or malice.
> Services that allow sign-up without proof of email (eg. by clicking a link in a verification email) ownership are just obnoxious in general.
I actually hate the services that require an email or phone number for no reason... that's one of the good things about reddit and this forum right here.
Someone every so often uses my email address instead of his/her own and you’d be surprised how many services don’t do any validation at all and you have to consider yourself lucky if you can get them to close the account without resetting the password, which is illegal.
It depends on jurisdiction of course but it is the same as logging in using a password you stole or guessed, which means you claim an identity that is not your own.
The thing that confuses me here is why these sites would 'merge' accounts if you sign it with another identity provider after supposedly having signed up with that email address separately. Shouldn't it just create another account? Or maybe say that the email associated with the account has already been used on this site, and to reset your password instead?
Feels like the issue stems from these sites opening a huge security hole in their sign up process in exchange for the tiniest piece of convenience that most people will never encounter or need.
I wrote a library for Rails a few weeks ago at https://github.com/rocketshipio/nopassword that eliminates passwords for login by making folks login with an email address and then emailing them a code.
It eliminates the vulnerability this article speaks of and eliminates passwords, along with all the support headaches that comes with.
Only if existing sessions are invalidated. Otherwise, magic login links like this have a problem:
- Attacker signs up with victim's email address and is immediately logged in (signup usually triggers a login/session creation). The session could last forever
- Victim tries to sign up, but it doesn't work, because the account is already registered. Victim assumes they forgot about them signing up already and requests a login-link/token. Victim logs in using the method and adds sensitive data to the account.
- Attacker session is still active, attacker can read victim's information.
Attacker can’t sign in with victims email unless they have gained access to victims email account. No session gets created for the authorized user until they provide a valid code and salt (within 3 tries and 5 min).
Readit News
This issue will most likely never get fixed as I already let most of the companies in this article know it was a problem...and they just don't care.
Is there a class-action lawsuit possibility in both cases?
There is no class-action lawsuit, that's just business...
> Fortunately, all the affected services were notified of the vulnerabilities and have implemented the necessary fixes.
this is right after they list the affected services
> Top services affected > In their study, the researchers examined 75 services that ranked among Alexa’s list of top-150 high-traffic domains. At least 35 were affected by one or more account pre-hijacking attacks, including Dropbox, Instagram, LinkedIn, WordPress.com, and Zoom. Fortunately, all the affected services were notified of the vulnerabilities and have implemented the necessary fixes.
- 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.
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.
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.
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.
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.
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.
They have my credit card number, but not my phone number, and I guess that's enough for them...
Why are we, on a daily basis, distributing all the information necessary to fraudulently impersonate us, and we're all OK with that. Then shrug it off 'oh yea they have my home address, credit card number, name, age, mugshot and email address... but at least they can't hijack my phone number'.
Until identity as a concept on the internet catches up with 30 years of cryptography advancements then we're all still stuck in the authentication vs authorization dark ages, the problem is because there's enough critical mass that outside of large enterprise roll-outs it means we're either stuck rubbing two-sticks together caveman style or accepting Apple or Microsoft as our new god (pls upload disk encryption keys to server, and unlock them with your face etc, trust our "secure cloud" while we MITM your login and credentials)
So you'd think I'd see this happen... but it hasn't happened to that email.
If you think properly about security and don't blindly rely on third parties (especially for auth) you'll be fine.
Even if you built it right. Some junior dev will misunderstand it years later and introduce issues. While they won’t be submitting bad PRs to an auth library.
I have a gmail address that simply represents my name, and tend to get something intended for someone else pretty much daily.
I feel the opposite. Many services that force sign-up with proof of email (eg. by clicking a link in a verification email) ownership are obnoxious. It's annoying to have to give a valid email address to sign up for an account just to use a service that wouldn't be required to regularly send things to my inbox otherwise.
This site does it right. Allow account sign up without any email address at all, and then allow users who want email from the site (even if just for something like password recovery) to add their address post-signup.
Most of the time if someone signs up for something with an email address that isn't theirs (successfully or not) it's because they either mistyped their real address or they just don't want that service to send them spam or sell their address to others who'll spam them.
I'd guess that when people are asked to give an email address where none should be needed people often try using a random address because they want to avoid the spam, only to find out they needed to click a link. which likely also generates a lot of unwanted junk in people's mailboxes, but it's hard to blame users who are just trying to protect themselves and don't know a better way.
People tried things like "10 Minute Mail" or signing up for a bunch of anon email accounts at various free services like yahoo, excite, hotmail, and gmail but these days many free email services demand ID to create an account (or an existing email address that does) or addresses at those domains are blocked by websites who want something real to spam.
For me, if whatever@example.com doesn't work I just won't use that service.
Now that I'm aware of this security flaw, I'm not sure whether that instance was incompetence or malice.
I actually hate the services that require an email or phone number for no reason... that's one of the good things about reddit and this forum right here.
What should be out of the question, though, is taking an email or phone number and using it without any verification. That's spam.
Deleted Comment
Feels like the issue stems from these sites opening a huge security hole in their sign up process in exchange for the tiniest piece of convenience that most people will never encounter or need.
It eliminates the vulnerability this article speaks of and eliminates passwords, along with all the support headaches that comes with.
- Attacker signs up with victim's email address and is immediately logged in (signup usually triggers a login/session creation). The session could last forever
- Victim tries to sign up, but it doesn't work, because the account is already registered. Victim assumes they forgot about them signing up already and requests a login-link/token. Victim logs in using the method and adds sensitive data to the account.
- Attacker session is still active, attacker can read victim's information.