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

Implementation not protocol

[Wizarth]

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.

Re:Implementation not protocol

[Doub]

If the protocol wasn't so uselessly complicated people could implement it right.

Re:Implementation not protocol

[Anonymous Coward]

Apparently, the 2.0 protocol's history has been fraught with heated disputes over its very design, with key people distancing themselves from the result. So, maybe you don't know what you're talking about.

Re:Implementation not protocol

[Anonymous Coward]

This. One of the reasons I (as a sysadmin who understands protocols quite well, particularly HTTP) tend to shy away from things like OAuth 2.0 is because when I ask either front-end or back-end folks (or app folks) "so, can you explain to me how this works?", I have yet to encounter a single person who can actually explain it. Instead, the reaction is always: "look, it works, we use {Ruby gem XYZ,Python egg ABC,npm package HIJ}, who cares about the rest?". This is a mentality that troubles me greatly, and *not* how the same sector operated in 90s.

Re:Implementation not protocol

[Junta]

I think the issue for a lot of sysadmins is that trends have ultimately resulted in them losing the practical ability to manage what the software is doing security wise, but are still left accountable for mistakes. There is a great deal of pressure in the industry to be fast, and to be fast, just let the developers own deployment of their own software, enabling various technologies to let the 'user' be 'root' in some special domain to give them freedom.. However, somehow the admins continue to stay on the hook for problems that arise from how that software is deployed, despite having no control over deployment. So an admin in such a position is justified to quiz the developers to make sure *they* understand what they are doing to themselves, and perhaps lead them to more deeply understand the lego block modules they are haphazardly slapping together. Those modules are of widely varying levels of quality and commitment, and no good way to know at a glance if it's a wise decision to use them or not. Even when they are done well, any tool used incorrectly can lead to trouble. Of course, in these cases, the admin staff would take the heat, so they are actually making the correct call on their end, since they are shielded from those sorts of consequences.

I have seen a lot of this 'cobble stuff together' mentality. In my experience, nodejs is the worst (applications that on deployment just npm whatever the latest version of every little bit, and there are a *lot* of little bits people pull in because javascript core is missing so many builtins), though every language with a package repository suffers to some extent. There's no longer any time for test. People don't even mirror a known working copy of their libraries, instead just assuming latest is always greatest and never causes a problem, no matter how many times new problems smack them in the face.

That's not to say that there aren't a lot of good things in these trends, but there hasn't been enough interest in keeping the good bits of the way things used to work and *way* too much confidence in random anonymous peoples' development, support, and test skills and methodologies. If the developers are empowered, they should also be the ones to face consequences. The admin staff can be held accountable for the infrastructure bits they own, but generally speaking they have no real control over any facet of an internet facing service (in select environments, I do know a lot of places where the admins still manage things very thoroughly, much to the chagrin of the application owners).

Re:Hows the turnkey tyranny doing?

[phantomfive]

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.

Attacker MITM's their OWN device

[raymorris]

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.