PayPal fixed an issue that could have allowed an attacker to hijack OAuth tokens associated with any PayPal OAuth application.
The vulnerability was publicly disclosed on Monday by Antonio Sanso, a senior software engineer at Adobe, after he came across the issue while testing his own OAuth client. For its part, PayPal remedied the vulnerability about three weeks ago.
The OAuth flaw, according to Sanso, stemmed from the token request and acquisition process. For starters, PayPal allows developers to create and edit their own apps through its developer application dashboard. After creating them, developers can register those apps and obtain an access token for them by sending a request to the company, which acts an authorization server. That PayPal server could be overridden however, Sanso found.
According to Sanso, the vulnerability stems from an error PayPal made when it implemented the OAuth. Developers with the company had set it up to accept any client. In this case Sanso used localhost, the standard hostname given to the local computer a program is running, as redirect_url, the address used by OAuth providers to deliver access tokens, via browser redirect.
After creating a DNS entry on his own site that mimicked localhost – http://localhost[.]intothesymmetry[.]com – Sanso found he could send a request to PayPal using that URL as the redirect_uri. It ultimately overrode the validation stipulated by PayPal and returned a PayPal OAuth client token.
Sanso stressed to Threatpost that since it was universal, the trick could have worked for any PayPal OAuth client. Before the issue was fixed, he claims, he could’ve made an OAuth request using his redirect_uri and the client_id of any application to get an app’s authorization token sent to his server.
PayPal began employing stricter redirect checks around the verification of the redirect_uri parameter in 2015 and uses exact matching to validate requests; but Sanso was still able to trick it with his own localhost subdomain. In this case ‘localhost’ was almost like a “magic word,” Sanso said.
He told Threatpost that what an attacker would be able to do with the access tokens would depend largely on the scope of the access token and the OAuth flow.
Sanso, who lives in Switzerland and co-authored a book on OAuth 2.0 last year, discovered the issue back in September but it took some prodding to get the issue resolved. Following a back and forth with the company – and radio silence for the month of October – PayPal informed Sanso on November 7 that it had fixed the issue.
https://twitter.com/asanso/status/803177137708605440
The company did not immediately return a request for comment on Monday, but according to Sanso developers there fixed the issue by making it so the “PayPal Authorization Server no longer overrides the correct validation they had in place.”
The way Sanso bypassed PayPal’s redirect_uri validations is similar to how Egor Homakov, a Russian researcher who went on to found the pen testing firm Sakurity, hacked GitHub in 2014. Through a series of OAuth bugs, Homakov found he could bypass validations in GitHub with a path traversal attack. Homakov found that every time he requested an authorization token, the provider responded with a valid access_token. Another bug he found could allow an attacker to hijack authorization code used for the redirect_uri. GitHub’s bug bounty program was in its infancy at the time, but it fixed those bugs and awarded Homakov with $4,000 for uncovering the vulnerabilities.
Facebook has patched issues that hinged on how the site used OAuth over the years as well. In 2014 it fixed an issue that Sanso also discovered that allowed for bypass and stemmed from the improper validation of redirect_uri not validating correctly.
Facebook patched a similar bug in 2013, dug up by Nir Goldshlager that relied on tricking victims into following a link. Goldshlager modified the URL string Facebook used for OAuth to get users to navigate to his own site and trigger an access token he stored there.
Researchers with the University of Hong Kong highlighted a nasty flaw in OAuth 2.0 earlier this month at Black Hat Europe. A trio of academics said at the conference that poor OAuth implementations which allow for Facebook and Google single sign-on functionality can lead to account hijacking in one billion mobile apps.
