Pentesting Multi-user and Android Enterprise apps

We were recently asked to assess the security of a well known BYOD solution that uses Android Enterprise management to create a separate working environment on the employee’s owned device. In this article, we are going to share a few notes and techniques used to overcome the challenges encountered during this activity.

“Android Enterprise is a Google-led initiative to enable the use of Android devices and apps in the workplace”, as stated in the developers’ documentation. It allows a company to manage employee’s devices in order to create a safe work environment. As the documentation explains, this can be done by fully or partly managing a company owned device, or by using employee’s devices, by creating and managing a work environment along with their existing personal profile (“Bring Your Own Devices” – BYOD).

Android Enterprise uses the multi-user features provided by Android in order to create safe separate environments; more details on the security features offered by Android Enterprise can be found in the last versione of the Android Enterprise Security White Paper. Here is a list of products that use and support Android Enterprise features.

Although rarely used, Android has the possibility of being used as a multi-user operating system. All data and applications are normally available for the default user (uid = 0); when creating a different user, it is possible to create a separate environment for data and applications. By setting a PIN/Passcode to protect the separate environment, all data can be encrypted on disk and decrypted only when the separate user’s passcode is provided.

Android-level users must not be confused with the underlying Unix users: Android, being Linux-based, is always a multi-user system, where different applications are run by different Linux users in order to provide app-level compartimentalization.

From a Penetration Tester’s point of view, testing Android Enterprise presented a few challenges because the techniques and tools we are used to are set to work by default only on the principal personal user profile.

Application data on Android normally resides in the folder /data/data/com.applicationname. This is actually a link to the location /data/user/0/com.applicationname. When a new user is created, a new folder with its uid is added, to contain their application data (e.g.: /data/user/10/com.applicationdata for uid = 10).

Adb commands act on the default user by default. So, a regular pm list packages will only return the packages installed for the default user. By running the command pm list users it is possible to list all users of the system. often support a --user switch that let you run the command for a specific user.

Android device with default user (0) user for a work profile (10) and guest user (11)

Frida, our favorite tool for instrumenting mobile applications, uses the official Android APIs that function with the default user only. Although undocumented, most APIs have a corresponding alternative used to specify the user. Therefore, with two pull requests (frida-core and frida-tools) we added the option to spawn and attach Android application for a specific user:

frida -U -f com.android.contacts --aux=uid=10

This way it is possible to hook and spawn frida processes running as another Android user.