Preparing your workspace...
Loading latest data

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).
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 model.
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.
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.
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.
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 model, but Alex checks for IPC (Inter-Process Communication) vulnerabilities.
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.
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.
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.
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.
Question 1.
What enforces security policies in Android?
Question 2.
What attack exploits buffer overflows in native libraries?
Question 3.
What is the core of Android’s OS?
Question 4.
What replaced Dalvik for app execution?
Question 5.
What is a dangerous misconfiguration in AndroidManifest.xml?
Question 6.
What component manages background tasks?
Question 7.
What security feature prevents MITM in API calls?
Question 8.
What is a common attack on WebView?
Question 9.
What SELinux mode allows policy violations?
Question 10.
What Android security model enforces process isolation?
Question 11. What authentication mechanism should never be stored in Shared Preferences?
Question 12.
What flag is used to prevent tapjacking attacks in Android apps?
Question 13.
What Android security mechanism ensures that only signed apps can communicate via IPC?
Question 14.
What type of vulnerability occurs when SQL queries are constructed using unvalidated user input?