Link Search Menu Expand Document

Sensitive Information Disclosure in Android

In Android, there are multiple instances where a careless developer can introduce vulnerabilities that will ultimately allow malicious actors or applications to extract sensitive data from the victim application.

Disclosure via auto backup

Android offers a number of auto-backup features. The backups include data and settings for all installed applications. If the application stores sensitive user data, backing up such data may be unwanted. Performing data backup for an Android application can potentially also backup sensitive information stored within the app’s data directory. Sensitive user data could be copied to a removable device or transferred to a third-party cloud system (e.g., Google, OEM), which could result in privacy compliance issues.

Android Backup Features:

  • Built-in USB backup facilities: when USB debugging is enabled, you can use the adb backup command to create full data backups and backups of an app’s data directory.
  • Auto Backup for Apps: available since Android 6.0 (API level 23) and enabled by default. It automatically stores up to 25MB of app data within a private folder in the user’s Google Drive account. By default, Auto Backup includes files in most of the directories that are assigned to your app by the system:
    • Shared preferences files.
    • Files saved to your app’s internal storage, accessed by getFilesDir() or getDir(String, int).
    • Files in the directory returned by getDatabasePath(String), which also includes files created with the SQLiteOpenHelper class.
    • Files on external storage in the directory returned by getExternalFilesDir(String).
  • Key/Value Backup: backup of key-value data to the Android Backup Service cloud. The amount of data is limited to 5MB.

  • OEM software: many OEMs have backup apps pre-installed.

Apps that target Android 6.0 (API level 23) or higher automatically participate in Auto Backup. In the app manifest file, set the boolean value android:allowBackup to enable or disable the backup.

If backing up is not required, disable the functionality in the AndroidManifest.xml file:

<application
    android:allowBackup="false">
    ...
</application>

It is also possible to create backup rules, listing files to be included/excluded:

In AndroidManifest.xml, add the android:fullBackupContent attribute to the <application> element.

<application
    android:fullBackupContent="@xml/backup_rules">
    ...
</application>

This attribute points to a backup_rules.xml XML file that contains backup rules. In the file, it’s possible to specify rules with the <include> and <exclude> elements.

In the example below, all shared preferences files are backed up with the exception of the user.xml file:

<?xml version="1.0" encoding="utf-8"?>
<full-backup-content>
    <include domain="sharedpref" path="."/>
    <exclude domain="sharedpref" path="user.xml"/>
</full-backup-content>

Disclosure via screenshotting

By default, the content of Android’s activities is not considered sensitive material, meaning that, for example, not only can it be screenshotted by the user but also by third-party applications. Therefore, developers should take extra care in identifying the portions of the application that require this additional protection.

Failing to secure sensitive activities might lead to the exfiltration of data, such as credentials, personal data, etc.

To prevent this behavior, the window containing the activity must be explicitly instructed to forbid third-party access to its frame buffer. In particular, the FLAG_SECURE layout parameter needs to be set in the onCreate method, before super.onCreate and after setContentView:

protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    getWindow().setFlags(WindowManager.LayoutParams.FLAG_SECURE, WindowManager.LayoutParams.FLAG_SECURE);

    setContentView(R.layout.activity_sensitive_data_holder);

    // ...
}

Disclosure via hardcoded sensitive material

The threat model of an Android application must consider that the application source code - especially constants - cannot be regarded as secure storage. In fact, anyone who gets ahold of the APK can extract, decode, and decompile the files that are part of the application. In particular, tools like Apktool are also able to decompile the Dalvik bytecode contained in classes.dex, creating a .smali file for each original source code file.

Think of .smali files as the mnemonic representation of the Dalvik bytecode; hence, they contain an equivalent source code and all the constants, including possibly sensitive data left there by careless developers.

Unsecured components

Android provides a complex permission system to secure applications and their components that can be daunting at first. In general, permissions (especially in recent Android versions) allow users to grant fine-grained privileged to potentially untrustworthy applications. In a nutshell, permissions work by requiring one application (or the system) to expose some permissions and another application to ask for them.

However, this method between application permissions isn’t merely limited to an expose/request manner of functioning; it doesn’t prevent any application (even malicious ones) from just asking for the permission themselves.

When a more rigid coupling is required, Android allows friend applications to have a closer relationship, enabling them to grant one other special privileges. One possible way to achieve this friend status is to sign all apps with the same key; this is enough proof for Android to accept that all such applications have emerged from the same development team. Hence, they trust each other.

However, this is not bulletproof and may lead to surprising behavior.