Back
Mobile Application Threat Modeling
Mobile Application Landscape
As mobile applications have become an integral part of everyday life, it’s hard to believe just how young the platform really is. When considering that seven years ago nobody has ever heard of iPhone or Android, and the first iPad came on the market a little over four years ago, it’s truly remarkable how quickly the technology was adopted by individuals and enterprises alike. People trust the mobile platform with their most intimate information such as credit cards, passwords, and other sensitive information, closely followed by enterprises that allow use of mobile devices for every business functions where use of the mobile form-factor is practical.
Value of understanding the overall threat posture
Looking over the results of several of our penetration tests of mobile applications, I realized that while many people understand and focus on the limitations associated with mobile, few people take time to think about similarities and security implications of the mobile technology. While limitations such as virtual keyboard, limited screen size, and limitations of the operating system take center-stage, security is often an afterthought, rife with weaknesses that would be plainly visible during a threat assessment.
Threat assessments are often ignored and misunderstood exercises that should be performed during the initial design phases of the development lifecycle. However, if you (like so many) were not given time for the threat assessment when you were designing the application, it’s not too late now. To help guide the process, I have provided a framework with which an application can be evaluated. This should be able to help facilitate further discussions and remediation of design flaws, which can potentially make the application exploitable to malicious users.
Mobile Infrastructure
While there are many examples of stand-alone applications, the majority of what I will focus on here will be mobile applications that communicate with one or multiple other servers. For those where a server component is not a factor, can simply focus on risks associated with mobile applications, which presents a much simpler problem. For most, however, mobile applications require communication with a back-end system, in most instances over an untrusted network. Therefore, when considering threats associated with the mobile application, it’s essential to remember the server components as well. While mobile applications by themselves provide a threat landscape similar to “typical” thick applications, web services providing the data feeds to the applications add a threat profile similar to a web-application. Additionally, since the two components of the mobile platform are inter-dependent, it’s also important to consider any business logic flaws (such as segregation of duties, regulatory compliance, and compliance with corporate policies), which may impact one or both components. With that understanding, let’s look at each one in more details…
Mobile Application Threats
When evaluating the security model for a mobile application, consider that at its core, it’s a thick application, with the addition of limitations unique to the Mobile platform:
Platform-specific vulnerabilities
While Blackberry and Microsoft mobile operating systems remain in use, for the purpose of illustrating the threat model I will focus on Android and iOS, as they are more common and represent the significant majority of mobile applications. When assessing mobile threats, it’s important to recognize the strengths and weaknesses of different platforms. For example, the ease with which Android applications can be reverse engineered should necessitate that the source code does not contain any information that may be considered sensitive, and require using stronger methods for protecting any certificates, passwords, or connection strings. At the same time, the ease with which iOS Keychain can be cracked to extract sensitive information may necessitate avoiding relying on the device for secure storage of anything that may allow a malicious user to gain access. When beginning to develop code for each platform, a detailed review of common weaknesses of each mobile operating system should be evaluated and considered when designing mitigating controls.
Single-user Platform
Yes, it’s obvious and self-explanatory, but when designing mobile software, it’s important to remember that most commonly, these are intended to be single-user devices. While the same user is “intended” to be the one in possession of the device at all times, the portable nature of the platform makes this an unreasonable expectation, require some form of a user-acceptable re-authentication each time the device is turned on. For those applications that are intended for multiple users, such as kiosks or other shared uses, additional precautions must be taken to ensure the system performs the necessary user identification, authentication, and authorization, as well as completely clears the session once the user is done (regardless whether the user logged out or the session has timed out)
Always Untrusted
There is really no other way to say it… assume anything typed into the application or the OS services providing security mechanisms can be compromised. While each mobile OS tries to provide application developers with controls that can provide several levels of security, Jailbreaking or Rooting the OS makes these controls unreliable. Even use of Mobile Device Management (MDM) technologies may not provide 100% assurance, though there are excellent ones hitting the marketplace every day. While use of tools like Fuzzers on a mobile platform may seem farfetched, remember that these applications can be loaded into virtual mobile device environments, where automation can be used to identify any available input validation flaw very quickly.
Limited UI & Screen
In order for controls to be effective, they must be easy to use. While the best way to authenticate the user is to prompt for username and password each time the application is opened, this may not be desirable if the application is frequently opened and closed.
Background Processing
Different operating systems handle this a little differently, but most allow applications to continue running, even after they are closed by the user or the device is turned off. Understanding the need to clear sensitive data from memory and storage between uses and ensure the data is not accessible from any other application may require development of additional mitigating controls.
Storage Encryption Challenges
Ideally, devices should never store any sensitive information or data. While onboard encryption and protection of encryption keys gets better with each Operating System release, key management challenges on a mobile platform become significant when considering the possibility of Jailbroken or Rooted device.
Web Services Threats
Web services are among the most common communication channels for mobile applications, and are a pivotal part of the security of the overall mobile application design. While it may be hoped that the Web Service will remain largely invisible, it’s discovery by a malicious user is inevitable, and should necessitate considering the following threats commonly associated with web applications.
Trusted Security Perimeter
If you consider the mobile application threats above, the Web Services provide a trust barrier between untrusted and trusted computing environments. Therefore, when considering threats associated with Web Services, it’s important to view the service layer as a critical component of the overall security strategy. In many instances this necessitates hardening of the server, tight firewall configuration in front of the interface engine, and ensuring that it’s running in the DMZ and does not have direct access to the internal network.
Limited Authentication Options
Ideally, each new session should be fully authenticated, including appropriate identification, authentication, and authorization of each device and user. However, considering the challenges associated with the usability and cryptographic storage within the mobile device platform, it’s important to design a comprehensive authentication and session management scheme that would resist common Man-in-the-Middle and other session hijacking attacks. Considerations such as mutual authentication may be necessary, depending on the sensitivity of the data managed by the application.
Input Validation
All inputs coming from the web application must be considered potentially harmful, and evaluated accordingly. Failure to properly sanitize input remains one of the most common application vulnerabilities, and web-services are not an exception.
Error Handling
When building a service to be used for mobile applications, developers often assume that error message handling is not necessary, since the service is intended to be used exclusively for one application. Improper error handling can results in sensitive information disclosure, and assist the attack by supplying information about the database and other inter-workings of the system.
Auditing & Logging
Most statutory and regulatory requirements, as well as security best-practices, require appropriate audit-logging to be implemented as part of the application. Therefore, it’s essential that the web service works together with the application to ensure all access to sensitive data and the application is logged.
Summary
Whether you are planning to develop a mobile application, or reviewing the security of an existing application, it’s never too late to perform a threat assessment. While specific threats will differ for each, the basic concepts described above should apply to the majority of applications, and help guide the process of understanding all mobile application threats.
