12 Basic Tenets of Mobile App Security: Part 3

Topics
Mobile, Security
Author
Mobiquity
Publication Date
12 February 2016

12 Basic Tenets of Mobile App Security: Part 3

To recap, we have thus far covered two of the four chapters on mobile app security, revealing eight of the twelve basic tenets for secure mobile app development and deployment. In the first two parts of the series, we focused on protecting the confidentiality and integrity of data, and preventing the threats associated with insider misuse of resources. Part 3 focuses on the celebrity of all vulnerabilities: the OUTSIDER THREAT. While the other tenets of the model all make good sense and help immensely in protecting the average mobile app and the data from being exploited, the outsider threat class is usually the one that makes headlines. And because mobile has become an ever more ubiquitous resource for almost every human out there, it’s also the class that tends to get over-hyped to generate good leads in the mainstream press.

[Full disclosure: I am writing this blog entry while watching Joshua “jduck” Drake present his findings in-person on the Stagefright exploit at BlackHat2015, so much of this information is coming straight from the source].

Case in point is the latest celebrity bug in Android, dubbed “Stagefright” (incredibly, this scary sounding name is not a codeword, but the actual name of the engine being exploited). Stagefright is a bug within the executing code of the Android operating system distributed to over 95 percent of its user base. This exploitation appears simple enough to invoke, using the right multimedia message (MMS video, animation, etc.) to crash the engine and bury some malicious shell code in the ensuing mess. The vulnerability being exploited here appears to be a series of poorly constructed code blocks dealing with allocation of memory, or rather the failure to properly allocate memory and handle errors.

 While the headlines scream "950,000,000 devices affected,” the fact is that there have been, to-date, exactly zero known real-world exploits using this technique (according to the head of Android Security’s “State of the Union” session earlier in the day). Why? Because as the mobile world has matured, so has the thinking around layered app security, and so has the cooperation between OS vendors, third-party app developers, and app security “bug hunters” like ‘jduck.’ This is a good thing, which continues to get better.

So without further ado, here are the next three of Mobiquity’s app security tenets:

9.      Know your attack surfaces to expose vulnerabilities to threats
10.    Model your threats and secure against them accordingly
11.    Monitor your security posture continuously

While a Stagefright hack has yet to occur, the vulnerability does highlight how important the first of the three tenets around outsider threats is: KNOWING your attack surface is critical to securing your solution. An Attack Surface is the sum total of the possible Attack Vectors, or exploitation points, through which an unauthorized user can gain entry or extract data from your application. Android and Apple continue to do a fantastic job of building out tools, processes and services to help protect against known and common Attack Vectors, but Stagefright belies yet another case where the Attack Surface was not properly defined - while the media file to crash the system could come from anywhere, MMS acted as an easy entry point because it’s a bit old and rarely used. This disregarded broken window in the Attack Surface of Android devices becomes an easy target for exploitation, and because it has existed for so long, the number of affected devices encompasses almost every Android device in the world today.

Defining your Attack Surface comes from diligent and iterative scrutiny of every possible attack vector within the scope of a product, a continuously evolving checklist of possible things that could go wrong in the deployment and execution of your app. This is sometimes known as Vector Enumeration, and the common ones for mobile center around:

  • Data storage locations
  • Data journey through the solution
  • Third-party frameworks built into the app
  • Communication path between app and backend services
  • Poor coding practices revealing test, debug or sensitive data in logs
  • Vulnerabilities in the platform itself
  • Physical access to the device through rooting or jacking
  • Reverse engineering of app packages
  • Weak validation of certificates or other communication entities

A comprehensive enumeration of the possible threat vectors within the above categories will create the Attack Surface.

Knowing the vectors of attack is not enough, however, as there are many possible paths an attacker may take to exploit, and this is where Attacker-centric Threat MODELING comes into play. Understanding not only the Attack Surface, but also the motivation, tooling and skillset of the attacker creates a set of threat models against which you can begin to assess risk and build mitigation strategies. These mitigation strategies are the counter-measures you employ against a potential attacker using one of the enumerated vectors.

And finally, because nothing is static in this ever-evolving world, it is mission-critical to continuously MONITOR, not only your application and supporting services, but also the evolving threat landscape. Applications are often released without the proper instrumentation to understand how the solution as a whole is performing or where the app is even running, and this can come at a serious cost. Android, for example, continues to improve on tools like VerifyApps and SafetyNet, tools that allow users to check apps against a known database and allow developers to profile devices to which their apps are being deployed to ensure they are properly configured. Developers can make use of these, and many other tools, to maintain a level of constant vigilance against common and new threats.

Much like uninformed users and misconfigured data storage and transport controls, outside attackers are not likely to go away anytime soon. There is significant value to being an attacker, either as a White Hat like Joshua Drake and so many others who diligently work through vulnerabilities and report on them for the benefit of the ecosystem, or as a Black Hat warrior who will steal your data, crash your services or highjack your application for blackmail money. It is therefore critical to enumerate the superset of possible threats to your solution, create models for each of them, design counter-measures to mitigate the risk, and continuously monitor both your solution and the changes in the outside threat landscape. Without doing this, you could be a feature presentation at BlackHat2016.

Coming up: Part 4 the final in this blog series on mobile app security, will explore the role of education in security.

Let our expertise complement yours

Leave your details below and we'll be in touch soon.