Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Security Bug Cellphones Facebook Google Software

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

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."
This discussion has been archived. No new comments can be posted.

1 Billion Mobile Apps Exposed To Account Hijacking Through OAuth 2.0 Flaw

Comments Filter:
  • Very helpful to those who may be using them. Thanks guys!

    • by Anonymous Coward

      Very helpful to those who may be using them. Thanks guys!

      As usual they don't want to hurt anyones feelings.
      Name the "apps" or get lost.

      • 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? Every time you get a dialog message on your phone that says 'this app needs to access your information on site y, please acknowledge', that is oauth.
        • 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.

          The problem is that the third-party app goes through OAuth, and the third-party backend server then trusts the app when the app says "yup, I checked with Google/Facebook/whatever, and this is user so-and-so", even though the app is running in an untrusted context. There are various w

          • 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.

    • The list is too long. They even may don't have a complete list anyway.
    • Re: (Score:2, Funny)

      by chuckugly ( 2030942 )
      Only apper apps can app you right in the app. Apps!
    • Identify which App Store(a) is/are affected or quit baiting me

  • by Wizarth ( 785742 ) on Saturday November 12, 2016 @11:03PM (#53274099) Homepage

    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.

    • If only the implementation had been written as carefully as the specification. But it won't be, because companies are lazy [medium.com].
      • by Doub ( 784854 ) on Saturday November 12, 2016 @11:29PM (#53274155)
        If the protocol wasn't so uselessly complicated people could implement it right.
        • by Anonymous Coward on Saturday November 12, 2016 @11:59PM (#53274241)

          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.

          • Oauth 2.0 isn't all that complicated at all and to be honest it is you that should be going out and learning it not the developer. For most developers Oauth is just a library they have been told to use in order to secure their app, just like if you asked them what a syn/ack is they would also look at you dumbfounded. As a sysadmin you should be learning at least the basics of common simple protocols.
            • by Anonymous Coward

              > Oauth 2.0 isn't all that complicated at all

              I think this article proves conclusively that that's not true. At least it is consistently more complicated than what people can reliably implement.
              The security community really needs to stop blaming widespread security failures on people other than themselves.

            • by Junta ( 36770 ) on Sunday November 13, 2016 @09:13AM (#53275339)

              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).

            • by ljw1004 ( 764174 )

              Oauth 2.0 isn't all that complicated at all and to be honest it is you that should be going out and learning it not the developer. For most developers Oauth is just a library they have been told to use in order to secure their app, just like if you asked them what a syn/ack is they would also look at you dumbfounded.

              Strongly disagree. I think (1) every developer who incorporates networking code (directly or through a library) should always understand exactly what the network protocol is, and (2) it's conceptually impossible to "secure" your app by incorporating something you don't understand.

              Yes, I took two days out of my life to understand the OAuth2.0 for my web app. I didn't fully get to grips with the every possible OAuth2.0 flow; just the one that my app was going to use. I asked some security experts about bits t

        • by Wizarth ( 785742 )

          OAuth2 isn't uselessly complicated. OAuth (version 1) was, because they wanted to not require HTTPS, but wanted all the security mechanisms HTTPS would have provided. OAuth2 requires HTTPS, and removed the complex handshaking required in version 1.

      • Re: (Score:2, Insightful)

        by 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.

    • That still doesn't excuse not identifying who screwed up so we can purge the offending apps. Who are they protecting, and why?

  • tl;dr Summary (Score:3, Informative)

    by Anonymous Coward on Saturday November 12, 2016 @11:40PM (#53274195)

    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.

    • by raymorris ( 2726007 ) on Sunday November 13, 2016 @12:15AM (#53274273) Journal

      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.

      • by Anonymous Coward

        but you wouldnt know who the token is valid for until you use it to get the user information. normally you would present just the token and that's it. You never tell your email prior to authenticating with the OAuth provider.

        • by raymorris ( 2726007 ) on Sunday November 13, 2016 @02:47AM (#53274717) Journal

          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.

          • Forgetting either check then leaves the third-party app vulnerable.

            Yet these "researchers" are leaving the user in the dark by not identifying the apps. That makes their paper pretty useless.

            • 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 a

              • It's just as important, if not more so, that the users know if their apps are vulnerable. It is irresponsible not to inform them.

  • 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

In any formula, constants (especially those obtained from handbooks) are to be treated as variables.

Working...