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.
Interesting. Its a shame its not easy to detect an unlocked bootloader, as that is the big vulnerability here imho. Even if the files were encrypted with system stored key pairs access to these is still only governed by UID, so that would be the same issue I think?
right, to make it more secure it should be something like a user PIN/password that is not stored on the device or something like the ARM TrustZone should be used to protect this memory/storage
The number (0, 10, 11, etc.) simply denotes the user account identifier. These are the same identifiers used when multiple profiles are created on the device by the user. Android is just picking the “next available number” to be used for the co-present, managed profile. Point being, they will not always be at /xxx/10/, the number will be whatever profile identifier was chosen by the device.
The point about the pinned documents being visible is somewhat misdirected. The fact that those documents are stored on the globally accessible external storage (i.e. you don’t even need root to access them) is the chosen test application’s fault (WPS Office). Apps like Google Drive stored pinned documents in the protected internal storage space (i.e. the directory where you found the contacts/calendar databases).
It is a good point to reiterate, however, that the external storage of a managed profile is no more protected than the that of any other profile. The point about the truly protected containers (internal storage) being just as vulnerable on a rooted device is also valid.
Managed profiles seem to use the exact same mechanisms for file partitioning that the core OS has always used for multiple user account profiles. The only difference with a managed profile seems to be that it can live co-present with the logged in user, rather than forcing account switching.
thank you Dave for this very valuable comment. I will use it to make some statements above more clear.