M1 – Weak Server Side Controls

Threat Agents

Threat agents include any entity that acts as a source of untrustworthy input to a backend API service, web service, or traditional web server application. Examples of such entities include: a user, malware, or a vulnerable app on the mobile device.

Attack Vectors

The attack vectors correspond to the same attack vectors available through the traditional OWASP Top Ten.

Security Weakness

In order for this vulnerability to be exploited, the organization must expose a web service or API call that is consumed by the mobile app. The exposed service or API call is implemented using insecure coding techniques that produce an OWASP Top Ten vulnerability within the server. Through the mobile interface, an adversary is able to feed malicious inputs or unexpected sequences of events to the vulnerable endpoint. Hence, the adversary realizes the original OWASP Top Ten vulnerability on the server.

 

Technical Impact

The technical impact of this vulnerability corresponds to the technical impact of the associated vulnerability (defined in the OWASP Top Ten) that the adversary is exploiting via the mobile device. For example, an adversary may exploit a Cross-Site Scripting (XSS) vulnerability via the mobile device. This corresponds to the OWASP Top Ten A3 – XSS Category with a technical impact of moderate.

 

Business Impacts

The business impact of this vulnerability corresponds to the business impact of the associated vulnerability (defined in the OWASP Top Ten) that the adversary is exploiting via the mobile device. For example, an adversary may exploit a Cross-Site Scripting (XSS) vulnerability via the mobile device. This corresponds to the OWASP Top Ten A3 – XSS Category’s business impacts.

 

M2 – Insecure Data Storage

Threat Agents

Threats agents include the following: an adversary that has attained a lost/stolen mobile device; malware or a other repackaged app acting on the adversary’s behalf that executes on the mobile device.

Attack Vectors

In the event that an adversary physically attains the mobile device, the adversary hooks up the mobile device to a computer with freely available software. These tools allow the adversary to see all third party application directories that often contain stored personally identifiable information (PII) or other sensitive information assets. Adversaries may construct malware or modify a legitimate app to steal such information assets.

Security Weakness

Insecure data storage, vulnerabilities occurs when development teams assume that users or malware will not have access to a mobile device’s file system and subsequent sensitive information in data-stores on the device. File systems are easily accessible. Organizations should expect a malicious user or malware to inspect sensitive data stores. Rooting or jailbreaking a mobile device circumvents any encryption protections. When data is not protected properly, specialized tools are all that is needed to view application data.

 

Technical Impact

Insecure data storage can result in data loss, in the best case, for one user. In the worst case, for many users common valuable pieces of data seen stored include:

• Usernames
• Authentication tokens
• Passwords
• Cookies
• Location data
• UDID/EMEI, Device Name, Network Connection Name
• Personal Information: DoB, Address, Social, Credit Card Data
• Application Data:

o   Stored application logs
o   Debug information
o   Cached application messages
o   Transaction histories

 

Business Impacts

Insecure data storage vulnerabilities typically lead to the following business risks for the organization that owns the risk app:

• Identity Theft
• Fraud
• Reputation Damage
• External Policy Violation (PCI)
• Material Loss.

 

M3 – Insufficient Transport Layer Protection

 

Threat Agents

When designing a mobile application, data is commonly exchanged in a client-server fashion. When the solution transmits its data, it must traverse the mobile device’s carrier network and the internet. Threat agents might exploit vulnerabilities to intercept sensitive data while it’s traveling across the wire. The following threat agents exist:

• An adversary that shares your local network (compromised or monitored wifi);
• Carrier or network devices (routers, cell towers, proxys, etc); or
• Malware on your mobile device

 

Attack Vectors

The exploitability factor of monitoring a network for insecure communications ranges. Monitoring traffic over a carrier’s network is harder than that of monitoring a local coffee shop’s traffic. In general, targeted attacks are easier to perform.

Security Weakness

Mobile applications frequently do not protect network traffic. They may use SSL/TLS during authentication but not elsewhere. This inconsistency leads to the risk of exposing data and session IDs to interception.

The use of transport security does not mean the app has implemented it correctly.

To detect basic flaws, observe the phone’s network traffic. More subtle flaws require inspecting the design of the application and the applications configuration.

 

Technical Impact

This flaw exposes an individual user’s data and can lead to account theft. If the adversary intercepts an admin account, the entire site could be exposed. Poor SSL setup can also facilitate phishing and MITM attacks.

 

Business Impacts

At a minimum, interception of sensitive data through a communication channel will result in a privacy violation.

The violation of a user’s confidentiality may result in:

• Identity theft;
• Fraud, or
• Reputational Damage.

 

M4 – Unintended Data Leakage

Threat Agents

Agents that may exploit this vulnerability include the following: mobile malware, modified versions of legitimate apps, or an adversary that has physical access to the victim’s mobile device.

Attack Vectors

An agent that has physical access to the device will use freely available forensic tools to conduct the attack. An agent that has access to the device via malicious code will use fully permissible and documented API calls to conduct this attack.

Security Weakness

Unintended data leakage occurs when a developer inadvertently places sensitive information or data in a location on the mobile device that is easily accessible by other apps on the device. First, a developer’s code processes sensitive information supplied by the user or the backend. During that processing, a side effect (that is unknown to the developer) results in that information being placed into an insecure location on the mobile device that other apps on the device may have open access to. Typically, these side effects originate from the underlying mobile device’s operating system (OS). This will be a very prevalent vulnerability for code produced by a developer that does not have intimate knowledge of how that information can be stored or processed by the underlying OS. It is easy to detect data leakage by inspecting all mobile device locations that are accessible to all apps for the app’s sensitive information.

 

Technical Impact

This vulnerability may result in the following technical impacts: extraction of the app’s sensitive information via mobile malware, modified apps, or forensic tools.

 

Business Impacts

The nature of the business impact is highly dependent upon the nature of the information stolen. Sensitive information theft may result in the following business impacts:

• Privacy Violations
• PCI Violations
• Reputational Damage
• Fraud

 

M5 – Poor Authorization and Authentication

Threat Agents

Threat agents that exploit authentication vulnerabilities typically do so through automated attacks that use available or custom-built tools. Threat agents that exploit authorization vulnerabilities typically do so through automated attacks that use available or custom-built tools.

Attack Vectors

Once the adversary understands how the authentication scheme is vulnerable, they fake or bypass authentication by submitting service requests to the mobile app’s backend server and bypass any direct interaction with the mobile app. This submission process is typically done via mobile malware within the device or botnets owned by the attacker. Once the adversary understands how the authorization scheme is vulnerable, they fake or bypass authorization by submitting service requests to the mobile app’s backend server using a session that belongs to a user with less permission than they should have to conduct the operation. This submission process is typically done via mobile malware within the device or botnets owned by the attacker.

Security Weakness

Poor or missing authentication schemes allow an adversary to anonymously execute functionality within the mobile app or backend server used by the mobile app. Weaker authentication for mobile apps is fairly prevalent due to a mobile device’s input form factor. The form factor highly encourages short passwords that are often purely based on 4-digit PINs.

Authentication requirements for mobile apps can be quite different to traditional web authentication schemes due to availability requirements.

In traditional web apps, users are expected to be online and authenticate in real-time with a backend server. Throughout their session, there is a reasonable expectation that they will have continuous access to the Internet.

In mobile apps, users are not expected to be online at all times during their session. Mobile Internet connections are much less reliable or predictable than traditional web connections. Hence, mobile apps may have uptime requirements that require offline authentication. This offline requirement can have profound ramifications on things that developers must consider when implementing mobile authentication.

To detect poor authentication schemes, testers can perform binary attacks against the mobile app while it is in ‘offline’ mode. Through the attack, the tester will force the app to bypass offline authentication and then execute functionality that should require offline authentication (for more information on binary attacks, see M10). As well, testers should try to execute any backend server functionality anonymously by removing any session tokens from any POST/GET requests for the mobile app functionality.

To test for poor authorization schemes, testers can perform binary attacks against the mobile app and try to execute privileged functionality that should only be executable with a user of higher privilege while the mobile app is in ‘offline’ mode (for more information on binary attacks, see M10). As well, testers should try to execute any privileged functionality using a low-privilege session token within the corresponding POST/GET requests for the sensitive functionality to the backend server. Poor or missing authorization schemes allow an adversary to execute functionality they should not be entitled to using an authenticated but lower- privilege user of the mobile app. Authorization requirements are more vulnerable when making authorization decisions within the mobile device instead of through a remote server. This may be a requirement due to mobile requirements of offline usability

 

Technical Impact

The technical impact of poor authentication is that the solution is unable to identify the user performing an action request. Immediately, the solution will be unable to log or audit user activity because the identity of the user cannot be established. This will contribute to an inability to detect the source of an attack, the nature of any underlying exploits, or how to prevent future attacks.

Authentication failures may expose underlying authorization failures as well. When authentication controls fail, the solution is unable to verify the user’s identity. This identity is linked to a user’s role and associated permissions. If an attacker is able to anonymously execute sensitive functionality, it highlights that the underlying code is not verifying the permissions of the user issuing the request for the action. Hence, anonymous execution of code highlights failures in both authentication and authorization controls.

The technical impact of poor authorization is similar in nature to the technical impact of poor authentication. The technical impact can be wide ranging in nature and dependent upon the nature of the over-privileged functionality that is executed. For example, over-privileged execution of remote or local administration functionality may result in destruction of systems or access to sensitive information.

Business Impacts

The business impact of poor authentication will typically result in the following at a minimum:

• Reputational Damage

In the event that a user (anonymous or verified) is able to execute over-privileged functionality, the business may experience the following impacts:

• Reputational Damage;
• Fraud
• Information Theft

 

M6 – Broken Cryptography

Threat Agents

Threat agents include the following: anyone with physical access to data that has been encrypted improperly, or mobile malware acting on an adversary’s behalf.

Attack Vectors

Attack vectors include the following: decryption of data via physical access to the device, network traffic capture, or malicious apps on the device with access to the encrypted data.

Security Weakness

In order to exploit this weakness, an adversary must successfully return encrypted code or sensitive data to its original unencrypted form due to weak encryption algorithms or flaws within the encryption process.

 

Technical Impact

This vulnerability will result in the unauthorized retrieval of sensitive information from the mobile device.

 

Business Impacts

This vulnerability can have a number of different business impacts. Typically, broken cryptography will result in the following:

• Privacy Violations
• Information Theft
• Code Theft
• Intellectual Property Theft
• Reputational Damage

 

M7 – Client-side Injection

Threat Agents

Consider anyone who can send untrusted data to the mobile app, including external users, internal users, the application itself or other malicious apps on the mobile device.

Attack Vectors

The adversary loads simple text-based attacks that exploit the syntax of the targeted interpreter within the mobile app. Almost any source of data can be an injection vector, including resource files or the application itself.

Security Weakness

Client-side injection results in the execution of malicious code on the mobile device via the mobile app. Typically, this malicious code is provided in the form of data that the threat agent inputs to the mobile app through a number of different means. The data is malformed and is processed (like all other data) by the underlying frameworks supporting the mobile app. During processing, this special data forces a context switch and the framework reinterprets the data as executable code. The code is malicious in nature and executed by the app. In the “best-case” scenario, the code runs with the same scope and access permissions as the user that has unintentionally executed this code. In the worst-case scenario, the code executes with privileged permissions and much greater scope leading to much greater damage potential than in the “best-case” scenario. There are other forms of client-side injection that involve direct injection of binary code into the mobile app via binary attacks. This brute-force approach to malicious code execution may lead to even greater potential for damage than data injections. For more information on binary attacks, see M10.

 

Technical Impact

To properly determine the technical impact, you must threat model the application. Injection attacks such as SQL Injection on mobile devices can be severe if your application deals with more than one user account on a single application or a shared device or paid-for content. Other injection points are meant to overflow applications components but are less likely to achieve a high impact result because of the managed code protections of the application languages.

 

Business Impacts

The business impact of client-side injection is dependent upon the nature of the malicious code executed by the adversary. Typically, malicious code steals sensitive information (passwords, session cookies, personally identifiable information, etc.). Hence, the associated business impacts include:

• Fraud
• Privacy Violations

 

M8 – Security decisions made via untrusted inputs

 

Your mobile application can accept data from all kinds of sources. In most cases this will be an Inter Process Communication (IPC) mechanism. In general try and adhere to the following IPC design patterns:

• If there is a business requirement for IPC communication, the mobile application should restrict access to a white-list of trusted applications
• Sensitive actions which are triggered through IPC entry points should require user interaction before performing the action
• All input received from IPC entry points must undergo stringent input validation in order to prevent input driven attacks
• Do not pass any sensitive information through IPC mechanisms, as it may be susceptible to being read by third party applications under certain scenarios

M9 – Improper session handling

Threat Agents

Anyone or any mobile app with access to HTTP/S traffic, cookie data, etc.

Attack Vectors

Attack vectors include physical access to the device, and network traffic capture, or malware on the mobile device.

Security Weakness

In order to facilitate a stateful transaction between a user and a mobile app’s backend servers, mobile apps use session tokens to maintain state over stateless protocols like HTTP or SOAP. To maintain state, the mobile app must first authenticate the user through the backend. In response to successful authentication, the server issues a session cookie to the mobile app. The mobile app adds this cookie to all future service transactions between the mobile app and the server. This allows the server to conveniently enforce authentication and authorization for any service requests issued by the mobile app. Improper session handling occurs when the session token is unintentionally shared with the adversary during a subsequent transaction between the mobile app and the backend servers.

 

Technical Impact

An adversary that has access to the session tokens is able to impersonate the user by submitting the token to the backend server for any sensitive transactions. Hence, the technical impact is dependent upon who is being impersonated and what service is being requested.

In the worst-case scenario, the adversary is impersonating an administrative user and issuing a request for administrative functionality that is dangerous in nature.

In the average-case scenario, users lose control of their accounts and who is performing authorized functionality on their behalf.

 

Business Impacts

Improper session handling results in an adversary that can impersonate another user and perform business functionality on their behalf. This may result in:

• Fraud
• Information Theft
• Business Interruption 

 

M10 – Lack of Binary Protections

Threat Agents

Typically, an adversary will analyze and reverse engineer a mobile app’s code, then modify it to perform some hidden functionality.

 

Attack Vectors

An adversary will use an automated tool to reverse engineer the code and modify it using malware to perform some hidden functionality.

 

Security Weakness

A lack of binary protections within a mobile app exposes the application and it’s owner to a large variety of technical and business risks. A lack of binary protections results in a mobile app that can be analyzed, reverse-engineered, and modified by an adversary.

It is difficult to detect that an adversary has reverse engineered an app’s code. Typically, the app owner will realize reverse engineering was successful when the code shows up in another app in iTunes, Google Play, or a third-party app store. Usually, the owner discovers this by accident and not through active policing by an app store.

There are many different viable solutions to detect code modification at runtime and respond accordingly. At runtime, mobile apps should be enabled to detect if a runtime modification / injection has occurred and react in a number of different ways. Pre-determined reactions of the apps will vary from either attempting to thwart the attack or fail in a subtle way.

 

Technical Impact

The majority of mobile apps do not prevent an adversary from successfully analyzing, reverse engineering or modifying the app’s binary code. Organizations should apply binary protections to a mobile app under a few different circumstances:

 

Analysis and Reverse Engineering

Binary protections prevent an adversary from analyzing exposed interfaces and reverse engineering code within the mobile app. All too often, the adversary will steal code and recycle it within another app for resell. The app owner is unaware that the app has been repurposed and sold elsewhere. If there is a likely chance that this may occur, the owner should apply binary protections to the app; and

 

Unauthorized Code Modification

Binary protections prevent an adversary from modifying the underlying code or behavior to disable or add additional functionality on behalf of the adversary. This is likely to occur if the app stores, transmits, or processes personally identifiable information (PII) or other sensitive information assets like passwords or credit cards. Code modification often takes the form of repackaging or insertion of malware into existing mobile apps

 

Business Impacts

Typically, a lack of binary protection will result in the following business impacts:

• Privacy Related and Confidential Data Theft;
• Unauthorized Access and Fraud;
• Brand and Trust Damage;
• Revenue Loss and Piracy;
• Intellectual Property Theft; and
• User Experience Compromise.