Dozens of high-traffic websites vulnerable to ‘account pre-hijacking’, study
portswigger.net
portswigger.net
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...
What you are saying is true, but it’s unlikely anything will be done because it’s expensive and not a huge risk.
> 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.
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.
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>").
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)
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.
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.
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)
Consider this: it is established practice to distribute all sorts of information about people that is far more intimate than your home address, if it is only "anonymized" in an accepted manner. HIPAA is no bar to this.
But decades ago, a researcher showed that the vast majority of people can be identified through only a few data points, like for example gender, birth date, and zip code. These are available in supposedly non-identifiable data sets. She went on to demonstrate that a US state governor at the time could be linked to his health records, which were public sans name and address.
It's about straightforward math - each data point, if more or less randomly distributed, reduces the number of people exponentially, so "anonymizing" people in data sets doesn't work and never did.
"Fingerprinting" people based on "anonymized" data is one thing, then there's just the constant total security breaches. My primary care doctor's practice had a massive leak of data because their accountant screwed up. There were no consequences for either entity except for someone having to write an embarrassing letter.
There's also the fact that every bit of information the US government had on millions of individuals with a security clearance was compromised by someone hacking into the Office of Personnel Management some years ago. Everything from the intimate details of their lives collected by background investigators, to fingerprints, everything on anybody (it was rumored that the CIA has a separate system, but otherwise everybody - for instance, James Comey mentioned it impacted him)
The entire discussion of privacy and security has a "Emperor's New Clothes" aspect to it. Whoever got the OPM information presumably was able to wipe up virtually every covert US agent abroad, and create a file on virtually every cleared person in the US. And maybe they shared it with allies too. Why do you think American politics has gotten so crazy and paranoid in the last few years?
Talking about improving security on the internet is like talking about organizing a neighborhood watch in Hiroshima just after it was nuked. It's over!
The only thing I can think of is social shunning/shaming of those who don't respect personal privacy voluntarily. Barriers are not impregnable, they are symbolic.
What did it matter, 30 to 50 years ago, if things were public. Public how?
Well, sure it was public knowledge about home ownership, but you'd have to fax, or call, to get the info! And a person would have to do the work of a lookup of paper files. And so often there was a minor charge, to pay for that bit of work.
Maybe even long distance phone costs(fax), or shipping costs too!
So sure, it was public knowledge, but not usable in some sort of mass exploit. And beyond that, people performing mass exploits encountered people at the other end too!
So people would notice a change in behaviour, strange things happening en mass.
Sure, "a dude" could pull tricks against an account, but hundreds? Millions? No way!
So legisltion, and behaviour needs to catch up, and embrace the differences today.
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.
I'm not saying it's right to toss your trash into your neighbors yard, but if you're not allowed to use a trash bin, and nobody ever comes to your house to collect garbage it's not not hard to imagine why it happens that some folks will chuck their trash anywhere.
Most people only do those types of things because they've been backed into a corner and don't know what else to do. Give folks an alternate that lets them sign up for stuff without hurting themselves in the process and they'll do it. We've had some great services pop-up to help (like temporary email services and bugmenot) but as those become less effective people will do whatever is left to them.
Now that I'm aware of this security flaw, I'm not sure whether that instance was incompetence or malice.
Also, if someone uses my email to sign up for some site, you know I'll be using the password reset functionality immediately, then checking that site out ASAP.
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.
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.
"In their study, the researchers examined 75 services that ranked among Alexa’s list of top-150 high-traffic domains."
Ironically, Microsoft accounts seemed to be vulnerable as of last year. I got an email from Microsoft about someone renaming an account linked to my email address - an account I didn't know about.
I was never able to recover access as they wanted me to prove I owned the account and whoever had created it had all that info.
If anyone in Microsoft is reading this I'd appreciate help sorting this out!
Your Microsoft account has been renamed. We just wanted to check with you that it's okay.
- Old account name: <my email address>
- New account name: <someone else>@outlook.com
If this is correct, you don't need to do anything.
If this is incorrect, please follow these steps:
1. Reset your password by going to https://account.live.com/password/Reset
2. Rename your account by going to https://account.live.com/
Neither link worked for me because I couldn't authenticate the account that someone else created. I couldn't stop the account name being changed, even though I had control of the original email address.Later when I submitted a request to reset the account I was asked for more information at this link: https://account.live.com/acsr. Again, this required me to know info about the account someone else created.
I managed to link my email address to another Microsoft account, but I'm not confident that someone still doesn't have another Microsoft account with partial control of my identity.
If anyone has any tips about who to talk to at Microsoft other than an automated system I'd appreciate it!
I'm not sure I'd rely to much on that new account though. It's easy for me to imagine the first renamed account being banned for fraud and then any "known associates" being banned as well.
- Classic-Federated Merge (CFM)
- Unexpired Session (US)
- Trojan Identifier (TID)
- Unexpired Email Change (UE)
- Non-verifying IdP (NV)
6.2 Root Cause & Mitigation
6.2.1 Strict Identifier Verification
The root cause of all of the attacks identified in the preceding sections is failure to verify ownership of the claimed identifier.CWE-304: Missing Critical Step in Authentication <https://cwe.mitre.org/data/definitions/304.html>
Looking at the CWE-304 wording, this does not look like the right CWE, but OWASP ASVP 2.2.2 points to this CWE.
OWASP ASVP 2.2.2 <https://github.com/OWASP/ASVS/blob/v4.0.3_release/4.0/en/0x1...>
2.2.2
Verify that the use of weak authenticators (such as SMS and email) is limited to secondary verification and transaction approval and not as a replacement for more secure authentication methods. Verify that stronger methods are offered before weak methods, users are aware of the risks, or that proper measures are in place to limit the risks of account compromise.
CWE-304CWE-306: Missing Authentication for Critical Function <https://cwe.mitre.org/data/definitions/306.html>
Looking at the CWE-306 wording, this does not look like the right CWE, but OWASP ASVP 3.7.1 points to this CWE.
OWASP ASVP 3.7.1 <https://github.com/OWASP/ASVS/blob/v4.0.3_release/4.0/en/0x1...>
3.7.1
Verify the application ensures a full, valid login session or requires re-authentication or secondary verification before allowing any sensitive transactions or account modifications.
CWE-306... and I say this as a vigorous proponent of second factor authentication.
The real fix here is to completely change how the service handles email addresses. You can continue to request it, but it cannot be used as an identifier until it is confirmed.