Improper platform usage is the major vulnerability of mobile applications. This vulnerability categorizes all the misuse or improper usage of any given functionality or a security feature in the mobile. This could include a misconfigured Android Intent which will leak users’ sensitive data or accept requests from other applications. It may also include various scenarios where a developer simply doesn’t use secure coding practices or secure coding guidelines which will effectively make their application more insecure. Any issue or situation which contributes to either misconfigured functionality or unavailability of security measures in the mobile application contributes to the broad category of improper platform usage.
There are various issues that may arise with the use of improper platforms for building mobile applications. The developer must use the secure coding practices which gives enough code security without much compromising on the functionalities it can offer to the user. The developer must maintain a proper balance between the code security and the functionality of its application.
Improper platform usage may arise due to the following three major risks:
Risks:
- Violation of published guidelines
- Violation of common practice
- Unintentional Misuse
- Violation of Published Guidelines
Developers of all the functionalities release a set of guidelines to modify and implement the functionality into the application. These are a set of processes and procedures which must be followed for the proper and secure working of the functionalities. The developer of the application must follow these coding guidelines for risk-free implementation and when the developer bypasses these set guidelines and does not properly follow the rules, the threat of data leakage or application crash may arise.
- Violation of Common Practice
There are many best secure coding practices and common procedures which are not codified by the manufacturer of the functionality but are suggested to be used by experts in the field. Though these secure coding practices are not codified by the manufacturer, developers are expected to use them as industry standards to prevent the introduction of any new vulnerabilities in the application code.
- Unintentional Misuse
This risk arises when the application developer does not have proper knowledge of the working processes or internal structure of API calls. The developer intends to do the right thing but somehow misunderstanding the API implementation and ends up with the opening a plethora of attack surface on their application.
Attack Scenario & Prevention
Attack surface covering the M1-Improper Platform Usage is very vast. Any issue that may arise due to misconfiguration or misuse of the functionality comes under this category. Leakage of sensitive data of users or malformed authentication is the most common result of this vulnerability.
The most common attack surface for Improper Platform Usage in Androids arises with the improper use of intents.
Improper Use of Intents
Intents in the android application is used to communicate with other components of the application. It is used to start an activity, communicate with background services, access data from content providers or send information using broadcasts. The improper declaration or incorrect flags may show up the vulnerable intents which a malicious application can use to communicate with sensitive endpoints of the application to extract data.
The intent of the application can be of two types, private or public. Private intents only communicate with the other components of the same application whereas Public intents have the ability to communicate outside the application area.
Android has a feature to protect the application’s private intents from the external calls from other applications in the mobile. To use this protection, developers need to add an attribute named ‘exported’ inside the declaration of intent in the manifest file of the application with the value false.
The android:exported=” false” restrict the intent being called by other applications and hence save from any data leakage from unauthorized intent calls.
If the developer wants to allow intents to communicate with other application of same developer (applications signed with the same key of developer) for eg: Data sharing between Google Play Store and Gmail then the developer can use ‘permissions’ attribute while declaring the intent in the manifest file which will allow all applications having the same signature to communicate using the intents.
Intent Sniffing
Android has two types of intents, implicit and explicit.
Implicit Intent: Implicit intent sends the data to android and allows android to search for all applications which can handle such data and let the user choose which application needs to be used to process the data.
For eg: On clicking a URL, android search for all the installed applications in the mobile which can handle a URL as an input, like installed browsers (Chrome, Firefox, Safari) and prompt user to select any of the prompted applications which will then handle the URL and open the webpage.
Explicit Intent: Explicit intent mentions the exact component to be called and sends data to only that component. This ensures the data is not sent outside the application and is handled by the intended component only.
Intent Sniffing is another technique which attackers may use to harvest sensitive data from the mobile of the victims. Attackers create a malicious application which registers itself to receive implicit intents and broadcast messages and subsequently look for sensitive information in the received data.
Insecure Permissions
This is also a very common issue that developers may neglect while coding the application. Android has specified a varied amount of privileges that can be assigned to the files used in the application or the files created by the application at the runtime. The developer must assign correct permission to the file to limit other users reads and write operations on it. The files with world-readable and world-writable permissions will allow viewing and writing any data which an unauthenticated user is requesting. This will seriously impact the confidentiality of the CIA triad and compromise the overall security of the application.
To mitigate this issue, developers must not assign MODE_WORLD_READABLE and MODE_WORLD_WRITABLE permissions. To improve the confidentiality and integrity of the application data, developers should use content providers to fetch the data in real-time.
Allow Backups
Many applications allow themselves to be backed up by the user, this functionality allows the user to backup the application along with the user data and restore it after a clean format or changing the devices. This backup functionality can also be exploited by the attacker to inject content in the application by modifying the backup file of the user and restoring the malicious backup file on the user’s mobile devices. This will not only modify the integrity of the application data but also can be leveraged to attack confidentiality. The backup of the application contains the sensitive user data which can be repacked with the malicious data of the attacker and on restoring the backup, users’ application will contain our injected data.
The developers have the option to block the permission for backup and android won’t be able to take a backup of the application or application’s user data. The developer should add the ‘allow backup’ flag with false value in the manifest file of the application. This protection will restrict the android to take a backup of the application and hence secure its tampering and injections.
Insecure Keychain Configurations
Apple uses a separately secured ecosystem for the need for authentication of the user for various applications in the mobile. The management of all the authentication processes is handled with the use of keychains. Keychain is a password manager for Apple products which are specifically designed by the company to keep the sensitive data of users like username, passwords, certificates or private keys. Keychain stores the user’s data after encrypting it thus restricting its malicious use by any other applications.
Developers can use this functionality for the authentication process of the user and need not to develop their own system for the process which could be buggy as well as less secure. The system controls which application can access the entries in keychain using Access Control List and Keychain Access Groups. The issue arises when the developer does not do the secured configuration in the keychains which allow the user’s sensitive data to be accessed by a third party application or even be synced to other devices using iTunes backup.
The developer should do the secured configuration of the keychains by attributes like kSecAttrAccessibleAfterFirstUnlock which makes the keychain accessible after the first unlock till the device reboot or kSecAttrAccessibleWhenUnlockedThisDeviceOnly which restricts the migration of keychains at the time of backups while being only present when the user unlocks the device. In addition to this, developers should also implement checks for jail-broken devices or devices using processors older than A7 as this might cause issues with the security of the data stored in the keychains. Developers should also add application-level authentication of the user which will act as an added security mechanism for the unauthorized access to the sensitive data of the application.
Conclusion
All this constitutes the improper platform usage of the OWASP Top 10 Mobile. Due to its vast array of attack vectors as well as difficulty in securely coding the applications, it made its way to the first position in the OWASP Top 10 Mobile list. The developer should follow above mentioned secure coding practices for the application and perform thorough testing of the application before releasing it to the public to be able to protect the user’s sensitive data.
