Projects/OWASP Mobile Security Project -2015 Scratchpad
- 1 M1: Improper Platform Usage
- 2 M2: Insecure Data
- 3 M3: Insecure Communication
- 4 M4: Insecure Authentication
- 5 M5: Insufficient Cryptography
- 6 M6: Insecure Authorization
- 7 M7: Client Code Quality Issues
- 8 M8: Code Tampering
- 9 M9: Reverse Engineering
- 10 M10: Extraneous Functionality
- 11 -=-=-=-= Historical Stuff -=-=-=-=-
- 12 OWASP Category Elements
- 13 "Test Drive" Category Element
This is the draft of the 2016 reworking of the Mobile Top Ten.
M1: Improper Platform Usage
This category covers misuse of a platform feature or failure to use platform security controls. It might include Android intents, platform permissions, misuse of TouchID, the Keychain, or some other security control that is part of the mobile operating system.
There are several ways that mobile apps can experience this risk.
Violation of published guidelines. All platforms have development guidelines for security (c.f., ((Android)), ((iOS)), ((Windows Phone))). If an app contradicts the best practices recommended by the manufacturer, it will be exposed to this risk. For example, there are guidelines on how to use the iOS Keychain or how to secure exported services on Android. Apps that do not follow these guidelines will experience this risk.
Violation of convention or common practice. Not all best practices are codified in manufacturer guidance. In some instances, there are de facto best practices that are common in mobile apps.
Unintentional Misuse. Some apps intend to do the right thing, but actually get some part of the implementation wrong. This could be a simple bug, like setting the wrong flag on an API call, or it could be a misunderstanding of how the protections work.
Failures in the platform's permission models fall into this category. For example, if the app requests too many permissions or the wrong permissions, that is best categorised here.
The defining characteristic of risks in this category is that the platform (iOS, Android, Windows Phone, etc.) provides a feature or a capability that is documented and well understood. The app fails to use that capability or uses it incorrectly. This differs from other mobile top ten risks because the design and implementation is not strictly the app developer's issue.
The impacts of this risk are hard to describe. Mobile platforms provide many different services, from authentication, to secure data storage, to secure network communications. Failing to use some part of the platform correctly, therefore, could expose data, allow connections to untrusted hosts, or enable fraudulent payments. Privacy and permissions in mobile apps are also the domain of the platform. Thus, a failure to use the platform's features could expose the end user to a privacy risk.
Because there are several platforms, each with hundreds or thousands of APIs, the examples in this section only scratch the surface of what is possible.
App Local Storage Instead of Keychain
The iOS Keychain is a secure storage facility for both app and system data. On iOS, apps should use it to store any small data that has security significance (session keys, passwords, device enrolment data, etc.). A common mistake is to store such items in app local storage. Data stored in app local storage is available in unencrypted iTunes backups (e.g., on the user's computer). For some apps, that exposure is inappropriate.
M2: Insecure Data
This new category will be a combination of M2 + M4 from Mobile Top Ten 2014.
(Bladou) This covers insecure data storage and unintended data leakage. Data stored insecurely includes, but is not limited to, the following:
- SQL databases;
- Log files;
- XML data stores ou manifest files;
- Binary data stores;
- Cookie stores;
- SD card;
- Cloud synced.
Unintended data leakage includes, but is not limited to, vulnerabilities from:
- The OS;
- Compiler environment;
- New hardware.
This is obviously without a developer's knowledge. In mobile development specifically, this is most seen in undocumented, or under-documented, internal processes such as:
- The way the OS caches data, images, key-presses, logging, and buffers;
- The way the development framework caches data, images, key-presses, logging, and buffers;
- The way or amount of data ad, analytic, social, or enablement frameworks cache data, images, key-presses, logging, and buffers.
(Bladou) It is important to threat model your mobile app, OS, platforms and frameworks to understand the information assets the app processes and how the APIs handle those assets. It is crucial to see how they handle the following types of features :
- URL caching (both request and response);
- Keyboard press caching;
- Copy/Paste buffer caching;
- Application backgrounding;
- HTML5 data storage;
- Browser cookie objects;
- Analytics data sent to 3rd parties.
(Bladou) This can result in data loss, in the best case for one user, and in the worst case for many users. It may also result in the following technical impacts: extraction of the app's sensitive information via mobile malware, modified apps or forensic tools.
The nature of the business impact is highly dependent upon the nature of the information stolen. Insecure data may result in the following business impacts:
- Identity theft;
- Privacy violation;
- Reputation damage;
- External policy violation (PCI); or
- Material loss.
M3: Insecure Communication
Owner: Andrew Blaich, Milan. Contributions by Paco
This risk covers all aspects of getting data from point A to point B, but doing it insecurely. It encompasses mobile-to-mobile communications, app-to-server communications, or mobile-to-something-else communications. This risk includes all communications technologies that a mobile device might use: TCP/IP, WiFi, Bluetooth/Bluetooth-LE, NFC, audio, infrared, GSM, 3G, SMS, etc.
All the TLS communications issues go here. All the NFC, Bluetooth, and WiFi issues go here.
The prominent characteristics include packaging up some kind of sensitive data and transmitting it into or out of the device. Some examples of sensitive data include encryption keys, passwords, private user information, account details, session tokens, documents, metadata, and binaries. The sensitive data can be coming to the device from a server, it can be coming from an app out to a server, or it might be going between the device and something else local (e.g., an NFC terminal or NFC card). The defining characteristic of this risk is the existence of two devices and some data passing between them.
If the data is being stored locally in the device itself, that's #Insecure Data. If the session details are communicated securely (e.g., via a strong TLS connection) but the session identifer itself is bad (perhaps it is predictable, low entropy, etc.), then that's an #Insecure Authentication problem, not a communication problem.
The usual risks of insecure communication are around data integrity, data confidentiality, and origin integrity. If the data can be changed while in transit, without the change being detectable (e.g., via a man-in-the-middle attack) then that is a good example of this risk. If confidential data can be exposed, learned, or derived by observing the communications as it happens (i.e., eavesdropping) or by recording the conversation as it happens and attacking it later (offline attack), that's also an insecure communication problem. Failing to properly setup and validate a TLS connection (e.g., certificate checking, weak ciphers, other TLS configuration problems) are all here in insecure communication.
There are a few common scenarios that penetration testers frequently discover when inspecting a mobile app's communication security:
Lack of certificate inspection
The mobile app and an endpoint successfully connect and perform a TLS handshake to establish a secure channel. However, the mobile app fails to inspect the certificate offered by the server and the mobile app unconditionally accepts any certificate offered to it by the server. This destroys any mutual authentication capability between the mobile app and the endpoint. The mobile app is susceptible to man-in-the-middle attacks through a TLS proxy.
Weak handshake negociation
The mobile app and an endpoint successfully connect and negotiate a cipher suite as part of the connection handshake. The client successfully negotiates with the server to use a weak cipher suite that results in weak encryption that can be easily decrypted by the adversary. This jeopardizes the confidentiality of the channel between the mobile app and the endpoint.
Privacy information leakage
The mobile app transmits personally identifiable information to an endpoint via non-secure channels instead of over SSL. This jeopardizes the confidentiality of any privacy-related data between the mobile app and the endpoint.
M4: Insecure Authentication
This category captures notions of authenticating the end user or bad session management. This can include:
- Failing to identify the user at all when that should be required
- Failure to maintain the user's identity when it is required
- Weaknesses in session management
Authentication issues are a reasonable place to put privacy issues related to authentication. For example, if a mobile app is using device-specific data like IMEI, Bluetooth MAC address, or other hardware identifiers as an authenticator for the user, that may create privacy expectations for the app developer/owner.
Authentication over an insecure channel also belongs in this category if that results in spoofing, replaying or otherwise attacking the authentication. Storing the password badly in the mobile app belongs in "insecure data storage" and transmitting passwords in the clear belongs in "insecure communications". For example, if observing the enrolment of one user into a service gave an attacker insight into data that would be used in subsequent enrolments, that would be an authentication issue belonging in this category.
In past versions of the OWASP Mobile Top Ten, there were separate categories for session management issues. In this version, all such issues go here—unless they have another, better place to go.
Session issues can include:
- Predictable session identifiers
- Failing to log users out
- Session lifetime risks (sessions valid too long, sessions valid across multiple channels)
- Session fixation
The key characteristic that authentication issues have is that the tokens which represent the user can be compromised in some way. Alternatively, the app might have mechanism at all for authenticating something that needs to be authenticated. E.g., no mechanism to identify users, no means of identifying/enrolling devices, no means of authenticating genuine microservices, etc.
One common risk around authentication is exposing data or delivering services to unidentified users. Anonymous users may be able to invoke web services (plan a route, put items into a basket, generate an image) when the intent is to require only registered/identified users to perform that operation.
Trivially Guessed Identifiers
If an app used some small, non-decreasing integer to identify users, it would be subject to obvious attacks like spoofing.
Anonymous Service Endpoints
A common problem in mobile apps is offering up information to unauthenticated requests when they come to service endpoints that service mobile apps. Imagine a loyalty programme that associated some number of points with a loyalty number. If the microservice returned discount codes applicable to a specific loyalty member without authenticating the request first, that could lead to abuse (e.g., attackers checking all loyalty numbers looking for valuable discount codes). The solution would be to securely authenticate the user and require authentication to display loyalty data.
Private Data Used As Identity
In Europe and in the UK, data like IMEI and other hardware addresses are private data that must be treated similarly to the user's phone number or home address. Mobile apps that use hardware identifiers as user identifiers might that they are transmitting, storing, and using those identifiers in ways that do not comply with applicable privacy laws. The solution is to use a unique, unpredictable identifier for users that is unrelated to any private data. Alternatively, apps can use these hardware addresses so long as they treat that private data with the policy and technical appropriate safeguards.
Apps sometimes do not actually log out of the server side of the application. The app merely discards its copy of session identifiers and other login data. This weak form of logout can leave sessions open far longer than is intended. A session that is observed (e.g., via eavesdropping) could be cloned into another device or into a web browser and continued, even after the mobile app believes it has logged out.
M5: Insufficient Cryptography
Owner: Paco Hope
The code applies cryptography to a sensitive information asset. However, the cryptography is insufficient in some way. Note that anything and everything related to TLS or SSL goes in #Insecure Communication. Also, if the app fails to use cryptography at all when it should, that probably belongs in #Insecure Data. This category is for issues where cryptography was attempted, but it wasn't done correctly.
Common failures in this category include:
- Weak ciphers
- Small keys
- Wrong type of crypto (e.g., symmetric when asymmetric is more appropriate)
- Vulnerability to a well known cryptanalytic attack like
- Chosen plaintext attack
- Known plaintext attack
- Poor key selection (e.g., predictable randomness)
All issues in this category share a common quality: The app did attempt to protect the data, and the protection probably works to some degree. But the finding is usually that the protection is deemed insufficient for one reason or another.
The data that is being protected with cryptography is likely to be exposed. Typical results are related to either the confidentiality or the integrity of the data that was protected.
Confidentiality risks might include an offline brute force attack against the data or inference attacks against the encrypted data. Such risks mean that an attacker learns some or all the protected information.
Integrity risks might include replay attacks if a cryptographic signature can be forged. Insecure code might get loaded if a code signature can be forged. Guessable or predictable cryptographic tokens might enable fake transactions.
These are just a few examples of the kinds of issues that might be classified in this category.
Imagine a mobile app that encrypts data before sending it to the server using a strong symmetric cipher (e.g., AES-256). If the key for encrypting were easily determined, this would be insufficient cryptography. Perhaps the encryption key is simply the user's numeric userid or some other easily guessed identifier. Fixing this issue would involve generating a strong key and securely communicating it between the server and client, or perhaps using asymmetric cryptography.
Easily Forged Integrity Checks
Imagine a mobile app that posts data to a central service (e.g., high scores for a game, user's geographic location, etc.). Imagine that the mobile app adds a hash of the user's data as a parameter in the request as an integrity check. This hash is trivial to duplicate, so an attacker attempting to forge a legitimate update can do so easily. The attacker simply needs to calculate the same hash over the fake data. Fixing this issue would involve making the signature unique and difficult to forge.
M6: Insecure Authorization
This is a category to capture any failures in authorization (e.g., authorization decisions in the client side, forced browsing, etc.). It is distinct from authentication issues (e.g., device enrolment, user identification, etc.).
If the app does not authenticate users at all in a situation where it should (e.g., granting anonymous access to some resource or service when authenticated and authorized access is required), then that is an authentication failure not an authorization failure.
Typical risk impacts relate to granting access to unauthorized users. Users may be able to perform CRUD operations that they should not be able to. They may be able to invoke services or receive service that their credentials do not entitle them to.
Client-based Authorisation Decisions
If the mobile app knows the user's privilege level, and offers menus and options appropriate to the user's level, that's normal. But if the server honours requests without verifying the user's right/privilege to execute those requests, then there is usually a problem. If the server is implicitly trusting the mobile code to only generate requests appropriate to the user's privilege level, that is a classic insecure authorization finding.
Authentication Instead of Authorization
The web app end points that service mobile apps might permit access to resources as long as any authentication has taken place. Imagine a REST-based microservice that provides the loyalty points balance for a given loyalty account number. If that service requires some kind of authentication, but does not validate the user's identity as being authorised to see that balance, then this a failure in authorization.
M7: Client Code Quality Issues
This was "Security Decisions Via Untrusted Inputs", one of our lesser-used categories. This is the catch-all for code-level implementation problems in the mobile client. That's distinct from server-side coding mistakes. This captures the risks that come from vulnerabilities like buffer overflows, format string vulnerabilities, and various other code-level mistakes where the solution is to rewrite some code that's running on the mobile device.
The key characteristic of this risk is that it's code executing on the mobile device and the code needs to be changed in a fairly localised way. Fixing most risks requires code changes, but in the code quality case the risk comes from using the wrong API, using an API insecurely, using insecure language constructs, or some other code-level issue. Importantly: this is not code running on the server. This is a risk that captures bad code that executes on the mobile device itself.
Bad code can allow attackers to exploit the business logic, perhaps bypassing security controls enforced on the device. Code-level bugs reveal sensitive data in unexpected ways.
If an app had a format string vulnerability or similar, it could display sensitive information (e.g., an encryption key, session ID, or API key) in its user interface that was intended to only exist in RAM inside the app.
M8: Code Tampering
Owner: Jonathan Carter
This category covers binary patching, local resource modification, method hooking, method swizzling, and dynamic memory modification.
Once the application is delivered to the mobile device, the code and data resources are resident there. An attacker can either directly modify the code, change the contents of memory dynamically, change or replace the system APIs that the application uses, or modify the application's data and resources. This can provide the attacker a direct method of subverting the intended use of the software for personal or monetary gain.
- Direct changes to the application package
- Redirection or replacement of system APIs
- Direct back-end server attacks
This category of attack can change the implicit or explicit logic of the application. This could be used to subvert or short-circuit in-application purchases or licensing, leading to lost revenue for the application developer. It could also be used to clone the application into a malicious variant which could contain a malware payload under the guise of a legitimate application. Also, this method can be used to change or discontinue network traffic to the application's back end servers-- or redirect the application to talk to the attacker's servers.
There are a number of counterfeit applications that are available across the app stores some of which contain malware payloads. Many copy and modify the underlying core binary and resources, and re-package them as a new application. The conditional jumps which detect whether an in-application purchase is successful canbe short-circuited to always allow the content, without charging the end user.
M9: Reverse Engineering
Owner: Jonathan Carter, Milan
- Code Reversing
- Binary Inspection
This category includes analysis of the final core binary to determine its source code, libraries, algorithms, and other assets. Software such as IDA Pro, Hopper, otool, and other binary inspection tools give the attacker insight into the inner workings of the application. This may be used to exploit other nascent vulnerabilities in the application, as well as revealing information about back end servers, cryptographic constants and ciphers, and intellectual property.
- Leaked source code
- Intel leading to code tampering
By reverse engineering, an adversary can enumerate and/or bypass the business logics, bypass security controls, facilitating source code piracy and enabling code tampering. If the source code is not obfuscated, then it becomes very easy for an adversary/competitor to replicate your application. Adversaries canthen re-pack the application and distribute it to public (via various means). This involves a high business risk: loss of revenue, brand damage, or counterfeit copies of the application. These counterfeit copies can also facilitate phishing or credential stealing.
Consider a banking Android application. The APK file can be easily extracted using 7zip/Winrar/WinZip/Gunzip. Once extracted, the attacker has manifest file, assets, resources and most importantly classes.dex file.
M10: Extraneous Functionality
Owner: Andrew Blaich, Milan
Often, developers include hidden backdoor functionality or other internal development security controls that are not intended to be released into a production environment. For example, a developer may accidentally include a password as a comment in a hybrid app. Another example includes disabling of 2-factor authentication during testing.
The defining characteristic of this risk is leaving functionality enabled in the app that was not intended to be released.
There is high risk of stealing sensitive data or accessing unauthorized functions via these extra capabilities. If a banking application has malicious code implanted in it, it will not only steal customer information and funds but also damage the bank's reputation. This malicious code will initiate an outgoing connection, which will be treated as genuine connection and not malicious. Despite of all security controls, it will be very difficult for bank to detect malicious activity by the application on mobile devices.
Another example is insurance application. If a developer injects malicious code snippet in any insurance application, then there is high probability of stealing customer data which includes all personal details. Imagine if this malicious snippet is monitoring your payment transactions.
-=-=-=-= Historical Stuff -=-=-=-=-
These bits below were at the top of this page some time ago. Now Paco relocated them here to support our surveying. Some old commentary has been moved to Mobile2015Commentary.
The content of the Mobile Top 10 will be refreshed at some cadence, and most probably not a short one. In between there will be needed changes as appropriate, but major changes will happen sparsely between "official releases".
In order to keep interest in the project and to offer deeper and more complete content, there is a proposal to supply architectural and code samples that illustrate the Top 10 items.
As a first milestone it is suggested that 6 months after the Top 10 is released we are able to do a refresh launch offering the initial version of these samples.
A set cadence for further refresh/release later on needs to be established as well.
What is It?
This is the "Mobile Top Ten" what? It's the top 10 "stuff people tend to screw up", but here are some important questions.
- Business risk or technical risk? The business risk would be something like "intellectual property unprotected" or "customer data exposed." A technical risk would be something like "data stored in plain text files."
- Root cause, or final impact? Often root causes are things like not encrypting when we should. Final impact is stuff like unintended data leaks. The problem is that some of these things are overlapping. Not every lack of crypto is a data leak, but many are.
- What threats are in scope? There are apps that simply do not care about protecting from malware, jailbreaking, etc. Think Yelp: it's just restaurant reviews. No financial impact, no reason to care about many client-side attacks. Plenty of apps do care about client-side attacks. E.g., banking, communications, health data. Many items hinge on whether or not you care about client side attacks. How do we capture this?
- If you care about client-side attacks, then failing to encrypt stuff is basically a data leakage.
- If you don't care about client-side attacks, then failing to encrypt stuff is kinda "gee you should do that".
- If you care about client-side attacks, there are probably some platform features that are not sufficient as-is: the app sandbox, etc. You probably want to be putting your own additional layer of encryptiong / protection, etc.
- If you don't care about client-side attacks, then you simply need to be using the standard APIs (keychain, app data storage, etc.) in the standard supported ways.
Who is it For?
Do we intend this to be a tool that infosec / appsec people use? Do we intend lay people to make use of it? (e.g., developers and non-mobile IT security people) What does the target audience need to get from it?
(Paco's opinion) We need to have a narrative: If you found functionality that does X, it is probably in bucket A, unless it is also doing (or not doing) Y, in which case that's bucket B.
OWASP Category Elements
This section explores the critical elements that must be included within all OWASP Mobile Top Ten 2015 categories. Each element is listed below along with a brief description of the appropriate content. The goal is to "test drive" this list of required elements with a sample, non-commital category to verify that the elements adequately cover what is needed within each of the OWASP Mobile Top Ten 2015 categories. Each of these elements has been initially based off the Google Hangout meeting held on April 1 2015.
Label (generic and audience-specific labels)
This element is a unique identifier for the bucket of issues that belong together. In the OWASP Mobile Top Ten 2015 Survey, we found that there were many different audiences that may use the OWASP Mobile Top Ten 2015 for different purposes. As always, there needs to be a generic label that uniquely identifies each bucket of issues. However, there should also be additional labels for the same category that are audience-specific to make it easier for different audiences to identify the category they are looking for. These additional labels will help clarify and differentiate the categories.
This element is a generic education piece (100-200 words) around the nature of the category. It should describe the nature of the category as it relates to the different audiences (e.g., penetration testers; software engineers). It should include external references and educational links to other sources around the nature of the problem.
This element eliminates any uncertainty or ambiguity that may result from vagueness / broadness in the category labels. It should include "headline vulnerabilities" that made it into the media and help each audience get a "gut feel" for what belongs to this category. In the 2014 list, we found that there were many instances where the same vulnerabilities were spread across many different categories. Hence, the need for this additional element along with a strive towards better categorisation.
This element helps clarify how critical the category of issues is from both a business and technical perspective. During the meeting of April 1 2015, it was proposed that the CVSS classification scheme may be used here as a way of helping guide the audiences in prioritisation of the fixing of the issues.
This element gives coding-specific examples, CVE vulnerabilities and newsworthy events that fall into this category. This element will help clarify to the difference audiences what fits into this category.
Audience Specific Guidance
This element gives practical advice and guidance for category remediation that is relevant to each audience (100-200 words). Each audience may approach the issue of remediation from very different perspectives. For example, an auditor may simply want to know more about whether or not remediation is appropriate. Meanwhile, a software engineer may want to have coding-specific advice. Each audience's concerns must be addressed in this element.
"Test Drive" Category Element
Here, we are testing a particular category to see whether or not the proposed elements for each category are adequate to address each audience's needs. It is important to note that this is a sample category and is not a formal commitment to any final category in the OWASP Mobile Top Ten 2015. It is strictly meant for testing purposes. Members who would like to 'own' particular elements in the category below should 'sign up' and add content where appropriate.
Insecure Data Transmission
Mobile devices and applications can be used to transmit data over many communication channels. These channels include, but are not limited to: "Wireless Cellular Protocols (2G, 3G, 4G, 5G, etc.), WiFi(Ad-Hoc, Infrastructure, and Peer to Peer modes), Bluetooth (and it's variants), Infrared, RFID, NFC, etc.
Vulnerabilities in this category focus on weaknesses associated with "data in motion" when transmission occurs over the above noted communication channels. These vulnerabilities can arise as a result of one or more failures in adequately securing the communications channels including but not limited to: plain-text transmission of sensitive data (i.e. not utilizing adequate encryption over the communication channel), insufficient authentication of encrypted channel endpoints (i.e. Failing to confirm the identity of the remote end-point you are attempting secure transmissions with) and/or insufficiently/inadequately establishing the encryption communications protocol (i.e. using weak encryption secrets, ciphers and/or protocols).
Owner(s): Milan Singh Thakur, Amin Lalji
Owner(s): David Fern
The key differentiator of this vulnerability is that it is concerned about unencrypted or improperly encrypted data being stolen during transmission, not on the device but through the airwaves.
Insecure Data Transmission should not be confused with others in the top 10 such as:
M3: Insufficient Transport Layer Protection – I DO NOT SEE ANT DIFFERENCE
M4: Unintended Data Leakage – Unintended data leakage is a result of insecure data transmission. Once data has been stolen and interpreted it may contain information that is valuable to attackers (leaked).
M6: Broken Cryptography – While broken cryptography does relate to data that has been improperly encrypted, and it may be an input or causes of insecure data transmission, it focuses on the encryption process/technique itself on the device transmitting the data.
The risk attributed to mobile applications that suffer from this category of vulnerabilities rely upon the "business" value of the data being transmitted - however from a technical perspective, exploitation of this vulnerability can lead to a loss of confidentiality (i.e. access to confidential/sensitive data by unauthorized individuals/systems) and possibly a loss of integrity (i.e. data may be changed in transit).
The ease of exploitation of this type vulnerability varies based on the communication channel, but generally speaking, is not an overly complex attack to successfully execute (i.e. when sensitive data is transmitted over WiFi in clear-text, it is trivial to intercept and review).
Mitigating the risks associated with this category of vulnerabilities can take various forms depending on the transmission protocol being used.
- Include examples here for protocol level security implemented with Layer 6/7 (TLS/HTTPS), WiFi, Bluetooth, NFC, RFID, etc.)
Owner(s): Rajvinder Singh, Milan Singh Thakur, Amin Lalji
Owner(s): Adam Kliarsky
Owner(s): Andi Pannell, Amin Lalji
From both a development and auditing stance, the easiest way to test this is to insert a proxy (such as burp) between the device running the mobile app and the wifi connection. Looking for data being transferred over plain text, as well as identifying weak procotols (SSLv2, SSLv3) and ciphers (RC4, MD5) being used to transmit data.