> #1 "In order to bypass PayPal’s 2FA, our researcher used the PayPal mobile app and a MITM proxy, like Charles proxy."
> So you need to be MITM'd and have a malicious cert installed? Yeah... not "critical" and out-of-scope for most places.
In generally, using a proxy to perform a 2FA bypass wouldn't decrease the risk. In this case, the attacker already has compromised credentials, and they are trying to bypass the secondary control. As they are the one authenticating, the need for MiTM isn't a huge deal.
That being said, another point that was made is that the "2FA" they are bypassing isn't actually Paypal's 2FA. Instead, it is a secondary, risk-based validation. A bit of a semantic difference, but important to note that if a user was leveraging 2FA this bypass wouldn't actually get an attack who had compromised credentials access.
No. The attacker is the man in the middle to himself, because why are you trusting the client.
> A "security" flaw that requires stolen creds and brute forcing isn't going to get much traction anywhere.
The feature is meant to stop people from using stolen creds.
It does not work.
Given that stolen creds exist, that sounds like a security flaw to me.
It's not "impossible to use stolen credentials", it's "you have to clear this barrier to use stolen credentials". If that barrier is broken, that sounds like a flaw in the security model.
But with the flaw here, the effectiveness drops to zero. The "making certain attacks harder to perform" is basically gone in the scenario where someone is buying a bunch of credentials. That's not good!
#5 and #6 are indeed exaggerated, especially that even if hacker has stolen credentials, and bypassed automatic 2FA, security question won't be displayed on same page users use to confirm payment (to replace e-mail address), or keylog credit card information.
#1 "In order to bypass PayPal’s 2FA, our researcher used the PayPal mobile app and a MITM proxy, like Charles proxy."
So you need to be MITM'd and have a malicious cert installed? Yeah... not "critical" and out-of-scope for most places.
For "#2 Phone verification without OTP", look at the messages they were sending. Did they not understand H1's responses? Repeatedly demanding answers isn't a great look. It's not surprising it was locked.
For #3: it requires stolen creds. A "security" flaw that requires stolen creds and brute forcing isn't going to get much traction anywhere.
#4 was a dupe
#5 is a self XSS, no one accepts these
#6 is a stored self XSS and a dupe