In this post and following a responsible and coordinated disclosure with Google, I will share some interesting findings Shahar Areli & I recently came across while looking into the secure separation logic of Android for Work. In fact, Android provides us with two built-in mechanisms that allow maliciously crafted personal apps to silently view, steal and even manipulate content that should be safely locked in the Work profile of Android for Work.
Here is the video of the complete RSA presentation where I presented the Android for Work and app-in-the-middle disclosure with my co-founder, Adi Sharabani.
NOTE: Google has recently dropped the ‘Android for Work’ branding (now calls it ‘work features in Android’), but for the brevity of this post we decided to keep the term “Android for Work” throughout the post.
Android for Work Sandbox
Android for Work was developed to address the massive demand for using personal devices in the business environment. The basic idea is to create a separate profile on the device which has business-level controls, while leaving the original, personal profile open and unmanaged. All of the business applications, email and documents would be managed and secured within the business profile, while everything on the personal side remains untouched and unrestricted. This way users can feel like their privacy is better respected, since administrators cannot manage or monitor personal apps.
Android for Work, introduced on version 5.0 Lollipop, relies on the Android mechanism of user separation, which allows a few different users to use the same device with an isolation of applications, network and storage. The work profile is implemented as a separate user, but it shares its icon badges and notifications with the personal profile. The premise of Android for Work profiles is that it allows an IT department to securely manage an environment for work activities without restricting the access or use of personal apps and data.
Android for Work was designed as an additional sandbox, or secure container, where apps outside the sandbox cannot access data inside the sandbox. In other words, no application installed within the device’s personal profile should have any kind of access to the activity or content in the work profile. Android for Work creates a seemingly secure framework whereby sensitive enterprise information and private personal information are kept separate, allowing the coexistence of productivity and privacy without security concessions. By default, work profile notifications and app icons have a red briefcase so they are easy to distinguish from personal apps.
Below, I will describe two ‘app-in-the-middle’ attacks, where a malicious app is installed in the personal profile and acts as an agent to steal information from (and even control) the Work profile and hand it off to an attacker’s Command & Control server.
The Notification Access Attack
Mobile notifications have become a standard and essential tool for both personal and work productivity, and the Android for Work notifications are presented right alongside personal notifications in the same, seamless interface (see image). Since Notifications access is a device-level permission, a malicious app in the personal profile can acquire permission to view and take actions on ALL notifications, including work notifications, by design. Sensitive information, such as calendar meetings, email messages and other information appears in these notifications, which are also visible to the “personal” malicious app.
This capability circumvents the secure separation logic between personal and work profiles, which is offered by Android for Work. An app-in-the-middle attack may manipulate a user to enable the Notification Access permission (even for a legitimate function in the personal persona) in order to gain access to information in the work profile. If the malicious app is designed to transmit the information viewed in notifications to a command and control server, then the information contained in notifications is no longer secure.
As an example for how such attacks can be further utilized, a clever hacker may be able to use this method to gain even greater access into sensitive work information by initiating a “forgot password” process on some enterprise system and hijacking the subsequent on-device notification to grant himself full enterprise access, even outside of the context of the mobile device. To keep this attack covert, the malicious app can immediately dismiss the notification and “archive” the recovery email using the Android Notifications API so the victim is completely unaware they have been hacked. This presents a serious threat to the use of Android for Work as a secure sandbox for mobile work productivity, as EMM solutions have no mechanism to recognize or defend against it. The attacker may even capture 2-factor authentication and administrators will not have any visibility of the theft.
Watch this demonstration video of the scenario described above.
The Accessibility Permissions Attack
Android created the Accessibility Service to provide user interface enhancements to help users interact with their device. This includes features like audible narration of on-screen text for visually impaired users. In order to facilitate these features, the Accessibility Service necessarily has access to virtually all content and controls, both reading and writing, on the device. An application in the personal profile that acquires Accessibility permissions can gain access to applications that are executed in the business persona, effectively circumventing the secure separation offered by Android for Work.
This app-in-the-middle resides in the personal profile, yet is effective in stealing corporate information as the user interacts with it. The personal profile cannot be monitored or controlled from the work profile, so even if IT administrators try to enforce security on the work profile (e.g., by restricting the profile settings or allowing only whitelisted apps) it won’t be possible to detect any exposure of sensitive information that uses the Accessibility Service, as they cannot access the personal profile. In order to perform such an attack, a malicious application would register as an Accessibility Service, present it with an innocent label, and manipulate the user to grant the access.
Watch this demonstration video of how the Accessibility Service may be used by a malicious app to capture confidential information from the work profile and transmit it to a remote hacker’s server.
As part of our interaction with Android’s security team, we learned about an API that the Android engineers have implemented, which allows the whitelisting of Accessibility Services, intended for EMM vendors to utilize in their Android for Work administration interfaces. As part of our effort to provide better security to the industry, we’ve reached out to our EMM partner ecosystem and are working with them to add such a control to their products to help mitigate this threat.
It is important to note that while taking a look at the API, we came across possible pitfalls and shortcomings of the API, which should be taken into consideration when utilizing it:
The whitelisting function uses an array of Strings of package names to represent the whitelisted Accessibility Services by the organization. The aforementioned is simple to circumvent by creating a malicious app with the same package name as a whitelisted legitimate app.
Any pre-existing, non-system Accessibility services that are enabled when the whitelisting mechanism (the setPermittedAccessibilityServices method) is executed, have to be allowed and included in the whitelist or the method execution will fail (see screenshot below). This is understandable from a user-experience perspective, but is problematic from a security perspective: malicious app-in-the-middle Accessibility services that already reside on the device might become whitelisted and create further havoc even after the remediation action is conducted, unless they are manually removed by the device owner in advance, which might be challenging from an enterprise perspective.
Alternate Covert Attack Vector
These app-in-the-middle attacks may be executed by the social engineering route described above and in the video. However, it can also be accomplished using “tapjacking” (discussed previously as clickjacking), a stealthier attack vector, as the user will be unaware that the malware is even using Accessibility Services or Notification access. This method uses the Draw Over Apps feature to trick the user into activating Accessibility Service or Notifications without their knowledge. First introduced over a year ago, Accessibility Clickjacking is still a practical threat to the vast majority of Android devices. Although Marshmallow (6.x) takes an additional precaution against this type of attack by requiring the user to manually and specifically allow an app to create a system overlay by changing permissions in Settings -> Apps -> Draw over apps settings, a combination of stealth and social engineering will still be an effective attack.
The Dangerous Illusion of Security
The interesting thing about both of these app-in-the-middle methods of defeating the Android for Work profile separation is that the device and the Android operating system remain operating exactly as designed and intended. It is the user that must be tricked into placing the software on the device and activating the appropriate services that allow the malware access to sensitive information.
The great danger in this disclosure is not only that the system may be hacked and sensitive corporate information leaked. Most knowledgeable IT security professionals know that there are inherent security risks introduced by the use of mobile devices. The danger lies in the illusion of a secure container, which tends to allow people to let their guard down in the belief that the environment itself is a sufficient security mechanism to protect sensitive data. We believe that mobile containers are a valuable tool for certain corporate needs; however, as have been demonstrated repeatedly over the past few years, hackers are able to circumvent them in a variety of ways (Adi Sharabani and I are going to share more details in our RSA Conference presentation on Friday, Feb. 17th, 2017).
Mitigation Strategy
In order to devise a strong mobile security strategy against this and other existing and emerging threats, it is imperative to have an active tool that can detect hacking attempts (whether they come from malicious networks or malicious apps) and also protect against them with standalone capabilities. The aforementioned rationale drives Mobile Threat Defense to become a core component in the mobile security strategy of organizations in every industry, and across all use cases, including managed, unmanaged and mixed use case environments. SEP Mobile, for one, utilizes its app-analysis technology to provide visibility and defense against this and other forms of attack.
Credits
I’d like to also thank to Elisha Eshed, Omer Ofir and Liran Gafniel for their great work and contribution to this research.
Acknowledgements / Responsible Disclosure
The aforementioned findings were shared in advance with the Android Security team. After internal evaluation by the Android team, it was decided that the aforementioned behavior is an intended behavior. As that behavior poses an unexpected and clear threat to corporate data of organizations that utilize Android for Work, we have mutually agreed to disclose the findings with the public, to raise awareness to the exposure. We would like to thank the Android Security Team for their engagement and the open channel they have created to discuss security exposures of the Android operating system.