6 min read
While testing for a customer, we discovered a 0-day exploit in VMware Workspace ONE Launcher which allowed us to access to all data on the device and the internal network.
In a modern workplace, phones and tablets are often used to enable employees to perform certain tasks. They’re easy and cheap to roll out, users are familiar with them, and specialized software makes it possible to control the use of them – in theory.
Overview of VMware Workspace ONE Launcher
VMware Workspace ONE Launcher allows companies to restrict Android devices to be used only for the intended purpose. It replaces the default “Home” menu with its own application screen that is using Android’s “appear on top” setting. On Samsung phones it also utilizes Samsung Knox, which allows to further restrict access to, for example, Bluetooth or Wi-Fi using built-in Samsung's mechanisms.
The software is widely used in retail, logistic and healthcare organisations to utilize Android devices shared within the company in a secure way and prevent users or unauthorized actors from accessing apps or phone functions that are outside the scope of the work-related tasks. In practice it means restricted workspace on the device with applications only allowed by the administrator.
Android is widely used across many device manufacturers. They often implement their own ideas on top of stock Android, like custom launchers, themes and features.
In terms of Samsung, the feature that has been helpful in bypassing the VMware solution turned out to be Samsung’s Edge Panels.
It is an app present in Galaxy devices since the time Samsung started to use curved screens on their flagship phones. Although many Galaxy phones are flat now, Edge panels stayed on as quick way to bring out handy side menu at any point of using the device to check the weather or access your favourite apps.
In our case, it turned out that many of those features, including Edge Panels were disabled via Samsung Knox in VMware Workspace administrative console. However, I discovered we could still use them after phone restarts – as long as it happened before relevant security policies were applied.
During the security assignment in May 2023, me and my teammate were supposed to check if the solution of the Client, that was using VMware Workspace One Launcher, was sufficient enough to restrict employees from using the Android phone in any other way than was intended by the employer.
The phones were supposed to be utilized while working in a remote location and were handling very sensitive data, hence the importance of restricting those devices to be used only for their intended purpose.
After a day of playing with physical devices I discovered the possibility to stop the Launcher application from fully starting, which allowed us to perform multiple unintended actions with the phone. To achieve this I utilized the Edge Panels described above.
After configuring the phones with HUB and launcher, setting it up to "appear on top" and waiting for all security policies to update, it is generally not possible to close the Launcher app or open any application that is outside the allowed apps list.
During phone booting-up, after providing the PIN code and unlock code, the phone presents a message that device is monitored and belongs to organization. The user can accept this message or make emergency call.
What is happening in the background is the Launcher is starting, which we can briefly see if we click on the emergency call button. However, it quickly gets covered back by the monitored message screen.
We noticed that whatever the user opens during this stage will be still opened in the background, just covered by the message screen.
The attempt to hold the power button and change the side button double-click function was made in order to open the "side-key settings" menu. This way, it was possible to set it up to open "files" program.
Everything above needed to be done before the launcher app fully boots-up. After that, the screen behind was covered by "appear-on-top" Launcher activity and the entire process needed to be repeated after a fresh restart.
The goal of the above was to get a chance for Samsung Edge Panel icon to appear on the right side of the screen. On tested phones the Edge Panels were disabled by Knox policy, however it was observed that the swipe edge panels icon sometimes appeared when reproducing the steps above.
If the user managed to open edge panels menu during the launcher app startup, it was possible to freeze the Launcher and open any application on the device. When this succeeded, the launcher would stay frozen, and we were able to browse through settings or other applications.
As you can see on the demo above, after getting to settings, it was possible to disable “appear on top” option for Launcher. 
After achieving the Launcher bypass, on Android 13, due to Samsung's new application switch menu, it was possible to view background apps (2 active in background) and force close them.
If the above technique is successful, we could force-close Launcher app and get access to the phone notifications menu. But even on Android 11, we were able to prevent launcher from taking over even after it’s restarted, by simply launching the application switch menu and opening an app from Edge panels.
Edge panels were always present after successfully executing the method above, even if they were disabled by Knox policy.
We can see that utilizing the above method will crash the launcher application. Android logs below were extracted after successfully exploiting the issue.
Results of exploitation
The result of successfully stopping Launcher from appearing on top, was that we gained access to settings, task switcher and all the applications on the phone.
Although adding a Google account was not possible, we successfully created a new Samsung account and after merging it with the device we could download and use any app from Galaxy Store.
Since in our use case, the phone had access to the company’s internal resources, we were able to download a shell application and perform a scan of the internal network:
Using phone code *#9900# that is specific to Samsung devices, we obtained Dumpstate logs from the phone that were useful in the next phases of the test.
Transferring files via USB was not possible due to the Knox policy, but we were able to extract files using Bluetooth:
It is important to note that restrictions applied via Samsung Knox were still in place. That means it was not possible to, for example, enable ADB access or turn on Wi-Fi on the specific phone I was working with, since those settings were restricted via Knox policies.
However, unrestricted access to all applications, most of the settings and files on the phone allowed us to utilize the device to compromise the Company’s resources on the internal network, that were previously protected by VMware Workspace ONE Launcher.
This issue is a good example of how security researchers should pay attention to specific Android implementations and versions. Many companies can add vendor-specific features on top of the stock system. It is important to always have an individual approach when testing Android devices and systems and look for addons that are not a part of the stock OS.
This is also a very good example of a difference between testing mobile applications in emulators vs physical devices. As good as emulators have become in recent years, it is hard to replace having physical access, being able to touch the screen and running a program on the real hardware and software environment it is intended to run on.
I would like to thank VMware Security Team for addressing the issue and very good communication during fixing time.
Timeline
Øystein Balstad : Apr 21, 2023 2:50:21 PM
Recently, we have had the opportunity to learn a little about what Russian intelligence officers spend their days doing in Norway. Will the...
Pål André : Mar 15, 2023 3:05:02 PM
Pål André : Mar 15, 2023 3:10:16 PM
Microsoft has released security updates to address a critical Windows zero-day vulnerability known as Follina, that has been actively exploited in...
