1 Billion Mobile Apps Exposed To Account Hijacking Through OAuth 2.0 Flaw (threatpost.com)

Threatpost, the security news service of Kaspersky Lab, is reporting a new exploit which allows hijacking of third-party apps that support single sign-on from Google or Facebook (and support the OAuth 2.0 protocol). msm1267 quotes their article: Three Chinese University of Hong Kong researchers presented at Black Hat EU last week a paper called "Signing into One Billion Mobile LApp Accounts Effortlessly with OAuth 2.0"... The researchers examined 600 top U.S. and Chinese mobile apps that use OAuth 2.0 APIs from Facebook, Google and Sina -- which operates Weibo in China -- and support single sign-on for third-party apps. The researchers found that 41.2% of the apps they tested were vulnerable to their attack... None of the apps were named in the paper, but some have been downloaded hundreds of millions of times and can be exploited for anything from free phone calls to fraudulent purchases.
"The researchers said the apps they tested had been downloaded more than 2.4 billion times in aggregate."

Comments

tl;dr Summary

[Anonymous Coward]

I read the paper, here is my understanding:

In a normal OAuth2 transaction, the access token does not pass through the user's browser as app's site and identity (i.e. Google/Facebook). In a typical mobile app OAuth2, it proxies through the Facebook app for example and the access token passes through (but does not seem to be stored in) the device as it passes from identity site and app site.

Therefore, if an attacker can install an SSL MITM service on the device to capture all network traffic, it can obtain an access token. In web-based OAuth2, this is impossible because not all information passes through user's browser so even a malicious app on user's machine can obtain the access token to access provider's (i.e. Google/Facebook) information on the user.

You do need to compromise the mobile device to have the SSL MITM proxy. But, the attacker could be the user themselves, who could impersonate the app's backend servers to the identity provider (like Facebook). I'm not sure what damage, if any, that could cause.

The mobile identity provider app can remedy the situation by better validation of requests from client app and responses from its own backend server. SSL certificate pinning helps but there are ways to subvert that via tools on Android to disable it, or modifying the provider app itself.

Some notes:

* I didn't notice anything in the article (I could have missed it) that explained how reasonable it is for an attacker who is not the user to install an SSL proxy on a mobile device.
* I don't understand why they didn't say a remedy is not to have the identity provider backend send the access token directly to the app backend servers as it would in a web-based OAuth2, or why mobile apps do it differently.
* In one of their scenarios they propose it's possible to subvert protections against the SSL proxy by reverse engineering and installing a new version of the identity provider app (like Facebook app), but it seems to me if you can install arbitrary apps you wouldn't need the proxy as you could just modify the app itself send the token to the attacker.

That's the web version, not the app version

[raymorris]

That's how it commonly works for web sites - the third-party site uses the auth token to retrieve the user profile.

With mobile apps, the system is commonly made faster by returning the user profile along with the signed token. That works fine IF the app checks two things a) the signed token matches the profile and b) the signed token is in fact verifiably signed by the correct identity provider. Forgetting either check then leaves the third-party app vulnerable.