Mr. Cowell made me aware of a Medium article by Bastien Bobe, field CTO at Lookout, this week. His article gave me a good overview of a vulnerability discovered by Alan Zaccardelle that I'd previously not heard about.
I'd encourage reading the linked article above for the overview and demo video of the vulnerability, but in a nutshell the issue is as follows:
During work profile setup, there's a temporary state as the profile initialises where no policies are applied. It's too early for organisational policy to enforce (in which sideloading is always prevented by default) and there's no default policy in place on Android's side.
The work profile is wide open.
This means if a user has developer settings enabled, USB debugging turned on, and the device connected up to a computer, applications can be sideloaded via ADB. For those more advanced, a script can be written to check for the presence of the work profile, and immediately adb install package.apk as many apps as desired until continuing on to the point of registration/enrolment and corporate policy application.
Here's a video of my own tinkering (I don't pause the process, so policy can be seen blocking further installs), and I'll continue the article below:
Pretty much all Android versions going back 10+ years.
Android 16 beta 3 is already patched, so 16 will be the first release in recent times to launch without it. For Android 12-15, a patch has been provided in April's SPL. Everything prior to that is for the respective OEMs to find and fix themselves (though running Android 11 or earlier today comes with many more risks than just this, if not manually maintained by the OEM).
The clear risk is the presence of unauthorised applications in the work profile, and the potential for data leakage through them. The entire point of the work profile is to isolate corporate apps and data in a separately encrypted and siloed environment; allowing unauthorised applications can effectively bridge the cross-profile divide, and this is quite obviously bad.
Unlike Bastien's take, I'm less concerned about malicious, or Potentially Harmful Applications (PHAs) being a risk, as despite his claim, Google Play Protect scans over 200 billion applications a day across certified Android devices globally, including at-least daily checks for known bad applications, and real-time checks of non-Google Play installed applications. Obviously AOSP doesn't benefit from this, but it's a safe assumption most work profile deployments are using certified devices.
So this:
By design, MDM won’t be able to detect malicious or unwanted apps in the work profile
Is misleading. While MDM isn't necessarily the on-device engine scanning apps (that is GPP), Android's built-in protections work well with, and are enforced by, MDM. Of course vendors like Ivanti also have MTD built in, in which case the MDM will be able to detect these apps directly, in addition to GPP.
Suggesting unwanted apps can run amok on the other hand is a fair claim, and data leakage is a concern.
It just so happens if your EMM leverages the Android Management API and is not Intune, you don't have to do anything. Within a few minutes, as shown by my video above, AMAPI removes any unauthorised applications; arguably before these apps could really get much - if any - data.
Microsoft, despite being the AMAPI for other use cases, uses Company Portal (custom DPC) with work profile devices, though they may apparently be moving over #soon. As such they do not benefit from the AMAPI behaviour that automatically removes unauthorised apps, and these devices are susceptible when using Intune also.
If you're an Omnissa (Airwatch/WS1), SOTI or Ivanti (MobileIron) house, or other custom DPC platform, organisations have to be vigilant; keeping tabs on installed applications for work profile devices and locating outliers as they may appear.
Although Bastien says:
If you don’t have an MTD application deployed in your work profile, you won’t see anything and the malicious user can exfiltrate data for years…
This is also misleading. MTD will make things exponentially easier/faster to detect anomalies, but many MDMs show installed applications within application inventories synced from devices. While there may be gaps in this capability across the ecosystem, it's a common feature.
While this CVE is active across an estate, taking the time to pour through application inventories synced up could save a lot of hassle later on. This could potentially even be done via automated reports and some basic scripting through a vendor's APIs.
Other things you can do?
The linked article is obviously very heavily biased towards the benefits of MTD, but speaking without bias, I'm all for the additional security on mobile devices providing the solution isn't just a glorified antivirus, as these are generally ineffective in Android - doing little, if anything, more than Google Play Protect.
A full-featured MTD can help monitor not only applications, but network traffic, help prevent phishing/smishing) and much more. And for what it's worth, I think Lookout is a great option for this.
Here are some considerations I've written previously that should still be relevant.
I'd very much like to understand the potential impact this CVE has had, or will have, now that it's public and not universally patched. Are you seeing applications showing up in reports you don't expect? How are you handling it?
Get in touch, if desired!