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?
- Without using obfuscating tools like HoseDex2Jar, people can easily reverse engineer the code in most Android applications.
- Sensitive data is being stored unencrypted on devices.
- 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.
You can read more about HoseDex2Jar here: HoseDex2Jar