The Summary Version:

The impending Android Malware Apocalypse is overrated, over-hyped and overused to sell more apps and extend control onto mobile devices. That said, it is a perception widely pushed by the media who copy and paste vendor news releases thus the public are beginning to accept the threat as being real. My opinion is that the available attack vectors are currently quite limited and nowhere near as bad as the industry press and mobile vendors are making out. You can’t blame them for pushing the stories though, one group makes its money getting eyeballs to articles, the other by selling cures to the risks…

What we can do as an industry is limited by the overall reluctance for users to double check what they are doing, coupled with the difficult situation created when differentiating device/product or service in a low-margin, rapidly evolving market.

The Rob Rantâ„¢ on device and market behavior version:

Reality:

The *reality* (unless you are an Anti-* vendor) is that only a very small percentage of people stray outside of their mobile marketplaces to download applications, and realistically only a small percentage of THOSE are affected by malicious code. There are sufficient warnings on iOS and Android devices for pretty much everyone to maintain arms length liability for any user issues should non-marketplace apps be loaded to a device resulting in an incident.

But that doesn’t solve the problem that people are going to be facing once smart devices become more prolific, more functionality is ported to them, and the bad-guys start getting themselves more organised… That problem is a far tougher nut to crack but crack it we must…

The Future:

In terms of privacy and liability, I imagine we (as an industry) will have a case^* to answer within the year – but the vulnerability will be more of a zero day attack or a non-affiliated ‘update’ to a well known application (say for example an Angry Birds level unlock). We have no known plans to address this, nor do we have the resources, as any solution would require significant alignment with the device vendors until such time as ice-cream sand wedge (ICS)

[ ^*”a case” does not imply legal liability, I’m predicting more of a moral obligation to better serve the folks out there in the real world. ]

Attack Vectors:

The real ‘value’ in a mobile device exploit is to either profile a target for a future attack, or to gain access to information held on, or accessed via the device itself. For the sake of a cohesive rant, let’s label these vectors “Privacy” and “Access”.

Privacy

This can only be solved via a mix of user education, device manufacturer compliance^*, and adequate ecosystem policing^**.

• User Education is a tough  nut to crack, looking at Windows users as an example, the infection rates reported in the Microsoft SIR #11 (October 2011 – Infographic Here) found that over 44% of infections REQUIRED user interaction to be effective. After all these years, people are still programmed to click the “Whatever” button to get whatever it is they think they are doing to happen and deliver the result they were looking for. While Googles August 2011 analysis puts the number of Social Engineering enabled sites distributing malware at only 2%, that 2% is truly effective – especially when coupled with socially connected applications or environments such as FaceBook where implied trust from ‘friends’ convinces many users to click a link without considering the plausibility of the story or consequences of the interaction with the as-yet-unknown additional functionality.
• Device Manufacturer Compliance is oxymoronic in an environment such as the Android ecosystem. Manufacturers are all looking to differentiate themselves from an otherwise (cl)open system and many are doing this with eye-candy and/or additions to the base functionality offered by the mobile OS. Even demonstrations at this years Consumer Electronics Show had (Samsung? – sorry, the reference is lost in yesterdays CES 2012 coverage) front ending their demonstrations with “of course, you can switch this off”. Many of these manufacturers (and of course application developers) are over-reaching the API calls required to make their product work in an effort to monitise or otherwise profile their user base in this low margin/micro-payment world.
• Ecosystem Policing carries with it it’s own difficult balance of an open-but-closed-but-open Android Marketplace versus the closed-but-inconsistent AppStore from Apple. Simply by looking at application submissions and the API connections they request when compared against the function of the app, the gatekeepers could discern if an app is overreaching in terms of access requested – for such applications, they could be sandboxed before public availability to track the apps true interactions and/or have global block lists to services such as premium SMS applied to them in an effort to limit the exposure to the users. This of course takes time and resource, but would also provide the ability for shutting down potential threats before they hit ‘the wild’. Both Apple and Google have insanely smart people working for them and, by simple comparisons of stated functionality versus required API access, applications could be pre-sorted for further investigation – even heuristic comparisions could be established to combat developers previously pinged for submitting malicious content from being able to use the same code or coding style in future attempts to get through the validation gates.

All of the points discussed above allow malicious code to make its way onto a device and access whatever has been ‘agreed to’. As such, maintaining privacy of oneself – not to mention the privacy implications when considering the proxy permission granted by a user to OTHERS privacy (such as exposing the contacts loaded on a phone to an otherwise unknown developer of an SMS application – do the contacts ONLY get used to label the recipient/sender of a message, or are they transferred to an external server where they are semantically mined to discover the social relationships between the app users and the contacts and the level of trust/conversation they engage in?)

[ ^*Note that the CarrierIQ debacle gained its initial traction from manufacturers ‘hiding’ and/or misconfiguring the functionality that CIQ provided. ]

[ ^**As much as I am loathe to use the ‘ecosystem’ tag – the owners of the OS/Marketplace are better placed than most to be gatekeepers on appropriate functionality. ]

Access

Much of the points raised above for personal privacy also apply to access to data held on and accessed via the device. I’ve kind of run out of steam/caffeine or care-quotient for the moment but I’ll return to this point to detail it some more. As bullet points, access must consider the following:

• Device Ownership – The Consumerisation of IT was the buzz-phrase of 2011 and it looks like this will continue into the new year with more people wanting to bring their devices into the enterprise. Who *owns* the devices connecting to, accessing and storing your data? What then can/can’t you do to encourage good behaviors or enforce policy compliance?
• Device Control – As above, but complicated by the multi-use of the device for Work and Personal use. There is some work in this space in regards to having separate profiles/virtual instances for work and private use with relevant control levels on each.
• Separation of Personal / Corporate use (applications and data) – The mobile is a small computer with a whole load of storage how effective are the controls (above) that can be placed on the device when ensuring an ‘air-gap’ exists between the Corporate and Personal data usage?
• User Interface/User Experience (UI/Ux) – if it’s unwieldy (UI) or time consuming (Ux) to do something ‘right’ on a small screen/touch interface, the odds are good that the user will find an alternative application or method of getting the task done.
• Connectivity – Mobile Data or WiFi? Protection levels?
• Nature of the Device – They’re small, portable and they get lost, a lot. Often people don’t know that the device is truely ‘lost’ until long enough after the even for the battery levels to be low enough for functionality such as Data Access and GPS to be switched off by the devices internal power management systems. If you can’t find it you can’t retrieve it, if you can’t access it, you can’t remotely wipe it.
• Fragmentation – Device capabilities are limited by their OS revisions and the vulnerabilities they are susceptible to are also dictated by what version the device is (capable of) running. As seen last year, there is a frightening number of Android devices which are being left behind by their manufacturers as they struggle to keep up with the changes to the OS, the demands of their customer base and the progression of technologies that are being crammed into these Tardis like, pocket-sized super-computers.