We wrote yesterday about research by Paul Brodeur of Leviathan Security Group on security weaknesses that are built into Google’s Android mobile operating system. Brodeur was able to show, using a proof of concept application, that Android applications without any permissions can still access files used by other applications, including which applications are installed and a list of any readable files used by those applications. In this question and answer session, Brodeur corresponds with Threatpost about his ongoing work studying the Android operating system, and how a combination of loose application coding and insecure design makes Google’s Android a boon for advertisers and others who want to harvest data on mobile users.*
Threatpost: What’s the difference between this research and previous “no permissions android app” research? How do you expand on previous no-permissions application work by ViaForensics and the “Capability leaks in Android phones” paper by the folks at North Carolina State University that talked about the failure of Android to enforce permissions to applications?
Paul Brodeur: “Capability leaks in Android phones” focused on misusing pre-loaded apps that have permissions to escalate the access that an unprivileged application has. My proof of concept instead focuses on actions that are permitted by the Android API that, by themselves, are considered harmless but in aggregate may allow for nefarious activity. Their paper focused on specific smart phone models, whereas my demo is designed to run the same on any Android phone. My work expands on the work done by the researchers at Lookout in their Defcon 18 presentation, “These Aren’t The Permissions You’re Looking For“, but as their work was aimed at Android 2.2 some of the tricks they announced no longer work. Hopefully with the release of the source code, other people can pursue research in this area without having to start from scratch.
Threatpost: One big take-away from your research seems to be that, even with zero permissions, you can collect data stored locally (on the SD card) and that many apps use this in ways that the phone’s owners may not be aware of. The other take away appears to be that, with zero permissions apps, you can still access files used by other applications – that could expose them to attacks. You were able to collect data on the device itself, including information on the device hardware and software used, vendor and the AndroidID – whatever that is. Finally, you showed that there’s a way to exfiltrate this data.
Paul Brodeur: Yes, the contents of “external storage,” which is usually an SD card, can be read by any application. Apps that want to provide users the ability to move data off of the phone do so via the external storage, and that data may remain on the device much longer than the user intends. With any app able to read the contents, there are numerous things that could be done. Sure, the app can’t read your current location information, but it could read the location information out of any pictures you’ve taken. As for accessing files used by other apps, this is only possible if the app has poor permissions. There have been a few cases of this, such as with Skype and Lookout.
There’s quite a bit of identifying information that’s readable by any app even in the absence of specific permissions. Even though we cannot read the IMEI or IMSI without the required permission, we can easily determine the GSM/CDMA provider and the SIM provider. Using various entries in /proc, we can determine the software version and make a good guess at the hardware model.
The AndroidID is just a 64-bit number that’s generated when the phone’s OS boots for the first time. While in itself this value isn’t meaningful, it can be used to uniquely identify an Android device. If your goal is to track a user over time, though their software version may update and they may change SIM cards, their AndroidID will remain constant.
In addition to identifying information, the app is also able to gather the list of installed apps. While this may seem like a small privacy breach, it’s easy to imagine circumstances where a person’s apps may be considered embarrassing or personal.
Finally, with all that data collected, we can exfiltrate it by opening the browser to a URL of our choice. While this had been shown by the prior works of both viaForensics and Lookout, where a two-way communication method was used to relay information back and forth, I found I was able to make multiple browser calls on a timed interval to upload large amounts of data through the URL without waiting for a response from the server.
Threatpost: What are the applications of this research? Could this be leveraged practically by Android malware, say, or another type of attack?
Paul Brodeur: I think most Android malware we’ve seen are Trojan applications: an app that looks like a cool game but is instead malicious at its core. Those apps generally request permissions because users aer accustomed to granting them. For example, the very popular Angry Birds app requests full Internet access, your location, your phone’s identity, and the ability to write to external storage. I think it’s important for users to know that no matter what permissions they grant to an app, a lot of data can be collected about you and your smart phone if the app chooses to look for it.
Malware aside, I think the gathering of identifying data is more likely to be used by legitimate apps. In the upcoming paper “Unsafe Exposure Analysis of Mobile In-App Advertisement,” due to be released next week, the authors discuss how legitimate apps that include advertising libraries allow the associated ad networks to gather any data that the app itself can access. So, a legitimate app with GPS permissions is also handing off your location to the ad network. The advertiser’s job to correlate any data it gathers about you, possibly using multiple apps with different permissions, is made very easy by the unique AndroidID value which any app can read.
Threatpost: Have you brought this research to Google’s attention? If so, has there been any response back?
Paul Brodeur: I have not. As all of the functionality I’m using is permitted by the Android API, there’s really no security vulnerability to report. Several parties, including viaForensics and Lookup, have already brought attention to the browser exfiltration behavior, but as access to the browser is necessary for most apps, I doubt that behavior will change any time soon. Google’s own Android documentation clearly states that SD card storage should not be used for sensitive data, but some apps choose to ignore that suggestion.
Threatpost: Are there any easy remedies or workarounds for security conscious Android owners, especially with regard to storage on the SD card, etc.?
Paul Brodeur: Don’t store sensitive files on your SD card and move them off of the device as soon as possible, or encrypt them in some fashion. Look out for suspicious activity, such as your browser window being opened to an odd page when you don’t remember doing so. When it comes to installing new apps, be mindful of where it’s coming from and who the author is. It’s not 100% effective, but spending a bit of time checking an app author’s reputation is one of the best ways to avoid Trojan applications.
(*) Interview conducted via e-mail on April 10, 2012
