Projects/OWASP Mobile Security Project - Mobile Threat Model

PROJECT INFO What does this OWASP project offer you?

RELEASE(S) INFO What releases are available for this project?

what is this project? Name: OWASP Mobile Security Project - Mobile Threat Model (home page) Purpose: N/A License: N/A who is working on this project? Project Leader(s): Tom Eston @ how can you learn more? Project Pamphlet: Not Yet Created Project Presentation: Mailing list: Mailing List Archives Project Roadmap: View Key Contacts Contact Tom Eston @ to contribute to this project Contact Tom Eston @ to review or sponsor this project

current release ==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. Architecture Considerations Although mobile applications vary in function, they can be described using a generalized model as follows: Wireless interfaces Transmission Type Hardware Interaction Interaction with on device applications/services Interaction with off device applications/services Encryption Protocols What is the design of the architecture (network infrastructure, web services, trust boundaries, third-party APIs, etc) Carrier Data SMS Voice Endpoints Web Services RESTful or SOAP based Third Party (Example: Amazon) Websites 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 Amazon/Azure Corporate Networks (via VPN, ssh, etc.) Wireless interfaces 802.11 NFC Bluetooth RFID Device App Layer Runtime Environment (VM, framework dependencies, etc) OS Platform Apple iOS Android Windows Mobile BlackBerry Baseband Common hardware components GPS Sensors (accelerometer) Cellular Radios (GSM/CDMA/LTE) Flash Memory Removable Storage (i.e.- SD) USB ports Wireless Interfaces 802.11 Bluetooth NFC RFID Touch Screen Hardware Keyboard Microphone Camera Authentication Method Knowledge based Token based Biometrics Input Type Keyboard 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? Mobile Data 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. etc. 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 Human Interaction 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 Automated Programs 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:[1]http://venturebeat.com/2012/08/06/olympics-android-app/ Scripts executing at the browser with HTML5: Any script code written in a language similar to JavaScript having capability of accessing the device level content falls under this type of agent section. A script executing at the browser reading and transmitting browser memory data / complete device level data. 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. Attack’s Flowchart 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 Attack Scenario “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: Carrier Based Methods Man in the middle (MiTM) attacks which can steal data packets including SMS or voice packets Hijack wireless transmission. Endpoints based methods 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 Miscellaneous Methods 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. 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. What are the controls to prevent an attack? Defined by platform Apple iOS Android Windows Mobile BlackBerry What are the controls to detect an attack? Defined by platform Apple iOS Android Windows Mobile BlackBerry What are the controls to mitigate/minimize impact of an attack? Defined by platform Apple iOS Android Windows Mobile BlackBerry 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 Project Contributors Special thanks to the following team members who contributed to the initial release of the threat model: Tom Eston (Project Lead) Jack Mannino Sreenarayan Ashokkumar Swapnil Deshmukh Brandon Knight Steve Jensen Shimon Modi Rodrigo Marcos Brandon Clark Yvesmarie Quemener Yashraj Paralikar Ritesh Taank last reviewed release Not Yet Reviewed other releases