Slashdot Mirror
Trivial Bypass of PayPal Two-Factor Authentication On Mobile Devices
chicksdaddy (814965) writes "According to DUO, PayPal's mobile app doesn't yet support Security Key and displays an error message to users with the feature enabled when they try to log in to their PayPal account from a mobile device, terminating their session automatically. However, researchers at DUO noticed that the PayPal iOS application would briefly display a user's account information and transaction history prior to displaying that error message and logging them out. ... The DUO researchers investigated: intercepting and analyzing the Web transaction between the PayPal mobile application and PayPal's back end servers and scrutinizing how sessions for two-factor-enabled accounts versus non-two-factor-enabled accounts were handled. They discovered that the API uses the OAuth technology for user authentication and authorization, but that PayPal only enforces the two-factor requirement on the client — not on the server."
The attack worked simply by intercepting a server response and toggling a flag (2fa_enabled) from true to false. After being alerted, PayPal added a workaround to limit the scope of the hole.
Update: 06/26 00:42 GMT by T : (Get the story straight from the source: Here's the original report from DUO.)
/comment&FunnyFlag=1
Saskboy's blog is good. 9 out of 10 dentists agree.
Security by incompetence.
No thanks, Pay Pal. You're not a bank, and apparently terrible at security. So you're not trustworthy.
Client side enforcement of two factor authentication may give the illusion of security, but it's anything but.
This is either lazy/incompetent programmers, or idiot managers.
Lost at C:>. Found at C.
wow. simply, wow.
If you have a very little bit of information, it's pretty easy to get around it on the regular website too, but I suppose it's better than nothing...
PayPal only enforces the two-factor requirement on the client
Many rookie developers just take the easy way and think that they can simply validate data client side. Never trust the client (even if you wrote it), the minute it is out there, someone can tamper with it.
I see this kind of mistakes coming from startups, or the little indie guy making his web site, or the new hire with little experience. For a seasoned tech company like PayPal this is an epic fail. Even if they had a rookie do this app, they need a senior programmer to do a code review, and if they did, then they need to replace him.
Embarrassing, and inexcusable.
currently the paradigm is if someone has control of your cell phone your two factor ID becomes zero factor ID. This is because nearly all cell phones can collect e-mail, allowing a password reset to be performed. Likewise cell phones display text messages with the second factor. So you are hosed. Even if you have a screen lock on your phone, have you ever lent your phone to a stranger to "make a call" or take a photo?
The workaround for this is to have a second e-mail address that you don't have associated with your phone's e-mail program. Then you can send all your finanical accounts to the e-mail address. But that's not really very convenient (e.g. amazon and google wallet would be awkward to use that way).
What needs to be done is to have financial companies send all non-critical e-mails (e.g. paypay receipts and notices) to your general e-mail, but require a second e-mail address for all critical transactions where money is movable.
or even better, they could simply require that all password resets go to a secondary e-mail address. this would be even more convenient.
until then two factor ID using cell phones is just a very vulnerable layer of the security onion.
Some drink at the fountain of knowledge. Others just gargle.
A better solution is to just don't use PayPal.
PayPal's for bozo's who can't be trusted with a real credit card.
The attack worked simply by intercepting a server response and toggling a flag (2fa_enabled) from true to false. After being alerted, PayPal added a workaround to limit the scope of the hole.
That's nice, but is adding a new flag called "2fa_really_enabled" to prevent any exploits of the original hole from working really the best way to deal with this?
This reminds me of when the government issued a redacted PDF where they just drew black vector rectangles on a separate layer on top of the PDF using Adobe's software. Can you say ASCII rip?
They hired the same team to handle security at the main gate in PayPal's headquarters. Here is a picture
Here is a helpful car analogy explaining how this security vulnerability works.
Duo.. this is not what you do well.. please reconsider hacking other people security models.
This is part of why I don't bother to support half-assed roll-your-own 2FA systems like PayPal's, or stupid SMS-based schemes like Apple's. If you want to offer 2FA, offer me RFC 6238 so I can handle all my 2FA accounts in one convenient app and I know you didn't invent it yourself.
Mind you, I guess PayPal's programmers would have just implemented RFC 6238 client side and sent an extra parameter to say I'd got the code right.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
The fucking thing hasn't ever worked for me, not once, not ever. Always blaming the server side. Win!
The "Civilized World" jumped the shark ca. 1973.
Not the first time this has happened. PayPal are clowns.
In 2009 (ctrl-f for "bypass the use").
In 2011 (ctrl-f for "don't have your football"), where they allowed use of common-knowledge as a fallback if you didn't have your 'football'.