Top 10 vulnerabilities in mobile applications

My team in the Threat Research Center at WhiteHat Security specializes in mobile application business logic assessments, which is a hands-on penetration test of both mobile client-side apps and the business logic that can be used to circumvent the security built into the program. In a rapid application development environment, it’s a best practice (and required for some compliance guidelines) to have a third party test the application – especially given how much code is recycled from one mobile app to another by the software engineer.

My team finds vulnerabilities in how a mobile application is used on a native device (iOS or Android), not just in a dynamic scan, but via deliberate malicious user tests of functionality by an experienced hacker. An average phone connects to more than 100 different IP addresses during the day, and most information flowing in and out of a phone is unencrypted. (SMS, emails, etc.) Development teams need a penetration test of their most business-critical applications to make sure these are not an avenue of information exfiltration for their users or organization.

This Top 10 list is for you — developers and software engineers — designing mobile apps today.

It’s not logical to order the top ten list of vulnerabilities my team encounters by either severity, impact, or prevalence, as these vulnerabilities found can cause problems for an organization in terms of data loss, sharing private information, or other areas ripe for exploitation by hackers. So here are the Top 10 by vulnerability class, and the solution for how to avoid them:

1. Binary Protection: Insufficient Jailbreak / Root Detection. Rooting or jailbreaking a device circumvents data protection and encryption schemes on the system. When a device has been compromised, any form of malicious code can run on the device, which can significantly alter the intended behaviors of the application logic. Recovery and data forensic tools generally run on rooted devices as well.

Solution: With regards to security, it is best to not have the app run on rooted or jailbroken devices, or to at least do some form of root/jailbreak detection. Detecting whether a device has been compromised adds an extra layer of policy enforcement and risk mitigation to protect the data within the application from being exposed.

2. Insufficient Transport Layer Protection: Applications frequently fail to encrypt network traffic when it is necessary to protect sensitive communications. Encryption (usually TLS) must be used for all authenticated connections, especially Internet-accessible web pages. Backend connections should be encrypted as well, or risk exposing an authentication or session token to malicious actors on the same network as the application host. These backend connections may represent a lower likelihood of exploitation than a connection over the external Internet; however, their impact in the case of exploitation can still result in compromise of user accounts or worse.

Encryption should be used whenever sensitive data, such as credit card or health information, is transmitted. Applications that fall back to plaintext or otherwise be forced out of an encrypting mode can be abused by attackers.

Solution: Ensure the application has a security constraint that defines a confidentiality and integrity-based secure transport guarantee. This will ensure that all data is sent in a manner that guarantees it cannot be observed or changed during transmission. If TLS must be terminated at a load balancer, web application firewall, or other in-line host, it should re-encrypt the data in transit to the target host(s).

3. Information Leakage – Server Version: Server information is present in the response. Information Leakage is an application weakness where an application reveals sensitive data, such as technical details of the web application, environment, or user-specific data. Sensitive data may be used by an attacker to exploit the target application, its hosting network, or its users; leakage of sensitive data should be limited or prevented whenever possible.

Information Leakage, in its most common form, is the result of one or more of the following conditions: A failure to scrub out HTML/Script comments containing sensitive information, improper application or server configurations, or differences in page responses for valid versus invalid data.

Solution: Remove unnecessary information from server responses that could give an attacker extra information regarding your network.

4. Information Leakage – Sensitive Data: Informationally this is similar to the Server version in 3, but touches on more leakage within the app, app-to-app, etc.

Solution: Information Leakage generally occurs in two categories: globally or resource specific. Vulnerabilities based on global information leakages are often related to verbose error messages or server / application framework version disclosures. These leakages can often be solved by a configuration setting. Resource-specific information leakage issues are related to the disclosure of developer comments, files or sensitive personal information. Resource-specific leakages often require direct mitigation each time they occur.

5. Insufficient Authorization/Authentication: Insufficient Authorization results when an application does not perform adequate authorization checks to ensure that the user is performing a function or accessing data in a manner consistent with the security policy.

Authorization procedures should enforce what a user, service, or application is permitted to do. When a user is authenticated to a web site, it does not necessarily mean that the user should have full access to all content and functionality.  

Solution: Enforce a proven authorization framework scheme which emphasizes policy-based configuration files over hard coded authentication/authorization checks wherever possible.

6. Cryptography – Improper Certificate Validation: This application is either not validating SSL/TLS certificates or is utilizing an SSL/TLS certificate validation system that will not correctly verify that a trusted provider issued the certificate. The client should be configured to drop the connection if the certificate cannot be verified, or is not provided. Any data exchanged over a connection where the certificate has not properly been validated could be exposed to unauthorized access or modification.

Solution: Ensure that your application’s certificate validation is configured to correctly verify that a certificate is provided, and from a trusted source like a reliable Certificate Authority. Or, code-in the latest certificate transparency standards approved by IETF or the CA/B Forum.

7. Brute Force – User Enumeration: There are numerous ways for an attacker to determine if a user exists in the system; a brute force attack is a method to determine an unknown value by using an automated process to try a large number of possible values. The attack takes advantage of the fact that the entropy of the values is smaller than perceived. For example, while an 8-character alphanumeric password can have 2.8 trillion possible values, many people will select their passwords from a much smaller subset consisting of common words and terms.

If error messages change when the username and/or password are submitted incorrectly, an attacker can determine the existence of a valid username/email address based on any differences in the error messages.

If user ID is generated sequentially in a predictable manner, (XXX102017, XXX112017, etc.) an attacker can enumerate through the list of users by incrementing the user ID.

Solution: The user enumeration vulnerability typically occurs in the following functionality: Login, Registration, or Forgot Password. The application should not reveal whether a username is valid. The response to valid and invalid input in either field should be completely identical.

For example, instead of “Sorry, your password is invalid”, a proper response might say: “Sorry, your username or password is incorrect. Please try again.”

8. Insufficient Session Expiration: After a user signs out of an application, the identifiers that were used during the session are supposed to be invalidated. If the server fails to invalidate the session identifiers, it is possible for other users to use those identifiers to impersonate that user and perform actions on his behalf.

Solution: First, it is a best practice to ensure a logout button is implemented in the application; and second, when the user clicks this button their session is properly invalidated.

9. Information Leakage – Application Cache: Sensitive data can be leaked from application caches, either through the main application code or via third-party frameworks.

Mobile devices present a unique challenge with regards to secure data storage. The devices can be easily lost or stolen. Many users do not lock their devices. The cached data can be viewed by an attacker who is performing data forensics on the physical device.

Solution: Ensure that sensitive data is not accidentally leaked through the cache. Developers can prevent it through creating a threat model for OS, framework, and platform to check and verify the way data is handled during URL caching, keyboard press caching, logging, copy or paste caching, app backgrounding, browser cookies objects, HTML5 data storage and analytic data that is sent to the server or another app.

10. Binary Protection – Insufficient Code Obfuscation: This is specific to Android/Java, the most common phone OS. To better protect Java applications from being reverse-engineered, several tools have been developed to scramble or obfuscate the code. Google has included one of the most popular of these tools, ProGuard, as part of the Android SDK. The ProGuard tool shrinks, optimizes, and obfuscates your code by removing unused code and renaming classes, fields, and methods with semantically obscure names. The result is a smaller sized .apk file that is more difficult to reverse engineer.

Solution: ProGuard is integrated into the Android build system, so you do not have to invoke it manually. ProGuard runs only when you build your application in release mode, so you do not have to deal with obfuscated code when you build your application in debug mode. Having ProGuard run is completely optional, but highly recommended and can help your security posture on those systems. 

Best wishes to all you mobile app developers out there! My team hopes to see less of these vulnerabilities in future apps your organization sends to us to evaluate.