Smartphone apps are among the hottest areas in software development these days, for both consumer use and corporate needs.
By some accounts, smartphones users operate an average of 30 apps per month, employing 10 of those on a daily basis, and clocking almost 900 billion hours of app usage last year. Of course, many of those apps collect data about their users, streaming it to servers where it is often used by advertisers. This then acts as a revenue stream to fund further app development.
Apprehension about the extent to which apps may be harvesting data and using it without permission is not new, but a recent study by researchers in England, "Intra-Library Collusion: A Potential Privacy Nightmare on Smartphones," sheds fresh light on the issue, and illuminates a growing cause for concern: intra-library collusion, or ILC. The study's authors describe ILC as a privilege escalation vulnerability that, "allows libraries to secretly aggregate multiple sources of sensitive user data by leveraging the permissions that they have been granted within two or more apps."
ILC is made possible by a coding model in which app libraries are shared between apps, and in which a permission model does not adequately separate privileges from those of the app libraries they employ. This seems to be typified by the current Android environment, although the authors assert that many of their insights may hold true for the iOS platform, as well.
While this study provides valuable new data about the potential for ILC on smartphones, the underlying problem has long been debated.
How app libraries collude
Attacks based on permission redelegation were described in 2011, the same year that several researchers published proof-of-concept malware exploiting this weakness. A collaborative project to detect app collusion, ACiD, was spun up in 2014.
ACiD gives this example of collusion: "one app permitted to access personal data, which passes the data to a second app allowed to transmit data over the network." In other words, you might give app A permission to use geolocation, and deny that permission to app B, but through a shared library, app B might still get your location data, which is something to which you did not consent.
There are four significant findings in this latest ILC research. The first, based on a detailed enumeration of the app libraries that could be exploited, is that the current potential for abuse is enormous.
The second finding, which echoes the views of other researchers and explains why the ACiD project was created, is that ILC is difficult to detect. Even when manual code analysis is used, it is possible for apps themselves to look clean, but bad actors -- or ethically challenged marketers -- could be reaping the rewards of ILC with off-device data.
The third finding, given the current incentive structure of the app ecosystem, is how difficult it will be to remove ILC from the smartphone development environment.
The fourth finding, substantiated with a very useful review of prior research, is that Android app permission creep over time is a reality, one that will only exacerbate the ILC problem.
And this is where things really get frustrating for security professionals. Unlike the discovery of a vulnerability that can be patched, or an exploit that can be blocked, there is no obvious, practical defensive action that can be taken to reduce the ILC threat, given that a ban on the use of smartphones for company business will not fly in most organizations.
Privacy risks and GDPR
Makers of endpoint protection for smartphones and other mobile devices are aware of this threat and are working on the detection of attacks that leverage ILC to compromise the security of devices and data; this is a nontrivial task, given that two seemingly innocent apps can collude to conduct malicious activity. But the more immediate threat might be to privacy, given the financial gains that the report cites, and the exploitation of personal data by ILC.
In fact, privacy regulations could strengthen efforts to remove ILC from the app ecosystem. When you read the European Union's General Data Protection Regulation (GDPR), or even a short summary thereof, it is practically impossible to reconcile its requirements with a development model that permits ILC.
And, if it's unclear as to what a European privacy law has to do with permission models in app development, check out Article 25: data protection by design and by default. The emphasis on limiting and minimizing the collection and use of personal data during both the design and implementation phases of any information processing system is clear -- and clearly at odds with current practices.
While there is skepticism in some quarters about GDPR's impact outside of the EU, there is nevertheless a very real chance that some European residents will assert their newly legislated right to review, change or revoke data collection shortly after the law goes into effect on May 25, 2018. Potential targets of those actions include companies that make and use the collusion-susceptible app libraries highlighted in the latest research. And if there is one thing we know about GDPR, it's that potential fines could run into the millions based on global revenue.
Learn how IT can handle mobile security issues
Discover enterprise best practices for mobile security
Read more on how Docker APIs can be exploited by attackers