| ==Mobile Application Threat Model - Beta Release==
This is the first release (February 2013) of the Mobile Application Threat Model developed by the initial project team (listed at the end of this release). Development began mid-2011 and is being released in beta form for public comment and input. It is by no means complete and some sections will need more contributions, details and also real world case studies. It's the hope of the project team that others in the community can help contribute to this project to further enhance and improve this threat model.
Mobile Threat Model Introduction Statement
Threat modeling is a systematic process that begins with a clear understanding of the system. It is necessary to define the following areas to understand possible threats to the application:
- Mobile Application Architecture - This area describes how the application is designed from device specific features used by the application, wireless transmission protocols, data transmission mediums, interaction with hardware components and other applications.
- Mobile Data - What data does the application store and process? What is the business purpose of this data and what are the data workflows?
- Threat Agent Identification - What are the threats to the mobile application and who are the threat agents. This area also outlines the process for defining what threats apply to the mobile application.
- Methods of Attack - What are the most common attacks utilized by threat agents. This area defines these attacks so that controls can be developed to mitigate attacks.
- Controls - What are the controls to prevent attacks. This is the last area to be defined only after previous areas have been completed by the development team.
Target Audience for the Mobile Threat Model
This model is to be used by mobile application developers and software architects as part of the “threat modeling” phase of a typical SDLC process. The model can also be used by Information Security Professionals that need to determine what typical mobile application threats are and provide a methodology for conducting basic threat modeling.
How to Use the Mobile Threat Model
This threat model is designed as an outline or checklist of items that need to be documented, reviewed and discussed when developing a mobile application. Every organization that develops mobile applications will have different requirements as well as threats. This model was designed to be as organizational and industry agnostic as possible so that any mobile application development team can use this as a guide for conducting threat modeling for their specific application. Real world case studies as examples will be integrated to this threat model in the near future.
Mobile Application Architecture
The mobile application architecture should, at the very least, describe device specific features used by the application, wireless transmission protocols, data transmission medium, interaction with hardware components and other applications. Applications can be mapped to this architecture as a preliminary attack surface assessment.
Although mobile applications vary in function, they can be described using a generalized model as follows:
Interaction with on device applications/services
Interaction with off device applications/services
- What is the design of the architecture (network infrastructure, web services, trust boundaries, third-party APIs, etc)
- Web Services
- RESTful or SOAP based
- Third Party (Example: Amazon)
- Does the app utilize or integrate the “mobile web” version of an existing web site?
- App Stores
- Google Play
- Apple App Store
- Windows Mobile
- BlackBerry App Store
- Cloud Storage
- Corporate Networks (via VPN, ssh, etc.)
- Wireless interfaces
- App Layer
- Runtime Environment (VM, framework dependencies, etc)
- OS Platform
- Apple iOS
- Windows Mobile
- Common hardware components
- Sensors (accelerometer)
- Cellular Radios (GSM/CDMA/LTE)
- Flash Memory
- Removable Storage (i.e.- SD)
- USB ports
- Wireless Interfaces
- Touch Screen
- Hardware Keyboard
- Knowledge based
- Token based
- Input Type
- Touch screen
- Hardware peripheral
- Decision Process
- Local (on device)
- Remote (off device)
- Define app architecture relative to OS stack + security model
- What should or shouldn't the app do?
This section defines what purpose does the app serve from a business perspective and what data the app store, transmit and receive. It’s also important to review data flow diagrams to determine exactly how data is handled and managed by the application.
- What is the business function of the app?
- What data does the application store/process (provide data flow diagram)
- This diagram should outline network, device file system and application data flows
- How is data transmitted between third party API’s and app(s)
- Are there different data handling requirements between different mobile platforms? (iOS/Android/Blackberry/Windows/J2ME)
- Does the app use cloud storage APIs (Dropbox, Google Drive, iCloud, Lookout) for device data backups
- Does personal data intermingle with corporate data?
- Is there specific business logic built into the app to process data?
- What does the data give you (or an attacker) access to
- Data at Rest
- Example: Do stored credentials provide authentication?
- Data in Transit
- Example: Do stored keys allow you to break crypto functions (data integrity)?
- Third party data, is it being stored/transmitted?
- What is the privacy requirements of user data
- Example: UDID or Geolocation on iOS transmitted to 3rd party
- Are there regulatory requirements to meet specific to user privacy?
- How does other data on the device affect the app (sandboxing restrictions enforced?)
- Example: Authentication credentials shared between apps
- What is the impact of Jailbroken/Rooted vs Non Jailbroken/Rooted device and how this affects app data (can also relate to threat agent identification)
Threat Agent Identification
What are the threats to the mobile application and who are the threat agents. This area also outlines the process for defining what threats apply to the mobile application.
Identifying Threat Agents
The process of identifying a threat agent is very simple and have been mentioned in the below steps:
S1: Take the list of all sensitive data (or information to protect) listed down from Section 2 – Mobile Data
S2: Make a list of all the ways to access this data
S3: The medium used to access the same listed in S3 is the Threat Agent to be identified
Threat Agent Identification Example
Let us understand it in a better way using an example of a Financial Application (specifically a Banking Application). Following the process as mentioned above:
S1: Sensitive data present in the application has been listed as: Beneficiary Details stored in some form in the Phone Application Memory and User Credentials used for authentication transmitted to the server.
S2: List the various ways of accessing information:
- Beneficiary Details:
- A device user aiming to browse through the memory card / phone memory
- An adversary using a jail broken phone; starts reading the content through putty/WinSCP via SSH
- An adversary while sniffing the WiFi, traffic sniffs the content travelling through the network
- Another malicious application while reading the phone memory contents, stumbles upon this data as the device is Jailbroken
- Another application which is sending data through SMS sends this data.
- A Web Application executing a script on the browser tries to get steal the phone memory and send it to its server.
S3: From the above points, we list down the medium used:
- Any user who has the device (Stolen device/ friend / etc)
- Any malicious application (installed / Web based script)
- An adversary sniffing the Wifi.
From the above example you should have a clear picture on how to identify Threat Agents. Below is list of threat agents, which were identified while analyzing various commonly used applications.
Listing of Threat Agents - By Category
- Stolen Device User: A user who obtained unauthorized access to the device aiming to get hold of the memory related sensitive information belonging to the owner of the device.
- Owner of the Device: A user who unwillingly has installed a malicious application on his phone which gains access to the device application memory.
- Common WiFi Network User: This agent is aimed at any adversary intentionally or unintentionally sniffing the WiFi network used by a victim. This agent stumbles upon all the data transmitted by the victim device and may re-use it to launch further attacks.
- Malicious Developer: A human user who has the intent of writing an application which not only provides a commonly known function like gaming / calculator / utility in the foreground but steal as much information from your device as possible in real-time and transmits it to the malicious user. This agent can also be looked at an angle from which he codes an app to perform DOS by using up all the device resources.
- Organization Internal Employees: Any user who is part of the organization (may be a programmer / admin / user / etc). Anyone who has privileges to perform an action on the application.
- App Store Approvers/Reviewers: Any app store which fails to review potentially dangerous code or malicious application which executes on a user’s device and performs suspicious/ malicious activities
- Malware on the device: Any program / mobile application which performs suspicious activity. It can be an application, which is copying real time data from the user’s device and transmitting it to any server. This type of program executes parallel to all the processes running in the background and stays alive performing malicious activity all the time. E.g. Olympics App which stole text messages and browsing history:http://venturebeat.com/2012/08/06/olympics-android-app/
- Malicious SMS: An incoming SMS redirected to trigger any kind of suspicious activity on the mobile device. There are multiple services which keep running in the background. Each of these services have listeners which might be active to listen for the content of an incoming SMS. An SMS message may be a sort of trigger for the service to perform some suspicious activity.
- Malicious App: Failure to detect malicious or vulnerable code and the likelihood of a compromise or attack against the app store itself, potentially turning legitimate code into hostile things including updates and new downloaded apps.
Below is a diagram illustrated to understand the Threat Agents and Threats in a visual manner:
Figure 1 : Pictorial Representation of Threats and Agents
Methods of Attack
In this section, we will observe different methods an attacker can use to reach the data. This data can be sensitive information to the device or something sensitive to the app itself.
Destruction of the asset is normally classified as attack. Attack can be further categorized as a planned attack or an unplanned one. Unintended attacks are normally caused due to some form of accidental actions.
Figure 2: Attack Workflow
“Method aimed to read the local application memory”
The above mentioned attack methodology is the one in which the data which is targeted is application specific memory and the method used is memory based analysis. The attacker steals any sensitive data like passwords, userid, user account information which is stored in the application memory by reading the device memory.
We have listed down other methods below which can be mapped with the second section in a similar fashion:
The classification of attacks based on the way data is handled:
- Man in the middle (MiTM) attacks which can steal data packets including SMS or voice packets
- Hijack wireless transmission.
- Inject code to tamper with web application or web services
- Many of the OWASP Mobile Top 10/OWASP Web Application Top 10
- Publishing Malwares in the app store
- Stealing user sensitive phone contents using Malwares
- Cloud storage
- Targeting malicious corporate network. (e.g. VPN Keys, etc)
- Wireless interfaces based methods
- Stealing data when its in-transit using wireless channel like 802.11, NFC based data exchange or Bluetooth based data exchange. Application Level Attacks
- OS and application level methods
- Exploit the Input validation on client-side by by-passing the checks
- An adversary steals sensitive data by reading SD Card based stored content
- Exploiting vulnerabilities within an app or runtime environment. (VM, framework dependencies, etc)
- An adversary exploits OS level functionalities steal data from device or server
- Rooting or Jailbreaking the phone to access sensitive data from memory
- Method used to exploit and steal GPS based signals which falls in users personal information
- Method used to exploit the flash memory
- Method used to perform “tap jacking” based attacks.
- Method used to steal keyboard cache or logs.
- Method used to steal microphone recordings of a user
- Method used to exploit and misuse the camera functionality.
What are the controls to prevent attacks. This is the last area to be defined only after previous areas have been completed by the development team.
- What are the controls to prevent an attack?
- Defined by platform
- Apple iOS
- Windows Mobile
- What are the controls to detect an attack?
- Defined by platform
- Apple iOS
- Windows Mobile
- What are the controls to mitigate/minimize impact of an attack?
- Defined by platform
- Apple iOS
- Windows Mobile
- What are the controls to protect users private information (privacy controls)
- Example: prompts for access to address book/geolocation
- Create a mapping of controls to each specific method of attack (defined in Section 4 – Methods of Attack)
- Create level of assurance framework based on controls implemented. This would be subjective to a certain point, but it would be useful in guiding organizations who want to achieve a certain level of risk management based on the threats and vulnerabilities
- Case studies, control examples
Special thanks to the following team members who contributed to the initial release of the threat model:
Tom Eston (Project Lead)