Mobile Application Security: New Platforms, Old Mistakes

Tuesday, January 24, 2012

Fergal Glynn

68b48711426f3b082ab24e5746a66b36

Article by Sam King

You don’t need me to point you to stories such as this New York Times article that reported on data from Flurry, a mobile analytics firm to convince you that mobile app usage is growing exponentially.

25B downloads at the end of 2011, a 300% increase year over year. I mean Angry Birds Rio was on the Christmas list for my 6 and 3 year olds – even Santa is not immune from this demand!

It is for this reason that we chose to include statistics from Android apps in our recently released State of Software Security report. The types of mobile apps our customers analyze are generally not the Angry Birds Rio kind but rather those that serve some commercial purpose.

It could be apps for their employees to interact with some enterprise system or apps they make available to their customers to transact financial information or manage healthcare records.

The figure below shows the distribution of Android apps submitted by different industry verticals. It is not surprising to see some of the top verticals due to the sensitivity of the data and transactions involved.

(click image to enlarge)

Our initial areas of focus for mobile apps has been Information Leakage (i.e. data exfiltration: transmitting potentially sensitive information off the device) and Cryptographic Issues.

The table below shows the prevalence of these flaw categories. Each of these categories has a couple of different CWEs represented within it.

(click image to enlarge)

While Android may be a new platform, some of the security issues we found are reminiscent of old mistakes we have seen developers make. One example of this was the practice of hard-coding cryptographic keys directly into the application.

Over 40% of Android apps contained at least one instance of this flaw, a higher rate than we observe across all non-Android Java applications (only 17% of all non-Android Java applications had at least one instance of hard-coded cryptographic keys).

Ironically, a hard-coded key is much simpler to extract from a mobile app than from a J2EE web application since the application can simply be copied off the mobile device! The problem is, once these keys are compromised, any security mechanisms that depend on the secrecy of the keys are then rendered ineffective.

Also with regards to Cryptographic Issues, 61% of Android apps exhibited at least one instance of Insufficient Entropy. In Java applications this usually takes the form of using the statistical random number generator (RNG) rather than the cryptographic RNG. It’s a common mistake seen frequently in Java web applications and can be fixed with a single line of code.

Under Information Leakage, nearly a third of Android apps were transmitting at least one piece of information marked as potentially sensitive. However, measuring the security of mobile apps is dependent on understanding the gap between design and implementation. For example, is it a privacy leak if an application is transmitting your GPS location?

If the application is FourSquare, probably not; sharing location information is core to its functionality. On the other hand, if the application is a flashlight app, then the use of GPS data may signify malicious behavior. Read more on this from my colleagues Chris Wysopal and Chris Eng in a recent Dark Reading Article, When Good Apps Go Bad.

Our recommendation to customers is to hold their mobile apps to the same security standards they apply to their enterprise apps. Learn from the common security errors we have seen developers make on older platforms and avoid those on newly authored mobile apps.

Cross-posted from Veracode Blog

Possibly Related Articles:
18782
Data Leakage Javascript Application Security Mobile Devices Android Analytics Cryptography Software Security Assurance Mobile Security VeraCode Sam King J2EE
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.