One of the best ways to develop secure Android applications is to engage in penetration (pen) testing, in effect trying to break into your application just as an attacker might do. This is the third in a series of posts on pen testing Android applications. In the first we set up the testing environment and captured traffic. In the second, we discussed some tools and proxy techniques—Drozer, Apktool, and a “man in the middle” proxy—that come in handy during a security review of Android applications.In this chapter, we’ll look at reviewing Android’s manifest file.
Every Android binary is packaged with the file Andoridmanifest.xml, which provides the system with necessary information such as permissions, intents, activities, services, broadcasts, etc. It also functions as a basic configuration file.
Access
You can obtain the manifest file by changing the Android binary extension from .apk to .zip. However, this change does not create a readable format. To convert manifest into readable format you can use Apktool to disassemble the Android binary. Once the binary is disassembled, the manifest file is readable. You can also use Manifest Explorer to view the manifest file.
Command:
Apktool d binarypathbinaryname
Here we see the manifest file for the test application Sieve:
You should review several elements in the manifest file.
- Package name: The package name is the unique name of the application, with the application data generally present in the folder /data/data/packagename in the Android directory. While reviewing Packagename it is useful to identify and examine the application directory for any sensitive data.
- Permissions: An application should not request unnecessary permissions. Only the permissions required by the application should be assigned. For example, if an application does not need access to GPS or the camera, then these permissions should not be requested.
android:protectionLevel defines the risks associated with permissions. If a permission is marked as dangerous, you should review this permission because it may grant control to the device or user data. Some permissions categorized as dangerous:
- Calendar
- Camera
- Contacts
- Location
- Microphone
- Phone
- Sensors
- SMS
- Storage
For detailed information on permissions refer to this link.
- Exported components: This element provides the components of an application (provider, activity, service, or receiver) to be invoked by other application components.
If this value is set to true, other components can access this application’s components.
For example, if in a banking application a “view account statement activity” has exported a value set to true, a malicious application could invoke it. Thus this value should be set to false.
android:exported="false”
An example of the fourgoats application with the exported value set to true.
- Android flags (debuggable, backup): The manifest file contains information about Android flags.
Android backup: Allows the application to participate in backup. This is not desirable in cases where the application has sensitive data and user data is at risk due to the backup.
Android debuggable: This flag indicates whether the Android application can be debugged. Once the application moves from test to production, the debug flag should be set to false. If this flag is set to true, any entity with access to the device can execute code under the application’s permissions, and can also obtain sensitive data from the application.
During the security review these flags should be set to false:
android:debuggable="false" android:allowBackup="false”
- API level
The attribute android:minSdkVersion defines the minimum API level required by the application to run on an emulator or device. If the device version is earlier than the minsdkversion, the application may not run on the device. No application should support obsolete versions. The latest API level is 24.
The post How to: Testing Android Application Security, Part 3 appeared first on McAfee.