For fuck sakes Google

Nieh and Viennot discovered all kinds of new information about the content in Google Play, including a critical security problem: developers often store their secret keys in their apps software, similar to usernames/passwords info, and these can be then used by anyone to maliciously steal user data or resources from service providers such as Amazon and Facebook. These vulnerabilities can affect users even if they are not actively running the Android apps. Nieh notes that even “Top Developers,” designated by the Google Play team as the best developers on Google Play, included these vulnerabilities in their apps.

Android isn’t secure? I’m shocked.

  • You think iOS is immune to secret keys in their apps? Developers can do dumb stuff on both platforms.

    • Wayner83

      But there is not easy access from anywhere on iOS to reach that information like it is on an Android.

      • Sure there is. Grab the IPA and take a look. It is nothing but a zip file.

        • TheMacAdvocate

          Amazing that we haven’t heard about thousands of iOS apps having the same problem. Oh wait: you’re the resident Google troll and it’s not surprising in the least.

          • So says the MacAdvocate. Surely you’re unbiased. 😉

            Yesterday I could have used that same argument saying “show me the thousands of apps on Android having this problem!” See how that argument falls flat on its face?

          • TheMacAdvocate

            So Google was a victim of…eventuality? Interesting tact.

            Here’s a statement to disprove: “Show me any apps on iOS that have this problem.”

          • If you look down just a couple comments below this one proving it:

            I look forward to your response to be proven wrong. 🙂

        • FYSZoso

          True, it’s nothing but a zip file. But correct me if i’m wrong, isnt ios a top to bottom encrypted os. It’s only easy to get to if you know the password. Or jailbreak it, for which you need physical access.

          • No, it isn’t encrypted top to bottom.

            For all of you who think iOS developers are somehow magically more intelligent, here is the FIFA app:

            I took a few minutes, downloaded 4 apps and on the fourth [FIFA] I found production key values.

            Now, how many of you will admit you were wrong?

          • No takers? I thought by now someone would man up and admit to being flat out wrong. @gjgustav:disqus? @unknwntrr:disqus?

            Ok…I’ll let it go. We can keep this between us.

    • I very much doubt Apple would admit an App containing a secret key to the App Store…

      • Sure they do. They don’t read every line of code.

        Trust me…they will and have.

      • John V.

        A “secret key” is just a piece of string somewhere in your code.

        Apple has no reliable way of detecting this, nor any reason to do it.

        What constitutes a secret key or not a secret key is entirely between the developer and their service provider.

        It’s very cute to think Apple can stop everything that’s considered a bad practice from their App Store, and they do catch a lot of things for sure. But this was never one of those, and never will be.

    • Anon Techie

      iOS devs have an option to “not do dumb stuff” called Keychain (on iOS). Super Secure (nothing is impossible to break).

      • Jailbreak the device and Keychain is easily broken. Android has the same secure storage option.

        But…let’s say jailbreak doesn’t happen. How does the secret info get put into the keychain? By code. Is it stored in an implementation file or are you downloading from a server?

        • John V.

          If you hash a secret key it’s about as good as useless for connecting to whatever you wanted to connect.

          The only sane choice is to proxy the service with a safe app-specific interface. Of course, the reason developers don’t do this is because it both requires extra development effort, and extra money to support the proxy hardware.

          • True on secret key. I was more talking about writing something to the keychain for later verification [ie – username or pin]. We use a hashing algorithm to store then on entry hash the entry the same way to verify the values, in essence.

        • gjgustav

          They keychain must be unlocked by the user. It is done via passcode. An app can not get access to the code so it can’t store it anyway. Any data stored in the keychain is then stored under the app’s domain. Another app can not read it, even if the keychain is unlocked.

          Of course, if your device is jailbroken, it’s possible to get a key-logger on your phone, I suppose, but this possibility is remote as most people don’t jailbreak their phones.

          Let’s face it, the likelihood of this happening on iOS, while technically possible, is far more remote than on a wide open system like Android.

          • Nope. It is just as possible. Again, Android has secure storage as well. People drop secret keys in objective-c all the time.

        • Anon Techie

          Jailbroken phones are solely user’s responsibility. Apple and App developers are not responsible for any of that.

          As I said, iOS devs HAVE an option. Doesn’t mean every iOS dev uses it.

          Otn a non-jailbroken phone with https for secure stuff over the internets and not having any of the credentials in the implementation or the interface, an iOS app is fully secure.

          Would the same option exist for an Android app?

          • As I said, Android devs HAVE an option. Doesn’t mean every Android dev uses it.

            Yes, the same option exists for Android.

  • John V.

    Sarcastic remarks that only reveal Jim’s ignorance? I’m shocked.

    Putting an API key in your app is not an Android thing. Developers on any platform can do it, and actually do it.

    Retrieving the keys on any of the platforms is trivial. Instead of making an ass of yourself, it’s always good to research an issue, Jim.

    • gjgustav

      iOS developers tend to use the keychain which is much more difficult to get the keys out of. Yes, I’m aware there are secure storage methods in Android. But the point of the article that Jim linked to is that they’re not using secure storage methods.

      Regardless, if you claim Jim is ignorant on the matter, please point us to an article showing where you find “thousands of secret keys” in iOS apps. iOS security breaches get way more press than Android ones, so if its as insecure, you must be able to show us.

      • John V.

        “Much more difficult to get the keys out of”.

        That’s nonsense. The Keychain is designed to protect user’s data from other users. It won’t protect the app data from the user.

        The secret key is shared between all instances of the app. Even if you obscure it in some “smart” way, all you need is to install the app on one jailbroken iPhone and all bets are off. You can sniff keys out the keychain, you can sniff network traffic going in and out, you can do anything.

        There’s no way to hide the keys, the only secure method is not connecting directly to services that need secret keys from your apps.

        Those researchers chose Android for purely practical reasons. For one, sure, it’s easier to hack into Google Play’s system. The platform is open source, various tools exist, the apps are easy to decompile and so on. The second reason is that on average, let’s face it, Android developers are less sophisticated bunch. You should expect a much greater yield of developers doing stupid shit from Android, than from iOS.

        However, app quality on iOS has been going down for a long time, the vetting process is less strict than it was, the game is about citing large app numbers these days, for both Google and Apple. And as a direct consequence, there are more and more iOS developers doing stupid shit in their apps as well.

        If you google “hide secret key ios” (no quotes) you’ll see people actively asking on forums how to “hide” their secret keys in iOS, a hopelessly insecure scenario as discussed. Many don’t even have enough clue to ask. They just proceed.

        • gjgustav

          Sorry. I was thinking of other users and other apps. Yes, you are correct – a user can get his own keys if they are stored in the keychain unmodified.

  • Gerard J
    • You might want to read articles you link to vs jumping on the “Google sucks” bandwagon. The anti-Google press [this blog included] jumped on one statement without posting the real point.

      This is from the article you posted by Sundar: “Android was built to be very, very secure. The thing that you’re seeing is because Android is an open platform, many people can ship Android in many different ways and so there are some partners when they ship devices, they have an older version of Android. And sure you can have a security vulnerability there, but that doesn’t mean Android isn’t secure. We go to great lengths–the depth of work in Android to make it secure; the depth of work done by Google Play…Google Play automatically scans and verifies thousands of applications for malware. We track data on this. It’s state of the art in terms of what we do. What you see across the ecosystem…people will ship good phones and keep them updated…you will have some phones that will not be updated. That’s where we see issues. Not Android at a fundamental level.”

      • John V.

        Well come on now, “at fundamental level” the fact Android’s licensing and distribution allows insecure stores, insecure apps and insecure handsets that ship with old Android software is part of what Android is. The very idea of iOS is to make the thing secure by default, so people who don’t patch kernels for fun in their free time can have a secure phone.

        When most of your users are instead sold lemon Android phones which just “happen” to be insecure and old, because “open” and because “the ecosystem”, this is a problem Google created because they put Android growth before the security of phone users. It didn’t happen out of nowhere.

        And sure, none of this has nothing to do with app secret keys, but still.

        • I disagree, to an extent. It isn’t, today, as big of old OS versions being sold. The problem is people not upgrading.

          I know someone rocking the original Evo!! I gave them major grief [all in good fun] but that’s why Gingerbread is hanging on. It isn’t because Gingerbread is still being sold.

          • Mother Hydra

            I’m just going through these comments and up-voting you like its reddit. Thank you for restoring balance to the galaxy.

          • LMBO. Thx.

          • gjgustav

            Balance? “But it’s technically possible to do this on iOS!” isn’t balance. Showing us thousands of iOS apps with easily retrievable keys is.

          • So your defense is “no one took the time to try this against iOS so it is more secure”?

            That’s like saying “my server is completely secure because no one has broken into it”…then…heartbleed.

          • gjgustav

            No. My defense is you can’t say iOS users are just as likely to have this problem without any evidence that developers are putting easily discovered keys in their iOS apps on an equivalent or larger scale than with Android apps.

            Remember the point of the article. The point is not what a security expert could do to either system, but what the common practice is amongst developers of either platform, and the likely effect on users.

            I never said iOS was bulletproof. I never said it couldn’t happen on iOS, I said nobody proved that this happens in iOS apps on a wide scale. Please understand the difference.

          • That’s even sillier. I know 100% for a fact developers on iOS do it because I have seen it first hand.

            Look, you can find any language with abilities to better provide secure keys to the language. You’ll also find posts from people saying “don’t put secure keys/passwords in your git repo” but you’ll STILL find devs doing it.

            When I don’t care about something, I do it too. It is VERY common.

            Just know…devs can be very lazy, yes…even iOS devs.

          • gjgustav

            I don’t deny that devs have done it on iOS. I’m saying it happens far less often on iOS, as is Jim’s point, and the article’s point. And if I was to recommend a platform based on this, I’d recommend iOS, by far. Until someone proves otherwise, there’s no point in discussing it further.

          • Jim had no point about iOS.

            LOL. Again, 6 months ago your web server was awesome and secure until you found out for the past few years it wasn’t. #heartbleed

            Just saying…ignorance [more so blindness/denial in this case] isn’t always bliss.

            Edit: Platform to platform, this changes nothing. Developers are the fault here…not the platform. That’s the point you cannot deny.

          • gjgustav

            I completely agree that your web server point is a great argument… for security. But I’m not arguing about technical security and neither is the article. I’m arguing the likelihood of people getting affected by the discovery of keys in apps. Please stick to the topic.

            As for Jim’s point, I can only say how I interpreted it. I interpreted an implied comparison. If you did not, fine. Who cares?

          • You missed it. My point isn’t to compare server to keys stored in an app. My point was to compare your “oblivion” argument: I haven’t seen it so it isn’t a problem.

            Who cares? No one.

          • John V.

            Many Android phones can’t be upgraded. Software updates for a given Android phone are typically abandoned with a year, year and a half. Many don’t provide any updates.

            An Apple handset comes with at least 3 years OS updates (when the new major OS is no longer supported, the older one still gets security patches).

            Unlike iOS, in many cases the existence of compatible Android upgrades is a function of some combination of the telco, the OEM and Google (and one of them usually craps out, so you get no update).

            It’s not like iPhone folks buy a new phone every year either, you know? Look deeper.

          • Gerard J

            My girlfriend and I purchased new phones around the same time a few years back. She got a Droid III and I got an iPhone 4s. She’s still stuck at the same version of Android (2.3 I think) and I’ve upgraded to iOS 7 and soon to be 8. She’ll never be able to update her Android version. That is true of most Android phones I know of and I don’t see that changing with the current plan of Google giving the base OS away, vendors hacking it to within an inch of it’s life and carriers having to certify the builds and put their own software on the phones. Apple’s ecosystem is FAR friendlier to keeping software up to date.

          • Thanks for proving my point. The Droid 3 is what…4 years old? She’s still using it vs upgrading every 1-2 years like iPhone users typically do.

            Google combats ODMs with bad upgrade cycles by pulling their services out and upgrading them on their own. It helps but security updates, etc don’t get down. KitKat was made to support lower-end devices, which is where most Gingerbread still lives, but even then those devices are too old for ODMs to care.

            Yes, iOS wins hands-down the upgrade war. Every I/O I hope to hear some amazing solution for Google to combat this.

          • Gerard J

            John… you point was vague as you simple said “people not upgrading” without identifying hard/software. I pointed out that most Android owner’s can’t upgrade their software, and not even “most” iOS users upgrade every two years since their older phones are still supported by software updates.

          • I didn’t realize I had to spell out all of the deficiencies in Android upgrades seeing as I went on to mention “ODMs with bad upgrade cycles” then “but even then those devices are too old for ODMs to care.”

            Formerly, Android upgrades were halted by 1) hardware incapable of running new versions of upgrades, 2) ODMs not motivated to upgrade phones [ie – forcing people to buy new phones], 3) new Android versions requiring too many resources [mid-higher end phones] to run properly so ODMs, for performance reasons, wouldn’t upgrade.

            There…I think I covered them all, in no particular order.

            Again, Google did wonders w/ KitKat by lowering the required specs and a ton of people have been upgraded to KitKat already and hopefully Android L** will show a faster upgrade cycle but we’ll see [not holding breath].

  • John

    My favourite part of the Nieh and Viennot report: 1/4 of the apps in the Play Store are clones.