Let’s start with a quick recap of what two-factor authentication is and what it’s supposed to achieve.
Two-factor authentication (2FA), or more generally multi-factor authentication (MFA), is the idea of relying on at least two different authentication factors rather than just one. Authentication factors must come from different categories such as knowledge (a password, PIN, etc.), possession (a hardware token, smartphone, etc.) or inherence (biometrics).
The idea is simple and similar to the Swiss cheese model you may remember from the COVID measures: While each individual protection can be defeated by an attacker, it is much more difficult to successfully overcome multiple factors at the same time.
Passwords can be phished or cracked, hardware tokens can be stolen and biometrics can be forged. For example, to defeat the combination of a password and a hardware token, an attacker must not only successfully obtain your password, but also be physically near you to steal the token. This is impossible for the majority of globally operating attackers. However, it is fundamental to the security of MFA that a user must always successfully authenticate all factors. Otherwise, your system is less like a castle with multiple layers of defence and more like a house where you left the door and windows open and now wonder how the burglar got in, even though you kept the balcony door closed.
While 2FA is becoming an increasingly common feature in software – not least because it is required by compliance standards such as PCI DSS or PSD2 – attention to detail often fades quickly. This happened to PayPal, and I’d like to tell you how I bypassed 2FA on PayPal corporate accounts, only to find that PayPal didn’t really care.
How 2FA can fail
In addition to personal accounts, PayPal also offers corporate accounts, which have some additional features, like managing users who have access to the account.
When I first tested this in August, PayPal required strong authentication with 2FA when adding new users to the account. This is a good decision, because an attacker who only briefly accesses the account (e.g. through an unlocked computer or an XSS vulnerability in the application) can use this feature to gain permanent access. Also, if there are any other features that require strong authentication, an attacker could use this to bypass it by simply adding a new account and configuring 2FA for that account.
At first glance, PayPal has implemented the strong authentication in a common and fairly straightforward way: When adding a new user, even though I am already logged in, I am asked to enter a TAN that is send to me via SMS.1
The TAN is verified, and if I have entered it correctly, I am redirected to the user management dialogue, where I get a message confirming that the user has been successfully created.
The vulnerability that allowed the second factor to be bypassed was in the enforcement of this workflow. Although each step seemed to be implemented correctly, it was never verified that all steps had been successfully completed. As a result, instead of prompting the system to send the SMS with the TAN, it was sufficient to press the ‘back’ button in the browser. All it took to complete the workflow was to return to the user management dialogue after being prompted to authenticate via SMS TAN. It was never checked whether I ever completed the final verification step.
I reported this to PayPal through HackerOne in August. I quickly received feedback that the issue didn’t qualify for a bounty as “it appears that, for successful exploitation of above issue an attacker requires having compromised credentials or physical access to the victim’s system”. I was aware of this before I submitted the report.
I didn’t hear anything new until end of November, when the ticket was closed as woks as designed:
PayPal team reviewed this report and confirmed that this finding is working as designed.
Revisiting the issue confirmed that the second factor authentication can no longer be bypassed as it’s no longer required.
Instead of fixing the problem, PayPal decided to remove 2FA. This decision compromises security and leads to non-compliance with any standard that requires 2FA. This decision also allows 2FA to be bypassed for any other feature where strong authentication may still be required, as attackers – instead of breaking the current user’s second factor – can simply create a new user and set up 2FA for them with a mobile number they control.
When implemented correctly, two-factor authentication can be a powerful tool against identity theft. However, as a layered defence, it is tempting to take problems with it lightly. Therefore, it is important to keep in mind that 2FA is not just a safety net, but rather an integral piece of your security, as no single factor is sufficient on its own: to achieve a comparable level of security with password authentication alone, the password would have to meet much higher requirements than most of them do. And it still wouldn’t address all the threats that MFA can protect against.
This is two-factor authentication: the existing session has been authenticated by password login (knowledge) and the SMS TAN proves possession via a previously paired phone. ↩︎