Recently, when examining the Zscaler cloud for unusual activity, ThreatLabZ researchers found some questionable hits in relation to a particular domain: 9appsdownloading[.]com. Upon analysis, we found these requests being made from a popular browser that's available on Google Play and has more than 500 million downloads to date: the UC Browser app.
 | |
|
As we began to analyze the UC Browser app, we found that the requests were being made to download an additional Android Package Kit (APK) over an unsecured channel (HTTP over HTTPS). Downloading and/or updating components from a third-party source violates Google Play policy, which states: “An app may not download executable code (e.g., dex, JAR, .so files) from a source other than Google Play.”
We decided to explore further into the UC Browser app and found the following issues, which will be discussed in detail in this blog:
-
Downloading an additional APK from a third party – in violation of Google Play policy
-
Communication over an unsecured channel – opening doors to man-in-the-middle attacks
- Dropping an APK on external storage (/storage/emulated/0) – allowing other apps, with appropriate permissions, to tamper with the APK
We found another app called UC Browser Mini from the same developer with the same functionality and issues, and it dropped the same additional APK from a remote server. The screenshot below shows UC Mini on Google Play.
 | |
|
It is important to note that these issues have the potential to affect millions of Android users because the UC Browser app has been downloaded 500 million+ times and UC Mini has been downloaded 100 million+ times. The ThreatLabZ team has been in contact with Google, whose teams are investigating the apps.
Timeline:
August 13, 2019: Zscaler reported policy violation to Google.
August 13, 2019: Google promptly responded. Case assigned to an investigation team.
August 13 – September 25, 2019: Follow-up emails with research details.
September 27, 2019: Google confirmed policy violation by UC Browser and UC Mini. Google contacted UC developers to update the apps and remediate the policy violation.
Update: After Google's intervention, the Zscaler research team noticed that the latest version of both the apps, UC Browser and UC Mini, have stopped downloading the third-party app store.
Technical Details of UC Browser
Name: UC Browser
Package Name: com.UCMobile.intl
Installs: 500,000,000+ (500M +)
Developer: UCWeb Singapore Pte. Ltd.
1. Downloading an APK from a third party
Upon finding the UC Browser app as the main culprit, we decided to dig deeper into our analysis of the app. As soon as the app is installed, it displays basic activities (Android screens) to set up default language, topics of interest, location, and so on.
 | |
|
After some initial requests for news and notifications, the app sends multiple requests with redirections and finally drops an APK on to the user’s device. The screenshot below illustrates the chain of requests and redirects taking place:
 | |
|
This functionality of dropping another APK from a third-party source clearly violates Google Play’s policy, which includes the following:
“An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism. Likewise, an app may not download executable code (e.g., dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine and has limited access to Android APIs (such as JavaScript in a webview or browser).”
During our analysis, we found the APK being dropped on external storage but we did not find the APK being installed. It is possible that this functionality is still under development or there may be other reasons it wasn’t installed, such as exception, disabled unknown-sources option, or rooted device.
2. Communication over an unsecured channel
The APK was downloaded over an unsecured channel (HTTP over HTTPS), opening the possibility for man-in-the-middle (MiTM) attacks. In our research, we came across a recent Dr. Web blog post that talks about similar issues they saw with UC Browser downloading and installing libraries from remote servers. In that case, they talk about libraries being downloaded over HTTP and, in our case, we saw a completely new APK being dropped (this APK is also analyzed in the latter part of this blog).
The consequences of downloading and installing components over unsecured channels were well addressed in the Dr. Web blog, along with the MiTM vulnerability, so we will not address those issues further.
We noticed that the app analyzed by Dr. Web researchers had the same icon as our sample, but had a different full-name and a different developer. The screenshots below show the Dr. Web sample (left) compared to the Zscaler sample (right):
 | |
|
It could be that the same app had been uploaded again on Google Play with a different name and developer along with modified or enhanced code to download additional APKs.
3. Dropping an APK on external storage
We also noticed that the additional APK being dropped by this app is stored on external storage, which is world-readable by default. The screenshot below shows the location of the dropped APK:
 | |
|
An APK being placed on external storage, or any other app with storage permission (android:name=android.permission.READ/WRITE_EXTERNAL_STORAGE) can have access to this location and can tamper with the downloaded APK.
Analysis of the dropped APK
During our analysis, we noted that UC Browser was dropping the APK but not installing it. It is unclear whether this is due to the fact that the functionality is still under development or if there is another reason the APK is not installing. But we did want to find out what the APK contained, so we decided to manually install it and have a look inside. To our surprise, we found that the APK was actually a third-party app store named “9 Apps” with the package name com.mobile.indiapp.
 | |
|
After installing the app, it scans the device for installed apps. The app’s scanning and further activities can be seen in the screenshots below:
 | |
|
We also saw several adult apps available for download in this third-party app store. These apps can be seen in the screenshot below:
 | |
|
We tried downloading a small-sized app from the 9Apps store and, to our surprise, the app was downloaded from 9appsdownloading[.]com. This is the same domain that we mentioned at the beginning of this blog. The screenshot below shows the functionality in action:
 | |
|
Further scrutiny of Zscaler cloud traffic showed multiple requests for APK downloads from this 9appsdownloading[.]com domain. Within the last month, we found 130+ such requests. The hits can be seen in the Zscaler cloud dashboard:
 | |
|
Conclusion
The tactics used by UC Browser and UC Mini violate Google Play security policies and make it possible for any malicious app to gain entry into a user's device. While 9Apps, an app store for Android apps, is not a malicious site, we searched the domain using VirusTotal, which showed a number of detections:
 | |
|
It is too early to determine exactly what the UC Browser developers intended with their third-party APK, but it is clear that they are putting users at risk. And with more than 500 million downloads of UC Browser, that is a significant threat.
Because UC Browser downloads an unknown third-party app to devices over unsecured channels, those devices can become victim to man-in-the-middle (MiTM) attacks. Using MiTM, attackers can spy on the device and intercept or change its communications. The UC Browser app’s use of unsecured channels also allows attackers to install an arbitrary payload on a device that can perform a variety of activities, such as display phishing messages designed to steal personal data, including usernames, passwords, and credit card numbers.
Once a user device has been compromised, and that compromised device connects back at the office, attackers have the ability to establish a foothold in your network, so they can snoop, spread malware, or steal data.
