Android Malware, Permissions, and Side Channels

New Android malware keeps popping up, and the latest one to be publicly discussed is very typical of what we are seeing these days. And frankly, I haven’t found them very impressive. In short, the attack consists in recording phone calls, identifying calls to credit card support lines, then analyzing the recording to identify the tones corresponding to a credit card number, and finally transmitting this data to another piece of malware through hardware settings.

Basically, this attack shares the following characteristics with many other ones:

  • Exploit Android permissions. Android permissions are very wide, and labeled in simple terms. This means that there are many ways to abuse people, especially with combinations. In that particular case, the use of two collaborating applications is a way to hide combinations, but it also makes the attack more difficult.
  • Use a side channel for leaking data. Some side channels are obvious (like leaking data on Internet together with other data), and this one is trickier. In fact, there is always a tricky way to leak data, especially when you can do it one bit at a time.
  • Be a proof-of-concept. This malware works, but only in a lab. In the real world, it needs someone to download two pieces of malware, dial a credit card support hotline, type a credit card number, and do that for another reason then blocking the card. Possible, quite unlikely.

My main claim is that such a malware is quite unlikely to represent any kind of danger. The scheme is so complex that by the time people get credit card numbers stolen, the malware is very likely to be detected. My second claim is that the Android permission system is not worse than the others around: iOS doesn’t really use permissions, MIDP uses overly detailed ones (granted by network operators in most cases), etc. My third claim is that what really count is that the Android Market is able to vet applications; even if it doesn’t do much today, we can rest assured that Google will make sure that 2011 doesn’t become the year of mobile malware.

Nevertheless, the paper points a few interesting things about Android permissions, and some of them could be fixed:

  • The Read contact data permission gives access to the call history. I am not sure that I see the need for that. In fact, my main issue with that is that, in terms of privacy control, I believe that it’s very different to know who I know and who I actually call. I believe that this one should be fixed.
  • The Record audio permission allows an application to record the content of phone communication (as well as recording audio in the background, actually). In fact, that’s again a privacy issue: an application that records audio while it is the currently running application is fine; allowing that application to record audio from the background is a very different thing, which worries me. This one also deserves to be fixed.
  • The side channel actually doesn’t use any permission in most cases, since it uses channels that don’t require any, like setting the volume repeatedly. Here, I don’t think that there is a big problem, because getting data out is most likely not the main problem today. Five years ago, everybody was worried about connected applications; today, most people consider it normal for an application to be somehow connected to the net (for instance, an application can always claim to backup things, to have a social side, etc.). Malware doesn’t need to be bundled with sensitive, intelligent software, so complicated side channels probably represent a futile complexity.

To conclude, a word about hidden communication channels. I have worked on information flow static analysis, and we haven’t found many practical ways to identify hiddne information flows. Usually, these hidden flows do not use variables or communication APIs to leak data. Instead, they often leak a trickle of information using either an unnecesssarily convoluted computation (which is likely to attract the attention of a human reviewer, but is difficult to find for a static analyzer), or by looping on an apparently innocuous API method (this is what is done here, and we may have detected it using a static analyzer).

One Comment

Leave a Reply

Your email is never shared.Required fields are marked *