Android for Work has been announced by Google only some days ago and Google promises a secure but also usable way to combine sensitive company data and private data on a single device without increasing the risk of unintended leakage of company data.
“… Android for Work on supported Lollipop devices offers a dedicated Work Profile with security, management and application support built-in. … Android for Work creates a secure Work Profile to isolate and protect data and manage the flow of work information. …” (Android for Work website)
Today, we took a brief look at Android for Work to see how secure it really is and if it is a real alternative to the container solutions of AirWatch, MobileIron, Good, etc.
So we started setting up the whole solution within the Google Admin Console, which is much more work then it seems when you are reading the press releases. The following screenshot shows the requirements for a fully working Android for Work including apps that are able to process company data.
To fulfill these requirements we used a Google Nexus 5 with Android 5.0.2 and the Google Apps Device Policy app installed.
Setting up the policy for all your company devices is straight forward and in most cases self-explaining. You can even set expiry dates for device passwords and number of old passwords that are not allowed for reuse (similar to what companies often do with domain credentials). Furthermore, you can block Google Now and other services you don’t want that your employees are using. You can even block compromised (rooted or infected) devices from syncing with your EMM. When looking to the rest of this post, maybe blocking itself is not enough and Google should also add something like “wipe device if compromised” or similar. In the following screenshots you can see some of the applied settings and the Google Apps Device Policy app.
Lets get to the positiv aspects of Android for Work before deep diving: The policy settings are reliable enforced and the UI is really separated if you configured it that way. Even the clipboard isn’t shared and no transfer of “work data” to the “private part” of the smartphone is possible. So from a user perspective this is really looking nice and usable, but …
As already mentioned blocking of compromised devices isn’t enough if you have synced sensitive or even confidential documents (emails, Word or Excel files, etc.) to the device and want to protect these files from unauthorized access. To test this scenario we need such documents on the device. So we installed an office suite (WPS Office) and some other useful apps to the work environment of the Nexus 5 and created some documents as well as inserted contact data into the “contacts for work” app (as can be seen in the following screenshots).
After saving these documents we first tried to find them on the local storage by using a file manager app. But as mentioned before, the policy is working like it should and we couldn’t find the documents or even the directories where these files should be located according to the work apps.
Afterwards, we tried to achieve the leakage of the “work files” from the managed device through the following attack:
- flashing a custom recovery image,
- using the same approach as formerly used by FROST to circumvent the FDE (by reading the key from memory), and
- accessing the decrypted partitions with the help of adb.
This approach looks really promising, as the Android OS is not running and the EMM doesn’t notice that we are attacking the device. After successfully connecting to the device we tried to access the directories where the sensitive documents should be located (at least according to the work apps): /storage/emulated/10/documents and /storage/emulated/10/Downloads
What we have seen so far was that /storage/emulated/0/… is the virtual sdcard, but we haven’t seen an emulated/10 before….and we didn’t find that location now. It seems that, although we now have root access, these files are still hidden. Due to the fact that we know how the files are named we used find to search for these files and checked if they are really hidden or just mounted to some other directory (the mount command doesn’t show anything suspicious).
This approach showed us where to find the work documents: data/media/10/
. ... ./Download ./Download/gesamt.pdf ... ./documents ./documents/Secret.doc ./documents/Test.doc ...
When looking for the work contacts and the planned meetings we noticed that they aren’t stored in the same directory. All databases and application folders of work apps can be found at: data/user/10/
. ... ./com.android.providers.calendar ./com.android.providers.calendar/lib ./com.android.providers.calendar/cache ./com.android.providers.calendar/databases ./com.android.providers.calendar/databases/calendar.db ./com.android.providers.calendar/databases/calendar.db-journal ... ./com.android.providers.contacts ./com.android.providers.contacts/lib ./com.android.providers.contacts/cache ./com.android.providers.contacts/databases ./com.android.providers.contacts/databases/contacts2.db ./com.android.providers.contacts/databases/contacts2.db-journal ...
At this point many thanks to Dave Smith who was giving us the hint, that the numbers here are the ids of the device users and that it therefore not has to be the id 10 for the work profile.
What puzzled us most, was that these files are neither encrypted nor protected by any other techniques than normal user-access-rights. Meaning that as soon as you are root, there is no protection or isolation of the work apps and its highly sensitive data.
For our attack you need physical access to the device, the bootloader has to be unlocked (not default on Nexus phones) and the device has to be running or at least the screenlock has to be a short PIN (for a fast attack on the FDE). But as soon as there is another exploit like towelroot that can be used without unlocking the bootloader or even bundled with an app, the same attack can be done by a remote attacker that tricks the user into installing a manipulated application.