Android Security

Introduction to Android Security Common Vulnerabilities and Concept
A security researcher, Alex, is performing a penetration test on a newly released Android app called SecureBank. This app is designed for online banking but has been flagged for potential security issues. Alex's goal is to analyze the app’s security mechanisms, identify vulnerabilities, and determine how an attacker might exploit them.

Phase 1: Checking SELinux Mode
Alex confirms whether SELinux is in permissive mode, which would allow policy violations

adb shell getenforce

Security Concern: If SELinux is Permissive , attackers can execute actions that should be blocked by policy.

Phase 2: Analyzing Native Libraries for Buffer Overflows
Alex decompiles the SecureBank APK and finds that it includes native libraries
written in C++. These libraries are commonly targeted with buffer overflow
attacks using Return-Oriented Programming (ROP).

• Use Ghidra or IDA Pro to analyze the native libraries for functions that handle user input without bounds checking.
• Run a fuzzing test to detect crashes that indicate memory corruption.

Security Concern: If a vulnerable native function is found, an attacker could exploit it to execute arbitrary code.

Phase 3: Identifying Core OS Dependencies
SecureBank relies on the Linux kernel for system interactions. Alex checks if the
app improperly requests root permissions, which could compromise the
Application Sandbox model.

• Use strace to monitor system calls made by the app.
• Check AndroidManifest.xml for android:sharedUserId="android.uid.system", which might indicate privilege abuse.

Security Concern: If the app requests unnecessary system privileges, it increases the attack surface.

Phase 4: Checking the App Execution Environment
Alex verifies whether the app is optimized for Android Runtime (ART) or if it uses outdated Dalvik-based methods.

• Run adb shell getprop dalvik.vm.usejit to see if JIT (Just-In-Time) compilation is enabled.
• Use dynamic analysis tools (e.g., Frida, Xposed) to test runtime modifications.

Security Concern: If an attacker can manipulate ART’s runtime behavior, they may inject malicious code dynamically.

Phase 5: Detecting AndroidManifest Misconfigurations
While examining AndroidManifest.xml , Alex notices that a critical activity is exported:

          android:exported="true"/>

An attacker can launch this activity using:

adb shell am start -n com.securebank/.TransferFundsActivity

Security Concern: If this activity does not check authentication, an attacker could transfer funds without logging in.

Phase 6: Background Task Management Risks
Alex checks whether SecureBank properly manages background services using JobScheduler. If the app relies on persistent background services, it could lead to battery drain or DoS attacks.

• Run dumpsys jobscheduler to list scheduled jobs.
• Look for android:permission="android.permission.FOREGROUND_SERVICE" in AndroidManifest.xml .

Security Concern: If an attacker can trigger excessive background tasks, they could drain device resources or force a crash.

Phase 7: Testing for Man-in-the-Middle (MITM) Vulnerabilities
To verify if SecureBank is vulnerable to MITM attacks, Alex sets up a Burp Suite proxy and intercepts API calls.

• If the app accepts self-signed SSL certificates, it lacks Certificate Pinning.
• Use Frida to bypass SSL checks and inspect intercepted traffic.

Security Concern: If an attacker can intercept API calls, they may steal login credentials or modify transactions.

Phase 8: Identifying WebView Exploits
Alex finds that SecureBank uses WebView for displaying transaction history. The app registers a JavaScript Interface without security controls:

webView.addJavascriptInterface(new WebAppInterface(this), "Android");

If an attacker injects JavaScript into a loaded webpage, they could execute native Android code.
Security Concern: WebView should have JavaScript disabled unless explicitly required.

Phase 9: Testing for Process Isolation Bypass
SecureBank follows Android’s Application Sandbox model, but Alex checks for IPC (Inter-Process Communication) vulnerabilities.

• Inspect content:// URIs to see if they expose sensitive data.
• Use adb shell service list to detect unauthorized service access.

Security Concern: If an attacker can access SecureBank’s IPC services, they might extract private user data.

Phase 10: Verifying Permissions for Non-Exported Components
Alex tests if the app enforces signature-level permissions before accessing sensitive features.

• Look for android:permission="com.securebank.PRIVATE_ACCESS" in AndroidManifest.xml .
• Try calling private activities via adb shell am start .

Security Concern: Without strict signature permissions, malicious apps could exploit internal components.

Phase 11: Analyzing Authentication Token Storage
Alex checks whether the app securely stores user credentials. If SharedPreferences is used to store API keys or tokens, they are easily extractable.

• Use adb shell run-as com.securebank cat /data/data/com.securebank/shared_prefs/*.xml .
• If credentials are stored, dump and decrypt them.

Security Concern: Authentication tokens should be stored in the Android Keystore, not SharedPreferences.

Phase 12: Tapjacking Protection in Mobile Apps
To prevent Tapjacking, Alex ensures the app is protected against malicious screen overlays that trick users into performing unintended actions.

• Check if the app allows screen overlays using the SYSTEM_ALERT_WINDOW permission.
• Attempt to overlay transparent UI elements over sensitive actions (e.g., login, transactions).
• Use tools like Frida or UIAutomator to analyze user interaction vulnerabilities.
• Ensure that critical app screens are protected using FLAG_SECURE , which prevents screenshots and overlays from being applied to the activity.

Security Concern: Without proper protection, attackers could use malicious overlays to trick users into approving permissions, confirming transactions, or entering sensitive information unknowingly.

Phase 13: Testing for SQL Injection
Alex inputs SQL payloads into login fields to test for SQL Injection vulnerabilities.
Entering the following in the username field:

' OR 1=1 --

If authentication is bypassed, the app is vulnerable.
Security Concern: Developers should use parameterized queries to prevent SQL
Injection.