Today's big security threat? Developer incompetence on your mobile app team


News: Today's big security threat? Developer incompetence on your mobile app team

  1. It would appear that the shorter development cycles and the rush to get up to speed on the latest mobile APIs is taking its toll on what would normally pass as standard development practices, and that's creating a massive problem that security conscious professionals should be severely worried about.

    I'd never code a username and password in plain text in a production system, and I'd certainly never allow sensitive information to be saved unencrypted on a device that I knew could be easily lost or stolen. Yet in the mobile development world, these inane practices seem to be commonplace, and the buck stops at the incompetent application developers who allow it to happen.

    At AnDevCon 2012 in San Francisco, TheServerSide spoke with Godfrey Nolan, founder of RIIS and author of both Decompiling Java and Decompiling Android, and he had some sobering insights into just how bad the security problem has become. Apparently, he’s been downloading, decompiling and doing some detective work on all sorts of Android applications, and in his short time sleuthing, he’s only run into a single Android app that he would consider to be properly secured. “Out of the hundred or so APKs that we’ve downloaded, we would say that only one was well protected, and everything else had information that was leaking or was available just in plain text if you reverse engineered the code.?

    And yes, I said ‘decompiling.’ It's incredibly easy to turn a downloaded Android app into its original source code and subsequently extract all sorts of interesting pieces of information, including access keys and security credentials. Of course, well developed source code wouldn’t reveal these tidbits of information, but that’s the problem. Developers are getting lazy, and organizations aren’t governing the development of Android applications properly, if at all.

    So what does Godfrey find to be some of the most common security gaffs nestled inside of those decompiled and inspected Android apps?

    1. Without using obfuscating tools like HoseDex2Jar, people can easily reverse engineer the code in most Android applications.
    2. Sensitive data is being stored unencrypted on devices.
    3. Code that communicates with back-end systems often includes plain text security credentials. That means your security problem is no longer people getting those embarrassing and X-rated images you've taken of your 'front end', but instead, they now have access to your entire 'back end' as well.

    So, what needs to be done? Maybe developers should start doing their jobs properly? There’s no doubt that living behind a firewall has made programmers lazy, but mobile devices break through the firewall every time an employee walks out of the building, and that changes the game. Encrypting data, not using plain text passwords in configuration files, and obfuscating code aren’t revolutionary ideas, and if developers don’t start doing this on their own, organizations are going to start oversteering the ship by putting in place extremely restrictive governance models that really restricts how a developer does their job, and this will hurt everybody.

    The Java ecosystem has taken some pretty hard hits with regards to its reputation as a secure computing platform over the past year or so. Let’s not give the Microsoft trolls and iOS fanboys even more anti-Java ammunition by having a high-profile organization hacked because of some poorly developed Android app source code. And besides, asking developers to do their jobs properly shouldn’t be too much to ask, and doing their job properly means taking basic steps to secure source code, application data and security credentials.


    Godfrey Nolan, quoted in this article, is the founder of RIIS, Research Into Internet Systems, and the author of both Decompiling Java and  Decompiling Android,

    You can read more about HoseDex2Jar here: HoseDex2Jar



    Threaded Messages (5)

  2. Android & password[ Go to top ]

    I'm wondering how you could save password in an encrypted way with Android. If you store the encryption key on the application, you can get it by decompiling the code and finding it. I think it's not a good idea to save any password on an Android device, encrypted or not, so we should use solutions as OAuth to save tokens instead of passwords. But then, if you save the token on the device, someone could steal the token and use it.

    How would you save something on the Android device in a secure way ?

  3. Right on the money[ Go to top ]

    I'm not an Android expert by any means, so I can't speak too intelligently to the technical aspect of your point. But indeed, these were the concerns many raised at the conference.

    I mention here not to release unobfuscated code, but many at the conference demonstrated how even obfuscated code could be fairly easily reverse engineered. And others demonstrated how after rooting a device, everything seemed to be open game, including tokens and encryption keys. Many people working for national security had some grave concerns that I never heard get adequately addressed.

    A good first start is at least making it hard to crack the device, and developers have a responsiblity to do due diligence at the very least. But your point is well taken.

  4. TheServerSide Rises Again...[ Go to top ]

    By the way, one thing I did hear often was purely virtualizing the experience, where *everything* was on the server. Currently the exeprience sucks with such approaches, but they seem to be the only approach that makes the device and data really secure.

  5. virtualizing the experience ?[ Go to top ]

    "virtualizing the experience"
    I'm sorry, I'm not sure I correctly understand your post. Are you talking about webviews looking like native apps ?

  6. What we're talking about here is the whole application and resources running on a server, and all the mobile client gets is a virtualized UI. Think of it like a remote desktop, except instead of a remote desktop, you have a remote smartphone UI. Everything stays on the server except the UI, so everything is secure, so long as nobody gets the device, and even if they do, usernames and passwords can be changed on the server as soon as a theft or loss happens. I think Citrix is doing interesting things in this space.