Android Apps: Attack Surface Overview

Overview

So, you’re looking to do a security assessment of a client’s Android application. Let’s talk about some attack surfaces and common security issues that should be on your mind. There are two use-cases for this info:

• You’re new to mobile testing and want an overview of common issues, so you know what terms to use in your research.
• You’re somewhat experienced with mobile testing and want a quick checklist to use for mapping coverage.

Here, we’re going to be thinking about a user-facing app that a organization or individual will be distributing for their business. That means we won’t be covering OS-level issues, fraud techniques, or malware. We shouldn’t treat this list as exhaustive but it should give you decent coverage on average. As usual, vulnerabilities and their severities will depend on the context of the app you’re testing.

App Configuration

Most of an app’s general configuration settings will be found in the manifest.

• Backup settings: apps can configure GDrive and adb backups; review for sensitive info.
• Network security config: apps can harden or loosen network traffic settings; review for misconfigured development settings and cleartext traffic controls (like usesCleartextTraffic).
• Minimum Android version: apps can define their minimum supported Android versions; old version are missing security features and may not be approprite for sensitive apps.
• System Permissions: review for unused or unnecessarily broad permissions.
• Custom Permissions: apps can define their own permissions; review for missing protections or typos in protection declarations.
• Debuggable: apps can allow debug tools to be attached; this should be disabled in production. This is uncommon but worth checking if apps are being sideloaded from an unofficial source.

Exported App Components (“IPC”)

Review the manifest for exported app components (android:exported="true" or declaring intent-filters) with weak or null permissions. Trace the logic of these components to see if user inputs can be leveraged to control any sensitive functionality.

• Activities: review incoming extras to see if you can coerce logic to access user data or take actions on a user’s behalf.
• Deeplinks: review browsable Activities (deeplinks) for URL parameters that can allow you to access user data or take actions on a user’s behalf. Deeplinks with Webviews are usually part of the “1-click ATO” vuln chains.
• Services: review whether other apps can bind to services to access sensitive functionality or data.
• Broadcast Receivers: review if incoming broadcast data can be used to access user data or take actions on a user’s behalf. Review any usage of registerReceiver() as well.
• Content Providers: review content and file providers for SQL injection, or direct data access that could bypass other app controls.

Webviews

• Loading user-controlled content: user-controlled URIs should be validated against expetected hosts before loading. Unexpected URLs or local files (passed in via extras or deeplinks) should not generally be loaded into the app context.
• Javascript bridges: carefully review usage of setJavaScriptEnabled and addJavascriptInterface to ensure user-controlled URLs or XSS payloads cannot access user data, or take actions on the user’s behalf. These interfaces are often targetted to steal session information and should be reviewed carefully.
• File access: review local content access settings (such as setAllowContentAccess and setAllowFileAccess) to ensure user data cannot be leaked via user-controlled URLs or XSS payloads.

Data Storage

• Use of shared directories: review any usage of shared external directories where app files could be accessed or modified. Look for race conditions on these files (such as sensitive pictures being temporarily written to the camera roll).
• User credential storage: ensure user-generated credentials are properly stored (Keystore or Credential Manager).
• Hardcoded credentials: review app code, resource XML files, and binary files for sensitive integration keys or tokens.
• Insecure cryptography: review any use of custom cryptography code. This can be challenging to get correct and likely touches sensitive data.
• Insecure file handling: review any file handling logic for parsing bugs (ex. zip slip, XXE, deserialization) and path traversal issues.

Network Traffic

• Server-side issues: intercept network traffic to test for server-side vulnerabilities (ex. SQLi, XXE, SSRF, Authz bypasses). Ensure you set aside enough time for this, as larger apps will have extensive backend APIs.
• Transport security: check for any code that handles custom certificate validation. Things like HostnameVerifier and X509TrustManager are occasionally overriden to allow interactions with misconfigured servers, but can leave network traffic exposed.
• Sensitive data leaks: review network traffic to ensure private user data isn’t sent to 3rd-party analytics platforms.
• Misconfigured integrations: review network traffic for usage of static or over-privileged API integration keys.

Build and Release Process

• Debugging interfaces: review code for hidden debugging interfaces or logic active in the production build.
• Insecure logging: review production logging code (logcat, usage metrics, and crash reporting) to ensure proper sanitization of user data.
• Build artifacts: unpack the production APK and review for unintentional files. Unnecessary and unexpected internal files can be caught up in the build process if the build pipeline is misconfigured.
• Insecure update mechanism: review any logic to dynamically update or load code (such as DEX files or Javascript bundles).
• Insecure 3rd-party libraries: review any 3rd-party libraries for insecure configurations or known vulnerabilities. Library configs will usually piggyback on the manifest or add a file into the assets directory.
• NDK usage: review native .so files for proper compiler and runtime protections. It’s also common for developers to include hardcoded secrets in these files, as they’re often considered less likely to be reverse engineered.

Misc

• Custom security flow: common security protections, like PINs and password-based unlock screens, should leverage the system APIs to use the device equivalents.
• UI hijacking: review any non-default taskAffinity settings for workflow hijacking issues.

Antipatterns

There are a few common hardening suggestions that provide questionable value in practice, and can cause more problems than they solve. If a user’s device is rooted, things like certificate pinning, root detection, and screenshot prevention can be fairly trivially bypassed. As the device needs to be able to understand the app to run it, code obfuscation can also generally be bypassed by motivated users, and usually simply delays analysis. These features can also be brittle and break your app in unexpected ways without robust planning, and ongoing support.

In general, engineering time is often better spent elsewhere, and these protections shouldn’t be recommended outside of specific contexts or relied on as security mechanisms.