Mobile
6/25/2014
06:00 AM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

PayPal Two-Factor Authentication Broken

Researchers discover a way to bypass the extra layer of security for mobile PayPal app accounts.

PayPal has temporarily disabled two-factor authentication for its mobile apps while it works on a patch for a newly discovered flaw that bypasses the security feature.

Independent researcher Dan Saltman in March reported to PayPal that he had discovered a way to bypass two-factor authentication in Apple iOS, but after getting no response from PayPal, Saltman in April went to friends at mobile security firm Duo Security to help him reproduce the security issue and assist him in reaching PayPal. Researchers there were able to confirm his finding, as well as discover the same problem in PayPal's Android app, which they then reported to PayPal as well.

Two-factor authentication, a more secure way method for users to log into applications securely, increasingly is being added as an extra layer of protection to protect users in the case of password theft. That feature is an option with PayPal's mobile apps, and researchers say a vulnerability in api.paypal.com -- a PayPal API that uses OAuth for authentication and authorization -- is flawed and does not enforce two-factor authentication on the server while authorizing a user. PayPal's web application does not contain the flaw.

"It's a security feature you have the option to turn on. If your password gets compromised, at least you've upped the ante, now the attacker needs to know an additional thing. But underneath, this [security feature] is defeatable," says Zachary Lanier, a senior security researcher at Duo Security who led the team that found the root of the problem. "It's a security control that wasn't really living up to its promise."

PayPal is currently working on a fix for the vulnerability and plans to release via an update on July 28, according to Duo Security. In the meantime, PayPal's two-factor authentication mobile option has been disabled.

A PayPal spokesperson issued this statement:

Through the PayPal Bug Bounty Program we were recently made aware of a potential way to bypass our two-factor authentication (2FA) log in process for a small number of our mobile products. We want to emphasize that all PayPal accounts remain secure. The workaround identified was related to an extra layer of security some customers have chosen to add to their account and was reported directly to PayPal before being shared publicly.

As a precaution we have disabled the ability for customers who have selected 2FA to log in to their PayPal account on the PayPal mobile app and on certain other mobile apps until an identified fix can be implemented in the next few weeks. While we regret any inconvenience this may cause our customers, their security is our top concern.

Lanier, whose team also created a proof-of-concept demonstrating how the bug could be exploited, says the worst-case scenario would be an attacker gaining access to a user's password, bypassing the second factor of authentication, and transferring money from the victim's account. "An attacker could use someone's credentials they got from a password dump" to bypass the second factor step in logging into the account, he says.

"The flaw is that there's no actual server-side two-factor authentication enforcement for api.paypal.com," Lanier says.

Meanwhile, the weakness is easily discoverable, he says. "The user has a false sense of security that having two-factor authentication means they're even more protected. Are there cases where users are reusing a password because they have two-factor authentication?"

Why go public with the flaw before the patch? Lanier says Duo Security was worried about bad guys finding and abusing the bug, especially with the large number of phishing campaigns against PayPal. "We feel good reporting it so we worked with them," he says. "We are a little disappointed in the fact that it was probably out there for some time and… when was the bug introduced? Why was it there? Did they know? Was it de-prioritized?"

PayPal has had a bug bounty program in place for some time. But according to a timeline provided by Duo Security, neither Saltman nor Duo Security got regular responses or updates from PayPal during the responsible disclosure process.

Duo Security has released a video demonstration of the PayPal flaw here.

Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
securityaffairs
50%
50%
securityaffairs,
User Rank: Ninja
6/25/2014 | 6:45:18 PM
Re: corrected point of sale process
The flaw is related to PayPal implementation for mobile platforms of 2FA mechanism.

Concerning it the time that will pass until the planned final fix (July).

Anyway PayPal has already implemented a temporary fix to protect its customers properly managing the session token and to avoid attackers to transfer victim's money.

 
Kelly Jackson Higgins
50%
50%
Kelly Jackson Higgins,
User Rank: Strategist
6/25/2014 | 12:44:51 PM
Re: corrected point of sale process
Great question, @BurgessCT. PayPal didn't say, but they are taking responsibility for the patch. 
BurgessCT
50%
50%
BurgessCT,
User Rank: Apprentice
6/25/2014 | 11:45:17 AM
Re: corrected point of sale process
Good piece Kelly - my question is did PayPal roll-their-own 2FA or did this flaw come from a partner's implementation of 2FA for the application?  

Context - I and other small business owners lack the resources of a company like (ebay/paypal) and thus recognizing the level of effort to roll-your-own for a good 2FA is important.

Thanks for the piece, Duo's commentary is much appreciated.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
6/25/2014 | 10:14:12 AM
Re: corrected point of sale process
Sounds like something to keep on the radar...
Kelly Jackson Higgins
100%
0%
Kelly Jackson Higgins,
User Rank: Strategist
6/25/2014 | 9:10:29 AM
Re: corrected point of sale process
Hmmm...good question. I'm not aware of any others (but that doesn't mean there haven't been any), and Duo Security says they expect to find similar issues in other mobile apps.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
6/25/2014 | 9:08:52 AM
Re: corrected point of sale process
Kelly, to your knowledge, how common are 2FA flaws? Is this the next big thing?
Kelly Jackson Higgins
50%
50%
Kelly Jackson Higgins,
User Rank: Strategist
6/25/2014 | 8:37:57 AM
Re: corrected point of sale process
The "good news" here is that PayPal is working on a fix. In the meantime, 2FA is disabled for mobile, so authentication is old-school for now with iOS and Android.
macker490
100%
0%
macker490,
User Rank: Ninja
6/25/2014 | 8:34:44 AM
corrected point of sale process
Fixing the Point of Sale Terminal (POST)

THINK: when you use your card: you are NOT authorizing ONE transaction: you are giving the merchant INDEFINITE UNRESTRICTED access to your account.

if the merchant is hacked the card numbers are then sold on the black market. hackers then prepare bogus cards -- with real customer numbers -- and then send "mules" out to purchase high value items -- that can be resold

it's a rough way to scam cash and the "mules" are most likely to get caught -- not the hackers who compromised the merchants' systems .


The POST will need to be re-designed to accept customer "Smart Cards"

The Customer Smart Card will need an on-board processor, -- with PGP

When the customer presents the card it DOES NOT send the customer's card number to the POST.  Instead, the POST will submit an INVOICE to the customer's card.  On customer approval the customer's card will encrypt the invoice together with authorization for payment to the PCI ( Payment Card Industry Card Service Center ) for processing and forward the cipher text to the POST

Neither the POST nor the merchant's computer can read the authorizing message because it is PGP encrypted for the PCI service.  Therefore the merchant's POST must forward the authorizing message cipher text to the PCI service center.

On approval the PCI Service Center will return an approval note to the POST and an EFT from the customer's account to the merchant's account.

The POST will then print the PAID invoice.  The customer picks up the merchandise and the transaction is complete.

The merchant never knows who the customer was: the merchant never has ANY of the customer's PII data.

Cards are NOT updated.  They are DISPOSABLE and are replaced at least once a year -- when the PGP signatures are set to expire.  Note that PGP signatures can also be REVOKED if the card is lost.

Transactions are Serialized using a Transaction Number ( like a check number ) plus date and time of origination.    This to prevent re-use of transactions.   A transaction authorizes one payment only not a cash flow.

~~~
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.