Lack of Security in Android Apps? That Could Be

Sunday, December 02, 2012

Keith Mendoza

Af9c34417f8e5e0d240850bb353b5d40

Have you ever installed an app in your Android phone and when you got to the permission screen you just couldn't justify to yourself why an app would require the permissions it's asking for? I have, and initially I thought it was just me until I ran into a white paper from Bit9 titled Pausing Google Play: More Than 100,000 Android Apps May Pose Security Risks. If you haven't freaked out yet, let me poke your side with this: this was based mostly on looking at the permissions the app is requesting at installation time.

They did not do any blackbox analysis of the apps themselves. Based on this, my experience reviewing code from a 3rd party mobile developer, and the type of questions that I've seen from some of the Android development forums out there, I don't even want to think how high that number would be. The white paper is geared more for enterprise IT professionals (like most of these things are), but it's an interesting read to help secure software developers in understanding the user landscape. What I really want to focus on is what can mobile developers do to help this disturbing trend.

Don't be permission happy

Make sure that you have fully evaluated whether your app really needs to use a particular service. Whenever you have to declare a new permission in the android manifest think first of whether you really need that permission. If you can't state exactly what feature needs a particular permission you're most likely doing something wrong, you're using the wrong Android API function, or worst using the wrong 3rd party tool or library.

Make sure to understand what you're using

Do you know where the data stored in the outState parameter of Activity::onSaveInstanceState() is stored? What is the lifetime of the data? When you save something in "Internal Storage" is it truly "private"? I once saw an app that stored the username and password in clear text. The developer claimed it was "safe" because it was stored in the file system using Context::openFileSystem() and they passed MODE_PRIVATE (which happens to be the default for this function) as the second parameter. Obviously the developer didn't know that ADB exposes the device's filesystem.

Make sure that a requirements document exists, and has been tested

I'm sure everyone understand the first part. We say and hear it more times than we bother to see if the moon is actually still there at night. The second part I can't think of the clearer way to state it, so let me explain a little bit. What I mean by the requirements has been tested is the requirements should have been reviewed from a QA perspective. There's more to secure software development than preventing buffer overflow, and preventing SQL injections. I believe that requirements play as large a part in securing an application than making sure that all inputs have been verified and being exception-safe.

The massive amount of effort and money being thrown in mobile app development is really just a variation of the same thing. People chasing the "next big thing". However, in this mad rush I hope that we learn the lessons of web 1.0 from a security perspective.

Cross-posted from Home+Power

Possibly Related Articles:
10111
Security Awareness
Information Security
malware Security Awareness Mobile Devices Android
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.