Exodus Privacy, a non-profit organization that has developed a privacy auditing platform for Android apps, has published some troubling statistics on the state of mobile data collection: most apps use some sort of tracker, and many use more than one. These trackers include advertising and analytics platforms, crash reporting and QA systems, and may come from well-known companies such as Yahoo or Salesforce, or even Google – the same company responsible for Android security and the Play Store. They aren’t limited to questionable flashlight apps either: Slack, a common workplace communication app, contains three trackers; Expedia, often used for booking travel, has seven; and Spotify, a popular music app, has eleven.
In total, Exodus is currently analyzing Android apps for 71 third-party tracking systems. Researchers at the Yale Privacy Lab are coming up with similar results to the Exodus work, and projects such as Haystack are ongoing. Monetization of free apps through advertising isn’t a new concept, but many people will likely be surprised to hear how sophisticated the tools have become and how widespread their usage is. Modern analytics platforms correlate user actions and behaviors inside apps and on the web, log detailed information from the multitude of sensors on devices, and continuously track network connections in order to cross-reference them to geolocation data. The value of these platforms is in the data they collect. But once a user’s information leaves the device, what happens to it?
The initial HospitalGown vulnerability discovery by Appthority in May 2017 connected approximately 21,000 unsecured Elasticsearch servers back to over 1000 apps gathering and sending data. (Disclosure: I work for Appthority and contributed to the HospitalGown research.) The vulnerability in many of these apps was present not in the main app code, but in third party libraries and SDKs – trackers similar to the ones listed by Exodus. The data exposure risk here is significant: a sample of only 4 percent of these vulnerable apps revealed over 160GB of data, more than 280 million records, was exposed. In multiple cases, this data was observed to have been ransomed by unknown attackers.
top security certifications: Who they’re for, what they cost, and which you need. | Get the latest from CSO by signing up for our newsletters. ]
What data was exposed? In some cases, it was application data, very specific to the app’s use. For example, an app by Jacto, a global manufacturer of agricultural machinery, revealed sensor readings, telemetry, and detailed operational data for large agricultural equipment. But in many more cases, the data exposed is everything the app and device can collect about the user, including personally identifiable information (PII) such as email address, phone number, carrier information, and even the user’s location.
This is the default for many of these tracker platforms: collect everything possible with hopes of finding ways to monetize the data in the future, which is particularly problematic given vulnerabilities like HospitalGown. One of the advertising trackers listed by Exodus had a backend server open and exposed, providing data collected by the SDK across tens to hundreds of apps, and millions of downloads, to anyone interested in harvesting it.
Third party tracker code makes it harder for everyone to understand the privacy implications of using apps, even the developers of those apps. In some cases, the tracker libraries will implement functionality beyond what the app gives permission for (and may describe in the EULA, if they are responsible); for example, a version of the Google AdMob advertising library has code that implements SMS functionality, even if it is not used for analytics and apps do not give the library the appropriate permissions for it ever to be used. In many cases, developers themselves don’t fully understand what the app they’ve built is capable of doing.
Enterprises are aware of this problem, especially with BYOD or COPE devices blending company and personal data. In addition to the data initially compromised via a tracking component in an app, enterprises are concerned about the risk of secondary attacks on their resources, enabled by this data – whether technical, such as by compromised passwords or device reconnaissance, or social, using collected data to craft phishing attacks well tailored to individual targets.
For multinational or Europe-based enterprises, another emerging mobile concern comes in the form of compliance to General Data Protection Regulation, or GDPR. Leaky mobile apps present an especially worrisome risk, as they facilitate the transfer of personal and sensitive data across borders. GDPR regulation can expose companies to severe financial fines for not safeguarding sensitive data. If we consider how common it is to see apps harvesting user data, tracking user location and actions, and sharing or storing this information in an insecure manner, it’s only a matter of time before companies face steep penalties for not monitoring for and eliminating mobile app risk on their employee devices.
So, how do enterprises protect themselves against these threats? The first step is identification. Tracker libraries and SDKs can be identified with a combination of static (source code) and dynamic (program execution, network traffic) app analysis. These analysis methods can also identify the type and scope of data that is collected and sent over the network, allowing security administrators to assign a risk value to the presence of certain code. Administrators can also identify where the data is going, such as to another country or to an unsecured data store, and determine the associated risk with that behavior as well.
Maintaining mobile data privacy and preventing data loss may be a difficult task, but it isn’t impossible. Real world use cases show that the most common reasons for enterprises blacklisting iOS apps are for privacy concerns, including sending SMSes, tracking location, or sending sensitive data unencrypted. Unfortunately, it is almost impossible to completely restrict app use to those that collect little to no data. It’s also not as simple as treating leaky apps as malware – all the apps discussed here are legitimate, working as designed. However, blocking app use where critical data access and transmission is confirmed can prevent loss and avoid the possibility of secondary attacks.
This article is published as part of the IDG Contributor Network. Want to Join?
