Analysis Methodologies

Static Analysis

This approach involves decompiling an application using tools like Apktool, dex2jar, jd-gui, and smali2dex. The resulting Java and XML files are then scanned for vulnerabilities. This is typically done by searching for keywords and patterns indicative of insecure coding practices. The findings are compiled into a report for further analysis.

Dynamic Analysis

Dynamic analysis monitors an application's behavior during execution. This is commonly achieved through sandboxing or virtualization.

• Sandboxing: A secure, isolated environment is created for the app to run. This prevents external interference and allows for observation of its actions within a controlled space.
• Virtualization: A virtual machine is set up to mimic the target mobile OS environment. The app runs inside this VM, and its interactions and potential malicious activities are logged and analyzed.

Manual Analysis

Expert security analysts install, run, and interact with the application. Through hands-on exploration, they identify its features and potential weak points, allowing for a focused and in-depth security assessment tailored to the specific application.

Key Security Testing Areas for Beginners

1. User Privacy
   • Verify that user passwords are not stored locally, even if encrypted.
   • Check if sensitive data, such as chat logs, contact lists, or financial information, is encrypted at rest.
   • Ensure system and configuration files are not stored in plaintext on external storage.
   • If data must be stored externally, implement checks to verify its integrity before each use.
2. File Permissions
   • The application's directory should have permissions set to prevent read/write access by other users or groups.
3. Network Communication
   • Sensitive information transmitted over the network must be encrypted. Critical data should use TLS or SSL.
4. Runtime Interpretation Protection
   • For applications using embedded interpreters (e.g., WebView), check for vulnerabilities like Cross-Site Scripting (XSS) and SQL Injection.
   • Test for URL spoofing vulnerabilities in WebView components.
5. Android Component Permissions
   • Internal components should not be accessible by arbitrary third-party applications.
   • If a component must be externally callable, enforce signature-level restrictions on the caller.
6. Udpate Mechanism
   • Verify that the integrity and authenticity of update packages are validated to prevent tampering or hijacking.
7. Third-Party Libraries
   • Keep track of and update any third-party libraries used in the application to mitigate known vulnerabilities.

Practical Testing Techniques

1. Interface Testing

This involves testing the network-facing interfaces of an Android app, which often wrap web service operations. The testing methodology is similar to traditional web security testing. A critical concern is the transmission of sensitive user data (e.g., credentials, tokens) over unsecured HTTP, which can lead to severe information leakage, especially on public Wi-Fi networks.

2. Component Testing

This requires knowledge of APK reverse engineering. Tools like Apktool and security assessment frameworks can be used to decompile the application.

Testing WebView: A common vulnerability is the misuse of addJavascriptInterface. By decompiling the APK to Smali code, one can search for these exposed interfaces. A black-box test can then be performed by crafting a malicious URL to probe for weaknesses.

Testing Android Components: Frameworks like Drozer can enumerate components declared in the AndroidManifest.xml. However, for components created dynamically in code, manual decompilation and analysis of the Smali or reconstructed Java code is necessary.

Testing a BroadcastReceiver: Consider a component like FileDownloadReceiver. If its manifest entry allows external broadcasts:

<receiver android:name=".media.FileDownloadReceiver" android:exported="true">
</receiver>

By examining its decompiled Java logic, such as:

private void processIncomingBroadcast(Context context, Intent intent) {
    String fileUrl = intent.getStringExtra("file_url");
    String displayUrl = intent.getStringExtra("display_url");
    if (TextUtils.isEmpty(fileUrl) || TextUtils.isEmpty(displayUrl)) {
        Log.e("Security", "Invalid parameters! URL cannot be empty.");
        return;
    }
    String fileName = intent.getStringExtra("filename");
    // ... logic to handle the download
}

An attacker could send a crafted broadcast to trigger a download from a malicious source.

Testing a ContentProvider: A ContentProvider often exposes a database. If improperly secured, it can be a target for SQL injection. For example, a manifest entry might look like this:

<provider android:name=".data.UserDataStore" 
         android:readPermission="com.example.app.READ_DATA" 
         android:exported="true" 
         android:authorities="com.example.app.user_data" />

If the read permission is too permissive, a malicious app could query the provider. An attacker might attempt to inject SQL via a poorly constructed query URI, which could reveal user data stored in the app's database.