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."
Very helpful to those who may be using them. Thanks guys!
“He’s not deformed, he’s just drunk!”
We, rather urgently, need to protect ourselves from your annexation.
What makes me think we even want you?
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.
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.
Most Americans can't find America on the map
Where's the moderation for "Sad but true"?
Nope, no sig
I voted Jill Stein.
"First they came for the slanderers and i said nothing."
of planets.
ahaha
Liberty freedom are no1, not dicks in suits.
Most Americans would rather die than actually use their brains.
Most Americans believe whatever their choice of "news" they choose to consume tells them.
Most Americans think that by hard work and diligence, they can get ahead.
Most Americans think they are living in a democracy.
Most Americans never visit other countries, and if they do, I'm ashamed of how they act for the most part.
Back on topic: Does anyone remember when Yahoo account credentials were the defacto "Single Sign on"? They didn't track failed logins, so it was fairly easy to bruit force an account.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
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.
They're talking about OpenId Connect and similar extensions.
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.
> People getting paranoid that their iPhones are putting them at risk can relax, (Maybe...).
Most assuredly not. Frequently the Android and iPhone versions of an app are compiled from the same source. If the source code doesn't include checking the that the user name matches the token, which OS happens to be three layers under that doesn't matter a bit.
If the app developer has two sets of source code, one for Android and one for iOS, and forgets the check in one copy, they probably forgot the check in the other copy as well.
In case you're completely unfamiliar with OAuth, here's a bad car analogy:
The researchers mounted 8 different GPS units made by Garmin, Tom Tom, and Magellan in their F-150. ...
Driving highway 1, six of the eight units
What if they put the GPS units in Chevy? It would make no difference.
It seems like you're trying to read a whole lot into one word in the summary. Linked in that summary is an entire paper which explains the details. However, it may not be understandable if you're not at least a little bit familiar with programming.
I've read and understood the paper. I'm a career internet security professional, so the paper makes perfect sense to me. I'm not speculating that the problem MIGHT be platform-independent, I'm letting you know it IS platform-independent. It's an easily missed requirement of the Facebook and Google APIs. (Not a *hidden* requirement, but an easy mistake to make of you're not being careful.) There's no six volt car in my analogy.
I've seen many implementations of OpenAuth in web apps. And everywhere I looked, one step was always missing. The verification of the token.
Token is a little XML fragment with information such as your e-mail address or public ID in the service that you are using for authentication. For example, Google authentication contains your gmail address, and Twitter has integer, if I remember right. And it contains the digital signature to ensure the token wasn't created in notepad. Websites will not try to check the signature in it, because all they need is presented in clear text. They choose the path of least resistance, so to say.
In truth, most small software companies usually don't have people who bother to understand OAuth. Large software companies may have such person. But the funny thing - these guys usually don't go further than mocking you on using other ways of authentication, blindly believing that their implementation of OAuth (downloaded from source-sharing website few years ago, at best) is god-given and immaculate. Their use of OAuth code snippets is like praying in Latin - they don't understand a fck about what they do, but it feels like Greater Power is taking a burden of thinking from them.