Image by Andrew Martin from Pixabay
The Android app store contains numerous Cloner Apps. These are an increasingly popular category that allow you to have multiple accounts associated with an app, such as a social media or messaging app. Our analysis shows that such apps introduce some really concerning potential security isolation risks that you should be aware of so that you can decide if you want to enable features to block the use of such cloner apps with your own app.
The typical presumption for an app is that an individual installation is associated with one account, so once you have logged in the first time an app will typically store a long lived access or refresh token so you don’t need to log in again every time you open the app. If you do have multiple accounts the process of continually logging out and then back in again is cumbersome. When launched, these cloner apps present a second launch window, with a different set of installed app icons. Each of these may be associated with a different account to that associated with the main app installation.
There is of course the whole question of why you might want to have multiple social media and messaging accounts, and hide those down inside a cloner app. But the nefarious motivations for all this is not really the topic here. The question is how exactly do these cloner apps work and what are the security concerns surrounding them?
Firstly, there are a lot of these cloner apps in the Play Store and some have many millions of downloads. Some seem very professionally put together and support paid premium models. Others seem somewhat less clean, with revenue models based on the requirement to watch ads every time you wish to launch your cloned app. Ironically, several of these apps do appear to be clones of each other - simply reskinned with ad revenue presumably redirected. The basic usage model of them all is very similar. You are asked to select an app that you have already installed on your device and then, with a few seconds delay, it is cloned into the launch area of the cloner app. When you launch it, it acts as a fresh installation unaware of the data held in the original version. From there you can easily set up another account.
Normally when you install an app it runs in its own sandbox within Android. The app runs in its own user process and standard Linux file permissions are used to ensure that it is only able to read its own files, and not those of other apps. This prevents apps from spying on each other’s data. Of course, there are always root exploits - bugs allowing any app to achieve root and attain complete control over the system. Google and device manufacturers are in a constant race to close those exploits down. By and large though, the Android sandbox is very robust, built on the solid foundations of the core security isolation mechanisms of the Linux kernel that have been battle hardened over decades.
How then, can one app clone another app if this sandbox is meant to be protecting against this sort of thing. Firstly, a quirk of Android is that any app installed is able to see what other apps are installed on your device without any special permissions. This allows the cloner app to list your other apps as possible selections for being cloned. Furthermore, through a further strange quirk it is actually possible for one app to read the APKs of other installed apps. This isn’t a security hole as such, since the APK is public and available from the Play Store, but it is convenient for cloner apps because they don’t need to interact with the store, only copy the already installed APKs.
But wait, how can the cloner app then launch another app from its own sandbox - surely that would be against the rules? Well that is the somewhat disturbing part of this story. It doesn’t. Actually any cloned app that you “launch” from inside the cloner app is still running as the cloner app. There is no app launch as such, the cloner app just takes on the visual personality of the app that was launched. This is demonstrated if the app asks for permission to access something. As the Android dialog shows, you are actually granting permission to the cloner app. When the cloned app saves any data, it is actually inside the data storage area for the cloner app. So the first lesson here is that you really must have trust in the cloner app, because it has access to all of the data within the apps that launch inside it and to all of the data made available for the permissions they request. Grant access to your messages and photos and the cloner app can see them too. Moreover, cloner apps can see all of the memory contents of the cloned app and observe all of the data that it is sending and receiving over the Internet - in its unencrypted form. So although we are not aware of any data breaches associated with cloner apps and these risks, this should definitely be of significant concern.
You should certainly never be trying to do your banking from inside a cloner app. But unfortunately the dangers are not clearly spelled out, and the fact that these apps are available in the Play Store imbues them with significant respectability.
Technically the way these cloners work is extremely impressive. The source code for VirtualApp demonstrates the level of complexity required. In effect cloner apps build a virtual sandbox inside of the real sandbox that the cloner app is actually running in. When an app is cloned, it is effectively linked into the cloner app itself. The cloner app can dynamically expand its capabilities to encompass those of any app it absorbs. The cloned app code is completely unaware of this though and can’t tell that it is not running in the raw Android environment. Underneath, however, the cloner runtime environment is working hard to maintain the illusion. For instance, the VirtualApp code intercepts all file access system calls at a low level and substitutes the pathnames that the cloned app thinks it is accessing, for the real ones in the real sandbox of the cloner app. It is quite an impressive trick to pull off, allowing different cloned apps to happily coexist as part of one big cloner app without them realising this reality. Any call the cloned app makes to the Android framework can be both observed and manipulated by the cloner app. For instance, the Advertising ID you get inside the virtual sandbox is different from the real one, as if you are running on a different device.
There are limits to this virtual sandbox technique, however. It is clear from our examination of the code that there are ways for an individual app to break out of the virtual sandbox and access the data of other apps installed in the same cloner. So there are distinct security risks lurking here. Even if the cloner app itself has no malicious intent, it is possible for an app that is installed inside the cloner to break out of its virtual sandbox with the ill intent of stealing data from its neighbours. The isolation of data between apps installed inside the same cloner is dramatically poorer than that offered by the real Android OS.
The dangers are amply demonstrated by VirtualXposed which, at the time of writing, was freely available in the Play Store. Xposed is a modding framework that normally requires root permissions. In this case it is typically used to apply cheats to games that are installed inside the VirtualXposed app, which is able to effectively wield root permissions over any app that runs inside it. There is no practical limit to the modifications it can make or the data it can observe.
We have added detection of cloner apps in our Approov 2.3 release. Approov can now tell if an app is running in a real sandbox or the faked virtual sandbox of a cloner app. In fact the detections for this have been pushed out to all of our customers via an Over-The-Air update for the security checks running in the Approov SDKs. Customers now see an flag-cloned entry in their metrics for devices that are running in a cloned environment. You can see which of our security Rejection Policies now disallow apps running inside a cloned environment. Since we are taking the view that this represents a significant security risk we are now failing requests from these environments, except in our most lenient security policies (such as allow-root-and-jailbroken).
We think though that perhaps a wider debate is needed about these apps and the potential risks to personal data they pose. Although these don’t seem to have been used as part of a wide scale attack vector so far there is no room for complacency. We note the Package Visibility changes forthcoming in Android 11, and this might be a welcome constraint on such apps.
