Mobile (iOS / Android) Penetration Testing

1.1. Define Objectives

• Clearly define the goals (e.g., "Access another user's data," "Bypass in-app purchase," "Extract sensitive data from the device").

1.2. Define Scope

• Platforms: Which platforms are in scope (iOS, Android, or both)?
• Application: Specific app name and version (e.g., MyApp v1.3.2).
• Distribution: How will the app be provided?
• From the public App Store / Play Store (Black Box).
• As a binary file (.apk / .ipa) provided by the client (Grey Box).
• Backend: Are the backend APIs in scope? (Almost always, yes). List all known API endpoints.
• Credentials: Will test accounts be provided for different roles (e..g, user, admin).

1.3. Define Test Type & Environment

• Test Devices: Testing will be conducted on both non-rooted/non-jailbroken devices and rooted (Android) / jailbroken (iOS) devices. This is essential as it allows the tester to bypass OS-level protections and inspect the application's internal data.
• Test Environment: A lab including emulators, physical devices, and a network interception proxy (e.g., Burp Suite).

1.4. Establish Rules of Engagement (ROE)

• Authorization: Obtain explicit, written permission.
• Testing Window: Define allowed testing times.
• Data Handling: Define procedures for handling sensitive user data discovered during the test.
• Communication Channels: Establish a point of contact for critical findings.

This phase involves analyzing the application binary without running it.

2.1. Obtain the Application

• Download from the store or receive the .apk (Android) or .ipa (iOS) file from the client.

2.2. Decompilation & Static Analysis

• Use apktool to decompile the app into its resources and smali (assembly) code.
• Use dex2jar to convert the app's classes.dex file into a .jar file.
• Use a Java decompiler (e.g., jd-gui, JADX) to view the Java source code.

• An .ipa is a ZIP file. Unzip it to access the application bundle.
• If the app is from the App Store, it will be encrypted. Use tools like frida-ios-dump or Clutch on a jailbroken device to decrypt the binary.
• Analyze the binary with a disassembler like Ghidra, Hopper, or IDA Pro.

2.3. Look for Static Vulnerabilities

• Hardcoded Secrets: Search the decompiled code and resource files for hardcoded API keys, passwords, encryption keys, or sensitive URLs.
• Manifest/Plist Analysis
• Android (AndroidManifest.xml): Check for android:debuggable="true", exported components (Activities, Services, Broadcast Receivers) that could be insecurely called by other apps, and insecure permissions.
• iOS (Info.plist): Check for custom URL schemes, permissions, and insecure configurations.
• Insecure Code: Look for use of weak encryption (e.g., ECB mode), use of SharedPreferences for sensitive data (Android), or insecure logging (e.g., Log.d).

This phase involves running the app on a device and interacting with it.

3.1. Environment Setup

• Configure a physical (rooted/jailbroken) device or emulator.
• Install the application.
• Configure the device to proxy all network traffic through a tool like Burp Suite or OWASP ZAP. This requires installing the proxy's CA certificate on the device.

3.2. Testing

The following is OWASP Mobile Top 10 2024.

Chain vulnerabilities to demonstrate maximum impact.

Example 1 (Data Theft):

• Bypass SSL pinning
• Intercept traffic
• Discover an IDOR vulnerability in the API
• Write a script to dump all user records

Example 2 (Account Takeover)

• Decompile the app
• Find a hardcoded API key
• Use key to access an admin API endpoint
• Reset any user's password

Example 3 (On-Device Theft)

• Use app
• Find the auth token stored in plaintext in a SharedPreferences file
• Steal the token and replay it in Burp Suite to hijack the user's session

• Executive Summary: High-level, non-technical summary for management, focusing on business risk.
• Technical Report: Detailed report for developers.
• Vulnerability Details: For each finding:
• Description: A clear explanation (e.g., "OWASP M2: Insecure Data Storage").
• Affected Platform(s): (iOS, Android, or Both).
• Evidence: Screenshots, code snippets, HTTP requests, and file paths.
• Impact: The potential business impact.
• Risk Rating: (Critical, High, Medium, Low).
• Remediation: Provide clear, mobile-specific, and prioritized instructions.

Remediation and Re-testing

• Present the findings in a debrief meeting.
• After the client's development team has implemented the fixes, perform a targeted re-test to validate that the vulnerabilities have been successfully remediated.