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."
If the protocol wasn't so uselessly complicated people could implement it right.
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.
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.