Apps Using Side and Covert Channels

Published by Joel Reardon on August 12, 2019August 12, 2019

The 2019 USENIX Security Symposium includes our study on the use of side and covert channels by apps in order to circumvent the permission system. In addition to our paper, we are writing a series of blog posts to explain our main findings. In this post, the first in the series, we provide the names, versions, and MD5 hashes of the affected apps (Android APKs).

Baidu

As we noted in a previous post, every phone has an IMEI, which is a hardware-based identifier that can be used for long-term tracking of users across apps and services (even if the user opts out of tracking in the phone’s privacy settings or resets the advertising ID). As a result, access to this identifier is protected by the READ_PHONE_STATE permission. We observed that apps with the Baidu SDK use the shared filesystem (the “SD card,” in Android parlance) to save the IMEI of the phone, when those apps have been granted the READ_PHONE_STATE permission. They do this so that other apps, also containing the Baidu SDK, but without the READ_PHONE_STATE permission, can access the IMEI outside of the permission system. The following apps were seen sending the IMEI when we tested them, despite not holding the READ_PHONE_STATE permission:

Salmonads

Similar to the technique used above, Salmonads also uses the SD card to save the IMEI of the phone, which circumvents the permission required to access it. The following apps were seen sending the IMEI when we tested them, despite not holding the READ_PHONE_STATE permission:

Shutterfly

EXIF is a standard for embedding metadata in digital photos, which can include information about the camera, but also location information. The Shutterfly app sends the EXIF data for all the photos it finds on your SD card. This can include precise geolocation information (e.g., GPS coordinates) and Shutterfly has code that processes location data directly and stores it in its own format. The app does not hold the location permission, despite transmitting users’ location trails to its servers (its privacy policy says that this data may be used for targeted advertising).

OpenX

OpenX is an advertising company that we found collecting the MAC address of the WiFi router (known as the “BSSID”) to which the phone was connected, which can be used as a surrogate for location. The OpenX SDK was able to do this without any permissions by reading the ARP cache on the device (when accessed through the Android API, this data is protected by the ACCESS_WIFI_STATE permission), which is available in the proc filesystem. The following apps were observed sending the router information without holding the ACCESS_WIFI_STATE permission:

Unity

Unity is a company that provides a game engine, an ad network for monetization, and other developer tools. We found that 710 apps accessed the phone’s hardware MAC address through IOCTLs and sent the hashes to stats.unity3d.com. The WiFi MAC address is a robust persistent identifier because it cannot be changed without extraordinary effort. On Android, as of version 6, no app should be able to access the phone MAC address under any circumstance; prior versions allowed it with the ACCESS_NETWORK_STATE permission. Because we tested these apps on Marshmallow (i.e., version 6), all of the times that Unity accessed the MAC address was due to exploitation of this side channel.