Study: Over 1000 Android apps on Google Play accessed user data without proper permissions

Study: Over 1000 Android apps on Google Play accessed user data without proper permissions

Despite user perception, Android is actually quite secure as a mobile OS. We generally accept the premise that the weakest link is the user; so long as you watch what you install and what permissions you grant, you should be safe from unauthorized access and distribution of your data. If you deny an Android app access to your location, then that app shouldn’t have any way to figure out where you are or where you’ve been. However, some app developers have figured out ways to get around Android’s permission model, according to researchers from the International Computer Science Institute (ICSI).


According to CNET, the study was presented last month at PrivacyCon after being responsibly disclosed to both Google and the FTC last September. Although the paper published on the FTC’s website doesn’t list the exact apps that the team flagged in their analysis (those details will come later at the Usenix Security conference next month), it does provide details on their analysis method and how the apps were bypassing Android’s permission model. For what it’s worth, Google says that the security and privacy changes that Google has introduced in Android Q will close these bypass methods, thus this paper provides valuable insight into Google’s justifications for some of the platform changes they’ve made in Android 10. Let’s dive in.

How >1000 Apps Bypassed Android’s Permission Model

The researchers distinguish between two different security circumvention techniques: side channels and covert channels. Side channel techniques involve getting access to particular information in a way that isn’t covered by the security mechanism; for example, apps used to be able to track a device’s location using the MAC address until Android Pie introduced MAC address randomization. Covert channel techniques involve two services cooperating to send data from one service that has valid access to one that does not; for example, an app that has been granted location access may share that data with an app that hasn’t been granted access.

The ICSI team analyzed 88,113 of the most popular Android apps from the U.S. Google Play Store and discovered over 1,000 apps and third-party libraries that employ side channels and/or covert channels to circumvent Android’s security measures so they can access the location data and persistent identifiers of users’ devices. Their full dataset consisted of 252,864 APKs since the team periodically scraped the Play Store for new versions of the 88,113 apps they planned to analyze. They initially tested each app’s behavior on a Google Nexus 5X running Android 6.0.1 Marshmallow but later retested their findings on a Google Pixel 2 running Android Pie to prove their findings were still valid as of the latest release at the time of the disclosure.

With this dataset, the team developed a method using dynamic and static analysis to detect circumvention of Android’s permission model. In other words, the team studied app behavior by auditing the app’s runtime behavior (dynamic analysis) or scanning the code for potentially malicious behavior (static analysis.) Of course, malicious app developers are aware of these techniques, using code obfuscation and dynamic code loading to make static analysis harder or TLS interception to detect when the app is running in a virtualized environment, so the ICSI team employed a mix of static and dynamic analysis (hybrid analysis) in their testing. As a result, the team discovered that the following data was being scraped by apps that did not have the required permissions:

  • IMEI: Since an IMEI is a unique, persistent identifier, it’s useful for online services to scrape so they can track individual devices. The team discovered that the Salmonads and Baidu SDKs were using a covert channel to read the IMEI. Apps with legitimate access to the IMEI were storing hidden files on the external storage containing the device’s IMEI so that other apps without legitimate access could read the IMEI. Identified apps using Baidu’s SDK in this manner include Disney’s theme park apps for Hong Kong and Shanghai, Samsung Health, and Samsung Browser.
  • Network MAC Address: The network MAC address is also a unique identifier, and ordinarily it’s protected by the ACCESS_NETWORK_STATE permission. According to the researchers, apps were using C++ native code to “invoke a number of unguarded UNIX system calls.” The team identified 42 apps using the Unity SDK to open a network socket and an ioctl to obtain the MAC address, though they noted that 748 out of the 12,408 apps contained the code in question while lacking the ACCESS_NETWORK_STATE permission.
  • Router MAC Address: The ACCESS_WIFI_STATE permission protects the BSSID, but reading the ARP cache in /proc/net/arp allows an app to obtain that data without needing any permissions. The researcher identified the OpenX SDK as using this side channel technique.
  • Geolocation: The researchers discovered that the Shutterfly app was accessing the location tags of photos’ EXIF metadata. All that’s required is the READ_EXTERNAL_STORAGE permission.

In Android Q, Google now requires that apps have the READ_PRIVILEGED_PHONE_STATE permission to read the IMEI. Devices running Android Q now transmit randomized MAC addresses by default. Finally, Android Q’s Scoped Storage changes mitigate the ability for apps to read the location data from photos. Thus, these concerns have been addressed in the latest Android release, but as we all know, it’ll take quite a while for the latest update to propagate.


Overall, this study provides an illuminating look into how some apps access data that should be protected behind permissions. The research only looked at a subset of what Google calls “dangerous” permissions, notably skipping over permissions like Bluetooth, contacts, and SMS. For the full details on this report, I recommend reading the paper submitted to the FTC.

About author

Mishaal Rahman
Mishaal Rahman

I am the former Editor-in-chief of XDA. In addition to breaking news on the Android OS and mobile devices, I used to manage all editorial and reviews content on the Portal.

We are reader supported. External links may earn us a commission.