Vulnerabilities of mobiles applications

One of the missions of the CIRT of ANTIC is the certification of the electronic platforms of cyberspace Cameroon. The certification of the electronic platform of a company will ensure that it does not present any flaw or danger for the various players in cyberspace Cameroon, the CIRT's expert engineers carries out assessments of the application logic and business applications web and mobile.

In the table below, we present the most common vulnerabilities in the assessment tests. We have not classified these vulnerabilities in terms of severity, impact, or prevalence, as these vulnerabilities can be a problem for a company in terms of data loss, private information sharing, or other areas that can be exploited by hackers.

1 App is Debuggable The application is compiled with the debug mode enabled. A malicious actor with physical access to a device on which USB debugging is enabled can attach a debugger to the application process during execution. This is dangerous because it could expose sensitive data, enable reverse engineering, and allow the execution of arbitrary code.

Suggested solutions :
1. Verify that all test code is not included in the final production version of the application;
2. Review all API endpoints that the mobile application accesses to verify that these endpoints are well-documented and publicly available.
3. Examine all log instructions to make sure that nothing too descriptive about the backend is being written to the logs.
2Accesses External StorageThe application accesses the external storage directory on the SD card. External storage is accessible by any application on a device with the READ / WRITE_EXTERNAL_STORAGE permission. It is therefore recommended not to store sensitive information in the external storage. Access to external storage is in the following methods and classes :

Suggested solutions :
For local storage, use the following function offered by the Android libraries to force Encryption into local file stores "setStorageEncryption". For SD card storage, some security can be obtained via the "javax.crypto" library. You have some options, but it's easy to encrypt all data in plain text with a master password and AES 128.
Ensure that the shared preference properties are not MODE_WORLD_READABLE unless they are explicitly required for sharing information between applications.
Avoid relying solely on hard-coded encryption or decryption keys when storing sensitive information.
Consider providing an additional layer of encryption beyond the default encryption mechanisms provided by the operating system.
3Contains Native CodeThe application loads the native code libraries. The native code does not have the same security protections as Java, and is vulnerable to memory overflows, use after free errors and occasional errors. the code can also be loaded from unreliable sources, such as a shared directory or network.

Suggested solutions :
In general, code quality issues can be avoided by doing the following: Maintain consistent coding patterns that all members of the organization agree on.
Write a code that is easy to read and well documented
Through automation, identify memory overflows and memory loss through the use of third-party static analysis tools; and Prioritize the resolution of memory overflows and memory leaks over other "code quality" issues.
4Insecure Pseudo-random Number Generation The application uses a pseudo-random number generator that returns a predictable sequence of numbers that is unsuitable for security purposes. The java.util.Random and java.lang.Math classes should not be used to generate random numbers for secure use. Unsafe pseudo-random number generators can be found in the following methods :
The application prints the log information in the system log. While applications often save information for debugging purposes, this should usually be removed before an application goes into production. Sensitive information, such as keys or tokens, should never be written to the system log.

Suggested solutions :
Use the java.util.Random and java.lang.Math classes to write newer, more secure algorithms for generating random numbers. Apply cryptographic standards that will stand the test of time for at least 10 years;
5Logs InformationThe application prints the log information in the system log. While the applications often save information for debugging purposes, this should usually be removed before an application goes into production. Sensitive information, such as keys or tokens, should never be written to the system log.

Suggested solutions :
Rest assured that no sensitive information is written in the logs.
6Source Code is not ObfuscatedThe application does not hide most of its code by renaming classes, fields, methods, and variables. This allows an opponent or competitor to decompile the application into an almost original source. It is recommended to hide the application code using a tool such as ProGuard to make reverse engineering more difficult.

Suggested solutions :
In order to avoid effective reverse engineering, you must use a darkening tool. There are many commercial grade free obfuscators on the market. Conversely, there are many different deobfuscators on the market. To measure the effectiveness of any masking tool you choose, try disobtaining the code using tools such as IDA Pro and Hopper.
A good obfuscator will have the following abilities:
Limit the code segments / methods to hide;
Adjust the degree of obfuscation to balance the impact on performance;
Obfuscate code tables and methods
7Uses MD5 Hashing AlgorithmThe application uses the weak MD5 hash algorithm. The MD5 algorithm is dangerous if it is used for sensitive data because it is vulnerable to collision attacks.

Suggested solutions :
Use the SHA-256 hashing algorithm
8Weak RSA Modulus Length of App Signing CertificateThe application is signed with a 1024-bit key and may be vulnerable. An attacker with the private signature key of an application would be able to create malicious application updates.

Suggested solutions :
Use a key at least 2048 bits long.
9Binary ProtectionInsufficient 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.

Suggested solutions :
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.
10Insufficient Transport Layer ProtectionApplications 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.

Suggested solutions :
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).
11Information Leakage – Server VersionServer 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.

Suggested solutions :
Remove unnecessary information from server responses that could give an attacker extra information regarding your network.
12Information LeakageSensitive Data: Informationally this is similar to the Server version in 3, but touches on more leakage within the app, app-to-app, etc.

Suggested solutions :
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.
13Insufficient 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.

Suggested solutions :
Enforce a proven authorization framework scheme which emphasizes policy-based configuration files over hard coded authentication/authorization checks wherever possible.
14Cryptography – Improper Certificate ValidationThis 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.

Suggested solutions :
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.
15Brute Force – User EnumerationThere 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.

Suggested solutions :
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.”
16Insufficient Session ExpirationAfter 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.

Suggested solutions :
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.
17Information Leakage – Application CacheSensitive 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.

Suggested solutions :
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.
18Binary Protection – Insufficient Code ObfuscationThis 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.

Suggested solutions :
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.