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.
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.
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.