The purpose of this article is to provide security guidance in the development of mobile applications. The following application threat-model (ATM) is an example, created to help developers identify potential threats that a malicious attacker could use to exploit a custom developed Mobile Application. This threat model example is based on Industry Best Practices and observations across the Mobile Application Development space, and is not based upon any one particular mobile application. The scenario presented here assumes an application in the Banking and Finance space, but could be any industry.
From a Security and Privacy perspective, a mobile application must:
- Prevent the un-authorized use of web service API associated to the related application
- Prevent the accessibility of information or operational control of a user’s account
- Prevent the ability for a third party to gain identification and authentication details
- Reduce the opportunity or intention of a malicious user from accessing confidential information
Threat Profile:
A "Threat Profile" is the concept of identifying the complete set of security threats that could be used to compromise a given application or system.The following Business Criteria and assumptions were used when assessing the threat profile for this example Mobile Application:
- Industry Categorization Financial Institution
- Organizational Audience Business Users
- Level of Potential Threat to Audience Moderate-threat Audience
- Degree of Confidential Data Moderate
- Likelihood of Exploitation Low to Moderate
- Delivery Platform Mobile devices with Secured Sandboxes
- Level of User Interaction Minimal
 |
| SANS: Threat Profiling |
Threat Agents:
A threat agent categorizes the types of intentional and unintentional users associated to the system. This can include, but does not require, the intended roles of the application.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.
- Access to account information to perform unauthorized transactions
- Access to account information to perform transactions from a different account
- Attempt to garner information about the banks overall security structure
- Denial of service attack against back-end systems based on gathered information
Owner of the Device: A user who has unwittingly installed a malicious application on their phone which gains access to the device application memory.
- Capturing of credentials associated to the account for use by third party
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.
- Capturing of credentials associated to the account for use by third party
- Ability to perform unauthorized transactions
Key Scenarios:
The following scenarios or activities have been identified as key to the success of the application's security profile:
User Authentication - to gain access to post-sign-on functionality and content on the Mobile application.
Get Portfolio and Rates, and Execute Trades - User being presented with the list of transactions associated with specific Rates (Wire Payments, Cross-currency Account Transfers). The User could retrieve, view and accept the rate presented for selected payment. The User could view Beneficiary Details and the Audit History Page of the selected payments. The User could manage Contacts and make phone calls using the Audit History information.
Payment Approvals - User being presented with the list of payments (Wires, Account Transfers, EFT, Bill Payments) that qualify to be approved/released by the user. The User could view payment details and approve/reject selected payment. The User must be re-authenticated as a part of each payment approval operation. The User could view Audit History Page of the selected payments. The User could manage Contacts and make phone calls using the Audit History information.
Accounts Module - User being presented with the list of accounts he is entitled to. The User could add/delete/change order of Favourites Accounts in the list. The User could query and view account balances and transaction history information.
Mobile Application Architectural Elements:
The following items are associated to the application architecture specific to mobile devices. This listing mechanism is intended to provide additional input and consideration into the overall threat model.1.Carrier Elements
|
5.Device
|
| 2. Web Services using RESTFUL agents over SOAP | 6.Common applicable hardware components
|
3. App Store
|
7. Authentication
|
4.Wireless Interfaces
|
Planned Application Security Mechanisms:
Planned application security mechanisms are technologies and threat-management measures that are included in part of application architecture and design. The model ignores these when defining the potential threats associated to the system but references them as solutions to identified problems.
The following application security mechanisms have been identified as part of application security design:
An organization and its application define a series of perimeter that define different levels of security-oriented trust. The following information defines the trust boundaries associated with systems, sub-systems, and identities.
App Container Boundary within secure devices including iPhone and BlackBerry
Internet Trust Boundary is the connector between the device and internal banking systems
DMZ Trust Boundary including perimeter firewall where core services are located
Data Center Trust Boundary in which direct hosted systems and services are located.
Data Flows:
Data flow diagrams help document the flow of information across trust boundaries.
Understanding how data is communicated across boundaries help identify potential issues within communication protocols and mechanisms.
The following diagram represents the data flow of the application under investigation
The following application security mechanisms have been identified as part of application security design:
- HTTPS secure transportation protocol using TLS 1.2 or above
- Two-phase authentication
- Input and data validation
- Exception handling
- Auditing and logging
- Minimization of operations
Trust Boundaries:
App Container Boundary within secure devices including iPhone and BlackBerry
Internet Trust Boundary is the connector between the device and internal banking systems
DMZ Trust Boundary including perimeter firewall where core services are located
Data Center Trust Boundary in which direct hosted systems and services are located.
Data Flows:
Data flow diagrams help document the flow of information across trust boundaries.
Understanding how data is communicated across boundaries help identify potential issues within communication protocols and mechanisms.
The following diagram represents the data flow of the application under investigation
Entry and Exit Points:
Entry Points
Entry points define the positions in your application where a user, cross-component communication or external application supply data and call operations associated to the back-end systems.- Mobile Application access to back-end API through JSON services.
- Unintentional direct access to back-end API through JSON services.
Exit Points
Exit points are relationships to entry points and define the positions in which data is sent to the client. Exit points are prioritized to identify where information is transmitted in a trusted manner but the source is untrusted.Potential Attack Tree:
An attack tree is a hierarchal diagram (or outline) that represents the attacks a malicious individual might perform against the application. This information is based on the development of an attack profile organized around the industry and type of threats associated to your application and end users
Gain authentication information to be used in other applications, systems or services
Monitoring of transactions to record communication patterns
General financial fraud
Data Collection by running application in a non-trusted environment (jail-broken)
Unmanaged JSON attacks over encrypted or unencrypted channels
- Authentication and access control attacks to determine applied security measure
- Determine the depth of breach and fraud preventive controls
- Access account to be used on other systems
Monitoring of transactions to record communication patterns
- Obtain confidential information about the system
- Gain details on how transactions are processed in the system
- Discovery of weaknesses associated to the back-end system
General financial fraud
- Perform unauthorized financial transactions to correct associated bank accounts
- Determine clients and size of transactions for social engineering attempts
Data Collection by running application in a non-trusted environment (jail-broken)
- Ability to access the application in a jail-broken device or development platform
- Ability to apply memory forensics on the application at runtime to gain confidential information
- Ability to apply memory forensics on the application to determine run-time details
Unmanaged JSON attacks over encrypted or unencrypted channels
- Ability to perform data theft through cross-site references
- Ability to perform a denial of service attack using cross-site references
Threat Tree:
A Threat Tree describes specific threats that can be applied to the application. Information in this section is defined in a threat-based tree for reference and specific descriptive afterwards. Please note that a single threat can be related to one or more common or uncommon vulnerabilities.- Authentication / Authorization
- Input and Data Validation
- Relying exclusively on client-side validation
- Writing data you did not validate out to trusted source
- Using input you did not validate to generate SQL queries
- Configuration Management
- Sensitive Data
- Basic Man-in-the-Middle Attack
- Request Forgery
- Session Management / Cryptography
- Parameter Manipulation
- Failing to validate all input parameters.
- Exception Management
- Failing to validate all input parameters
- Audit and Logging
- Missing Security Auditing Features
- Unsecured Audit Logs
- Mobile Specific Threats
- Method aimed to read the local application memory
- Malware on the device
- Transactions performed from non-localized location
Rating Potential Threats:
Relying Exclusively on Client Side Validation:
| Threat Description | By relying on client-side validation the system allows for exposure of the back-end services through compromised client systems as well as communication protocols. This issue includes common assaults results including “Writing data you did not validate out to trusted source” and “Using input you did not validate to generate SQL queries” |
| Category | Input and Data Validation |
| Threat Target |
|
| Risk | High |
| Attack Techniques | A malicious attacker compromises the mobile application by installing it on a jail-broken device or reviews data communication though a proxy service. Unintended information (pre or post authentication) is sent through the communication protocol to the back end server containing injection data or unintentional information. |
| Countermeasures |
|
Basic Man-In-The-Middle Attack:
| Threat Description | User is able to monitor the data being communicated from the mobile application to the associated server in order to determine the URL, formats and identity of back-end services for direct access to the service. |
| Category | Sensitive Data |
| Threat Target |
|
| Risk | Medium |
| Attack Techniques | Use of data monitoring tools including BURP Scanner or WireShark as proxies to view data being transmitted from the mobile application to the server. |
| Countermeasures |
|
Request Forgery:
| Threat Description | An unauthenticated user sends requests through HTTP protocols in an attempt to (1)subvert authentication mechanisms, (2) perform destructive activities against a system, (3) gain information around exception handling mechanisms, or to (4) garner information about the system and its transactions |
| Category | Sensitive Data |
| Threat Target |
|
| Risk | Medium |
| Attack Techniques | Use of data monitoring tools including BURP Scanner or WireShark as proxies to view data being transmitted from the mobile application to the server. |
| Countermeasures |
Use of a secure token (similar to a CSRF token) to acknowledge authorized transactions to the system and to take appropriate measures including alerts and logging when un-authorized transactions are performed. The same mechanism used in a CSRF token can be used in this circumstance.
|
Missing Security Audit Features:
| Threat Description | Attacks by an unauthorized user is not properly documented by the system reducing the opportunity for breach attempts to be discovered, hindered or prevented. From a security practice audits and logs should be applied across application layers and servers. |
| Category | Auditing and Logging |
| Threat Target |
|
| Risk | Low |
| Attack Techniques | This threat does not have a direct attack; it represents an inability to detect and manage the assault in the case of a breach. |
| Countermeasures |
|
Unsecured Audit Logs:
| Threat Description | Once a breach has occurred, a malicious attack will attempt to alter or remove log files that demonstrate their attempts. This is a common step for an attacker in a breach to reduce the chance of success for a forensic investigation. |
| Category | Auditing and Logging |
| Threat Target |
|
| Risk | Low |
| Attack Techniques | Upon a system breach the attacker will modify or delete the associated log files so evidence of their activities are removed. |
| Countermeasures |
|
Method to Read Local Application Memory:
| Threat Description | In this attack methodology, the data targeted is application specific memory and the method used is memory based analysis. The attacker steals sensitive data like passwords, userid, user account information which is stored in the application memory by reading the device memory. |
| Category | Mobile Specific Threats |
| Threat Target |
|
| Risk | Medium |
| Attack Techniques | Through development or forensic tools on the device or using a developer workstation, the system and application memory is reviewed while the application is running to determine how information is stored, communicated and its residual nature. |
| Countermeasures |
|
Malware on the Device:
| Threat Description | Any program / mobile application which performs suspicious or unauthorized 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. On a Jail-broken phone this can include access to the applications memory, buffer overflow threats |
| Category | Mobile Specific Threats |
| Threat Target |
|
| Risk | Low |
| Attack Techniques | Often malware is installed on a device through unintentional means where the malware itself is a Trojan or worm that is embedded in a useful application. Once installed the application slowly consumes and analyzes other applications in the device. Malware is most often found on Jail-broken phones in which non-App store related applications have been installed. Malware is often not a targeted attack but attack by drawing. |
| Countermeasures |
|
Transaction Performed from Non-Localized Location:
| Threat Description | An unauthorized user attempts to perform a transaction from a distributed location with the goal of applying a fraudulent action. This may include a single or multiple financial transactions |
| Category | Mobile Specific Threats |
| Threat Target |
|
| Risk | High |
| Attack Techniques | An individual using a stolen device or perform a transaction from a distributed location (uncharacteristic of the user) is able to perform multiple transactions |
| Countermeasures |
|
Threat Risk Rating:
Threats are rated into three categories (Low, Medium and High) based on their DREAD rating. The individual elements associated to this rating are as follows:- Damage potential: How great is the damage if the vulnerability is exploited?
- Reproducibility: How easy is it to reproduce the attack?
- Exploitability: How easy is it to launch an attack?
- Affected users: As a rough percentage, how many users are affected?
- Discoverability: How easy is it to find the vulnerability?
Threat
|
D
|
R
|
E
|
A
|
D
|
Total
|
Rating
|
| Basic Man-in-the-Middle Attack |
2
|
3
|
3
|
1
|
2
|
11
|
Medium
|
| Request Forgery |
2
|
3
|
3
|
1
|
2
|
11
|
Medium
|
| Relying exclusively on client-side validation |
3
|
3
|
3
|
1
|
3
|
13
|
High
|
| Missing Security Audit Function |
1
|
1
|
1
|
1
|
1
|
5
|
Low
|
| Unsecured Audit Log |
1
|
1
|
1
|
1
|
1
|
5
|
Low
|
| Method aimed to read the local memory |
2
|
1
|
2
|
1
|
2
|
8
|
Medium
|
| Malware on the Device |
1
|
1
|
1
|
1
|
1
|
5
|
Low
|
| Malicious App |
1
|
1
|
1
|
1
|
1
|
5
|
Low
|
| Transactions from non-localized location |
3
|
3
|
3
|
1
|
2
|
12
|
High
|
| Threat |
D
|
R
|
E
|
A
|
D
|
Total
|
Rating
|
