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

77 comments

  1. None of the apps were named by fustakrakich · · Score: 1

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

    --
    “He’s not deformed, he’s just drunk!”
    1. Re: None of the apps were named by Anonymous Coward · · Score: 1

      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.

    2. Re: None of the apps were named by AchilleTalon · · Score: 2

      The list is too long. They even may don't have a complete list anyway.

      --
      Achille Talon
      Hop!
    3. Re: None of the apps were named by chuckugly · · Score: 1, Funny

      Only apper apps can app you right in the app. Apps!

    4. Re: None of the apps were named by Sinesurfer · · Score: 1

      Identify which App Store(a) is/are affected or quit baiting me

      --
      Regards Sinesurfer A Nerd is someone who lives for technology, A Geek is someone who lives for technology and loves it
    5. Re: None of the apps were named by Anonymous Coward · · Score: 0

      I think the lesson here is, "don't use apps".

      The only thing your phone should be doing is providing credentials and displaying the returned information. Have hundreds of permutations of hardware and software run custom applications for every entity you interact with is completely insane. A web browser is already bad enough. Apps, are essentially very poorly vetted custom browsers, all of which may expose you to something that may install a rootkit.

      Use as little software as possible.

    6. Re: None of the apps were named by Anonymous Coward · · Score: 0

      You know, it's as if these people were supposed to be the bad guys. If they played a role in an old western, they should be wearing a black hat!

    7. Re: None of the apps were named by Anonymous Coward · · Score: 0

      Idiot

    8. Re: None of the apps were named by Anonymous Coward · · Score: 0

      American

    9. Re: None of the apps were named by fluffernutter · · Score: 1

      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.

      --
      Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
    10. Re: None of the apps were named by Kiwikwi · · Score: 1

      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 ways of solving this using OAuth, and OpenID Connect even adds the JWT mechanism, which is designed for thus use case... but apparently many apps don't take advantage of this.

      The same problem can easily happen on the desktop, if the third-party server trusts client-side JavaScript to do the OAuth process... and at least Google's developer docs specifically warns against that attack.

    11. Re: None of the apps were named by Kiwikwi · · Score: 1

      You can be the victim of this attack even if you don't own a smart phone. The attacker uses an app to attack the service... and the attack still works, even if the victim only uses the desktop version of the vulnerable service.

    12. Re: None of the apps were named by myowntrueself · · Score: 2

      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.
    13. Re: None of the apps were named by syntotic · · Score: 1

      Use as little software as possible? Yip, such IS the way Chinese think. Do not use it, if you use it do not use it, otherwise use it as little as you can, but better do not use it. There are reasons for such way of thinking, it is only Americans (?) who think Chinese think like Americans do (or think). Today I realized my Casio organ was still working in 2003 after being in use since I purchased it in 1980, years long daily then intermittently, but Arab friend who had all these things in store and not using them to protect them, well, by 1997 they were not working at all, from apple II to electric instruments. But that is the way Arabs and Indians think. People do seem to think nowadays that some idiot invented words like Occident, Orient, Middle East, Asia, Africa, America, Europe, Antiquity, Modernity... but it is all the same.

  2. Re:Hows the turnkey tyranny doing? by chipschap · · Score: 1

    We, rather urgently, need to protect ourselves from your annexation.

    What makes me think we even want you?

  3. Implementation not protocol by Wizarth · · Score: 4, Insightful

    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.

    1. Re:Implementation not protocol by XparXnoiaX · · Score: 1

      If only the implementation had been written as carefully as the specification. But it won't be, because companies are lazy.

      --
      Irresponsible disclosure is responsible
    2. Re:Implementation not protocol by Doub · · Score: 5, Insightful

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

    3. Re:Implementation not protocol by Anonymous Coward · · Score: 0

      It takes an special breed of retard to not validate a data structure that has a *signature*, and instead trust whatever is inside blindly. Unfortunately, this special breed is rather common, and its name is "the typical professional programmer". There is a difference between laziness and negligence.

    4. Re: Implementation not protocol by Anonymous Coward · · Score: 0

      I still don't understand the exploit. It seems to be a case where an app caches a user's information but relies on oauth for auth. I'm guessing it asks for only the password since this exploit would make no sense if it asked for your email. It then must do oauth behind the users back, and assumes that a valid auth response must be mean you logged in, and begins using the token given. I'm guessing this is the implicit auth flow.

      What I don't understand is how they can claim so many apps are affected when this is a clear misuse of OAuth 2. They also seem to be making assumptions about the implementation of a lot of apps.

    5. Re:Implementation not protocol by Anonymous Coward · · Score: 2, Insightful

      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.

    6. Re: Implementation not protocol by Tim12s · · Score: 1

      They likely dont validate a signature at a step which allows man in the middle.

    7. Re:Implementation not protocol by Anonymous Coward · · Score: 5, Insightful

      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.

    8. Re: Implementation not protocol by Anonymous Coward · · Score: 0

      OAuth 2 doesn't have a signature. This is all over https so presumably mitm is already very unlikely.

    9. Re:Implementation not protocol by Anonymous Coward · · Score: 1

      Your message should be to the people who can't explain how it works, not to me (the AC). :-)

    10. Re:Implementation not protocol by Wizarth · · Score: 2

      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.

    11. Re:Implementation not protocol by gravewax · · Score: 1

      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.

    12. Re:Implementation not protocol by Anonymous Coward · · Score: 1

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

    13. Re:Implementation not protocol by Anonymous Coward · · Score: 0

      I must confess to having a bot of a blind spot on this. I even watched a few training videos and I'm none the wiser.

      Can you explain it using Alice, Bob, and possibly a car or two?

    14. Re: Implementation not protocol by Anonymous Coward · · Score: 0

      Asking someone to explain something does not necessarily imply that the asker does not know how it works. (I am not the AC who has been asking people to explain OAuth 2.0)

    15. Re:Implementation not protocol by Junta · · Score: 3, Insightful

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

      --
      XML is like violence. If it doesn't solve the problem, use more.
    16. Re: Implementation not protocol by jrumney · · Score: 1

      This is all over https so presumably mitm is already very unlikely.

      Unless apps are trusting self-signed certs or something along those lines.

    17. Re:Implementation not protocol by fustakrakich · · Score: 1

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

      --
      “He’s not deformed, he’s just drunk!”
    18. Re: Implementation not protocol by Kiwikwi · · Score: 1

      Indeed. The attacker is running the app, and thus controls the list of trusted CA roots.

      The bug is in the third-party backend, which trusts the app to do authentication.

    19. Re:Implementation not protocol by ljw1004 · · Score: 1

      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 that concerned me. I had been going to use a middleware library for it but discovered the only value-add provided by that library was "let you use OAuth2.0 without worrying about how it works" but that, once you understand how it works, the middleware was actually more complicated than it was worth.

    20. Re:Implementation not protocol by Anonymous Coward · · Score: 0

      Alice tells Bob, "I'm a Car".
      Bob looks at her funny, but then shrugs and says "I guess you'd know".

    21. Re:Implementation not protocol by Anonymous Coward · · Score: 0

      A sysadmin is responsible for ensuring the machines and networks they manage are supported and secure.

      An application developer is responsible for ensuring their application is secure.
      Maybe the junior developer doesn't need to know the details, but the senior developer or technical lead definitely should - and should be able to tell their team exactly what the pitfalls to look out for are.

    22. Re:Implementation not protocol by Anonymous Coward · · Score: 0

      horseshit. by that measure SSL, HTTP, email, hell even basic telnet is too complex as they have all had many implementation specific vulnerabilities and problems over the years.

    23. Re:Implementation not protocol by Anonymous Coward · · Score: 0

      I deal with hundreds of developers every day. The vast majority are not even capable of understanding OAuth, they simply don't have the basic background to have a hope of comprehending it, hell most struggle with many of the basic concepts in HTTP or configuration of a web service, that doesn't mean they can't write code though. What these people can do is follow instructions (sometimes), So what we do is ensure our sysadmins are appropriately skilled and that our architects and security pros are also appropriately skilled. This gets over the problem by them being able to issue "thou shalt do's...." to every developer on the knowledge if they don't follow the advise they lose their contract. implementing Oauth, SAML/WS-Fed based federated/claims auth can be done effectively by simply following the bouncing ball and while it would be awesome if those doing that understood it, it is by no means a requirement in order to do it well.

    24. Re:Implementation not protocol by Anonymous Coward · · Score: 0

      While oAuth 2 (&Open ID connect) solve a bunch of problems they come across as very bound to the underlying HTTP protocol.
      im am sure this makes it faster and easer to implement than abstract cross protocol mechanism.
      personally I would like to see something closer to a top down Authentication and authorisation system that could be implemented using SMTP over carrier pigeon or TCP over Spooky action at a distance.

  4. Re:Hows the turnkey tyranny doing? by Anonymous Coward · · Score: 0

    "What makes me think we even want you?"

    I wonder how many in GCHQ would spy on Britain for FSB and help Putin put a pro-Russian leader into the UK PM seat, simply if their rules said it was their job. i.e. given the orders would they follow them at any and all costs?

    I think they would. I think cognitive dissonance means they'll tell themselves whatever story they need to, to justify it. 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.

  5. Re:Hows the turnkey tyranny doing? by phantomfive · · Score: 3, Insightful

    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."
  6. WHAT TIME IS IT CHILDREN? by Anonymous Coward · · Score: 0

    OAuth 3.0 time!

    1. Re:WHAT TIME IS IT CHILDREN? by Anonymous Coward · · Score: 0

      Nah, definitely time to invent some competing standard and fuck shit up even more.

  7. tl;dr Summary by Anonymous Coward · · Score: 3, Informative

    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.

  8. Re:Hows the turnkey tyranny doing? by fubarrr · · Score: 4, Funny

    Most Americans can't find America on the map

  9. Attacker MITM's their OWN device by raymorris · · Score: 5, Insightful

    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.

    1. Re: Attacker MITM's their OWN device by Anonymous Coward · · Score: 1

      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.

    2. Re:Attacker MITM's their OWN device by Anonymous Coward · · Score: 0

      I am more familiar with how it works with websites. For websites, you don't send anything identifying the user when requesting an OAuth 2.0 token.

      In the scenario where a user clicks "Sign in with Facebook" button on service FooBar:

      o FooBar creates a signature that includes the callback URI, OAuth version, FooBar's app key and secret (assigned by Facebook), a nonce, and Facebook's OAuth endpoint.
      o FooBar creates a POST request with the signature data to Facebook's OAuth endpoint.
      o FooBar is unaware of the user who is attempting to sign in at this point.
      o This next sequence depends on a few factors. Is the user presently signed in to Facebook? Has the user granted the FooBar service access?
      -- If yes to both, the user is redirected back immediately to FooBar service with their OAuth token.
      -- if no and yes, the user authenticates to Facebook before being redirected back to FooBar service with their OAuth token.
      -- If yes and no, Facebook presents the user with a dialog box to grant FooBar access to at least some portion of their account. If the user approves FooBar, they are redirected back to FooBar service with their OAuth token. If the user rejects FooBar, Facebook returns the user to FooBar without a token.
      -- If no to both, the user authenticates to Facebook and is then asked if they want to grant access to FooBar to at least some portion of their account.

  10. Re:Hows the turnkey tyranny doing? by Anonymous Coward · · Score: 0

    > I'm going to tell you something,

    Lol, phantom5 is gonna tell us something, gather 'round to hear the wise man spread the gospel from on high!

    Why is it that only the total whackjob conservotards say crap like that? Are you so authoritarian in your mindset that you believe self-aggrandizement is persuasive? I guess you probably do, it fooled you into voting for trump, master of telling people he's smart and his opinions are the best.

  11. Re:Hows the turnkey tyranny doing? by drew_kime · · Score: 1

    Most Americans can't find America on the map

    Where's the moderation for "Sad but true"?

    --
    Nope, no sig
  12. Re:Hows the turnkey tyranny doing? by phantomfive · · Score: 1

    I voted Jill Stein.

    --
    "First they came for the slanderers and i said nothing."
  13. they cant find earth in our system by cheekyboy · · Score: 1

    of planets.

    ahaha

    --
    Liberty freedom are no1, not dicks in suits.
  14. Re:Hows the turnkey tyranny doing? by buss_error · · Score: 1

    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.
  15. Re:Hows the turnkey tyranny doing? by Anonymous Coward · · Score: 0

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

    No, they care about the emails message Putin's hackers obtains, jazzed up with his propagandists and delivered by his strategists (which include Manafort, he worked with a Russian team to deliver Viktor Yanukovych's victory).

    Scaremongering is future tense. It isn't describing what happened in the past, all of the things in that sentence above, are exactly what happened with exactly the same people involved. It's a recorded documented history.

    It's something that so many of you are keen to shut down discussion of.

  16. That's the web version, not the app version by raymorris · · Score: 3, Informative

    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.

    1. Re: That's the web version, not the app version by Anonymous Coward · · Score: 0

      is that oauth 2 or is it openID, which uses oauth 2 (going to bed, not gonna look up)? I don't recall returning the user profile information part of the OAuth2 spec. In theory, a token derived of random values is sufficient for OAuth 2.

    2. Re:That's the web version, not the app version by fustakrakich · · Score: 1

      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.

      --
      “He’s not deformed, he’s just drunk!”
  17. MAJORITY voice by Anonymous Coward · · Score: 0

    The majority voted against Trump, you lot might want to conceal the Putin links, and I'm sure you'll cover his ass as he's signing away half the world to Putin, but why should the MAJORITY of Americans be silent?

    Fuck you, election rigging MINORITY traitors.

  18. One beeljon Windows Phones? by Anonymous Coward · · Score: 0

    W0t? There are 1 beeljon Windows phones?

  19. OpenId Connect amd similar by raymorris · · Score: 1

    They're talking about OpenId Connect and similar extensions.

  20. 40% of apps is a long list and they fixed it by raymorris · · Score: 2

    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.

    1. Re:40% of apps is a long list and they fixed it by fustakrakich · · Score: 1

      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.

      --
      “He’s not deformed, he’s just drunk!”
    2. Re:40% of apps is a long list and they fixed it by Anonymous Coward · · Score: 0

      I've got some irresponsibility right here, in the Summary
      "The researchers examined 600 top U.S. and Chinese mobile apps that use OAuth 2.0 APIs from Facebook, Google and Sina..."
      The original text:
      "The researchers examined 600 top U.S. and Chinese Android mobile apps that use OAuth 2.0 APIs from Facebook, Google and Sina..."
      Notice the difference? People getting paranoid that their iPhones are putting them at risk can relax, (Maybe...). But, why was the word "Android" excised? Short of actually listing a sampling of effected Apps, the one word that should _not_ have been edited out, was.

  21. Re:Hows the turnkey tyranny doing? by Anonymous Coward · · Score: 0

    Why is it that only the total whackjob conservotards say crap like that?

    Because you've defined anyone who doesn't immediately fall over and kiss Hillary's feet as a "total whackjob conservotard", and after calling everyone else names for one and a half years, you're still calling them names and blaming them for not being your best friend and supporting Hillary. And oh, look, the person you're insulting voted for Jill Stein. Maybe he or she would have voted Hillary if you had not worked so hard to chase him or her out of your group.

    But hey, you don't need to hear the truth, you can just plug your ears and screaming about "mansplaining" from the "privileged white misogynists" that should be ashamed of themselves and proud to join the group of voters that want to #KillAllWhiteMen.

  22. Mostly same apps have same vulnerability on iOS by raymorris · · Score: 1

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

    1. Re:Mostly same apps have same vulnerability on iOS by Anonymous Coward · · Score: 0

      I _am_ unfamiliar with the guts of OAuth, which is exactly why I stuck the (Maybe...) in there. But you are missing my point. The Editors chose to remove one critical word in their Summaries. This was not accidental and I believe the term that applies is FUD. This was badly reported and even worsely, (Yeah, I know- Not a valid Scrabble word.), edited bit of Slow Sunday Sensationalism.

      Now as for your truck analogy, make the Chevy Fifties era MGs instead, with a six Volt Positive Ground system. The GPS units can be cheaply re-engineered to work for that smaller pricier Market, stick in a Resistor or something if they bothered, or they could design from scratch for that smaller Market.
      "So six out of eight Garmin, Tom Tom, and Magellan GPS units in Ford Trucks catch on fire, (Chinese "16VDC" Caps...), thereby all GPS units will kill you.
      Except perhaps the ones that work just fine at 6 Volts, Positive Ground."
      But then somebody decided to edit the above as follows: "So six out of eight GPS units catch on fire." No mention of how, or why, or who is responsible, and who is not. I guess this keeps the Lawyers happy...

  23. There's a whole paper with details, more than TFS by raymorris · · Score: 1

    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.

  24. How Patchable? by Anonymous Coward · · Score: 0

    What I really want to know is, how patchable is this in the real world? What needs to be done and by whom? What could we expect in terms of delivering fixed code to, say, 80% of all users?

    If the problem is code in the mobile OS then this is bad news for Android. iOS gets reliably patched but Android, not so much. If the problem can be dealt with by the individual apps then that implies a better, more functional patch window.

    However with 600 mobile apps, including many popular apps, and that is only the apps reviewed... wow. What about apps that get little or no developer attention anymore? Those are going to be left in the lurch.

    No, I did not read the links in the OP. Those sites are probably fine, but I'm not a security specialist and I don't want the risk of visiting even relatively reputable 'dark side' sites, i.e. Blackhat. Apparently the Blackhat conferences are a veritable tornado of hacking activity, just as one relevant data point. I know my limits and this is one of them.

  25. Re:Hows the turnkey tyranny doing? by Anonymous Coward · · Score: 0

    OK, most Americans are Africans, Indians, Indians or Orientals or their mixes, so what did you expect?

  26. I can believe that by Mondor · · Score: 1

    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.