Slashdot Mirror
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."
"The researchers said the apps they tested had been downloaded more than 2.4 billion times in aggregate."
Reading through the published paper, it's a flaw with the implementations, not the protocol itself, which is reassuring. It can be fixed by adding the missing checks, rather than having to replace OAuth2.
The list is too long. They even may don't have a complete list anyway.
Achille Talon
Hop!
I never thought GOP would work with Manafort, given his links to the Russian election strategists (and likely the hacks) and his involvement in the Ukraine takeover, yet they did exactly that
I'm going to tell you something, the average American doesn't care about Ukraine, or even Russia really, despite all the attempts at scaremongering in the last few months (the fact that the scaremongering didn't work is further evidence that Americans don't care about Russia).
Not only does the average American not care about Ukraine, they would also have trouble finding it on a map. Russia is easy because it's big.
"First they came for the slanderers and i said nothing."
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.
Most Americans can't find America on the map
The attacker doesn't need to man-in-the-middle the VICTIM'S device, they would MITM their OWN device. That is, I can pretend to be you by manipulating the traffic on my phone.
The TLS MITM stuff is really a distraction from the actual vulnerability, though. The real vulnerability is a couple flavors of the following:
I send a request to Facebook for an authentication token for my account, raymorris@slashdot.org. I get a valid authentication token, by which Facebook vouches that I really am who I say I am. I send that token to a third-party app, like this:
I am taco@slashdot.org and here's my Facebook authentication token affirming that I really am who I say I am.
The app checks that the token is valid, but doesn't check WHICH user it's valid FOR, and accepts it.
Other apps fail to check the validity of the token at all.
Because I've changed the token from "Affirmed, he is raymorris@slashdot.org" to "Affirmed, he is taco@slashdot.org", if the token is sent via TLS I have to MITM the TLS on my device, but that's a bit of a minor implementation detail.
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.
The researchers said two important things:
40% of the many apps they checked were broken.
They contacted the companies, who said they did/would fix it.
> That makes their paper pretty useless.
The paper is useful to app developers by telling them what prpblems to check for and fix in current apps, and avoid in future apps. It points out that framework and standards developers can reduce the risk by providing a known-good process. It's helpful to everyday users in that it points out that 40% (!!!) of apps are broken in this way, so you can assume app X is likely insecure, in this way or another way.
It would be only slightly more helpful to list some examples of specific apps which used to be vulnerable.
Almost everyone turned to oauth as the bastion of mobile security. You want a list of almost every mobile app that connects to a server?
This is not a protocol bug, but a common implementation bug in mobile apps relying on OAuth for authentication. So no, not "almost every mobile app that connects to a server" will be vulnerable... only all the poorly coded ones.
Right, so pretty much all of them then.
In the free world the media isn't government run; the government is media run.