In the Last Part, Android Application Penetration Testing Part 6 We have seen about the Vulnerabilities has been categorized as TOP 10.
INSECURE LOGGING- ADB Logcat:
Logcat is a command-line tool that dumps a log of system messages, including stack traces when the device throws an error and messages that you have written from your app with the Log class.
Android Logcat allows you to:
- View, filter, and collect all application logs
- View, filter, and collect all system logs such as the garbage collector events
- Retrieve all unexpected errors that have occurred
Sometimes when you are logging into the application. Those credentials can be found in logs.
Mitigation: adb logcat -c” (This clears the logs.) But make sure while coding an application credentials should not be displayed in logs.
Insecure external and internal storage
As we already know all data of the application in the device can be found in the/data/data directory and all applications (apk files) in device can be found in the/data/app directory.
When you have a rooted device you can go in-depth to see which kinds of files are stored in these directories.
Internal Storage
Internal storage is another way of storing data in Android apps. Developers can store data in Android applications locally in various ways
Examples
Shared preferences, files, Cache, SQLite databases, lib, log files, Binary data stores, cookie stores, etc.
Shared Preferences
“Shared Preferences” allows a developer to save and retrieve persistent key-value pairs of primitive data types such as Booleans, floats, ints, longs, and strings.
Shared preferences are created in Android applications using the Shared Preferences class.
Sq-lite Databases
Sq-lite databases are lightweight file-based databases. They usually have the extension “.db” or “.sq-lite”. Android provides full support for Sq-lite databases.
Databases we create in the application will be accessible to any class in the application. Other apps cannot access them.
External Storage
SDCARD is another important location in Android where we can store data associated with our applications. Files created on external storage are globally readable and writable.
Because external storage can be removed by the user and also modified by any application, you should not store sensitive information using external storage.
Mitigation:
- For local storage, the enterprise Android device administration API can be used to force encryption to local files stores “set storage encryption”
- Ensure any shared preferences properties are NOT_MODE_WORLD_READABLE unless explicitly required for information sharing between apps
- For SD CARD storage some security can be achieved via the ‘javax.crypto’ library.
Insecure Communication
Lack of Certificate Inspection: Android Application fails to verify the identity of the certificate presented to it. Most of the applications ignore the warnings and accept any self-signed certificate presented. Some Applications instead pass the traffic through an HTTP connection.
Weak Handshake Negotiation: The application and server perform an SSL/TLS handshake but use an insecure cipher suite which is vulnerable to MITM attacks. So any attacker can easily decrypt that connection.
Privacy Information Leakage: Most of the time it happens that Applications do authentication through a secure channel but rest all connections through non-secure channels.
That doesn’t add to the security of the application because rest sensitive data like session cookies or user data can be intercepted by a malicious user.
Mitigation:
- Use certificates signed by a trusted CA provider and consider certificate pinning for security-conscious applications.
- Apply SSL/TLS to transport channels that the mobile app will use to transmit sensitive information, session tokens, or other sensitive data to a backend API or web service.
- Only establish a secure connection after verifying the identity of the endpoint server using trusted certificates in the key chain.
