Thoughts on Google’s Android Security 2014 Year in Review

androidI have finally got round to reading Google’s ‘Android Security 2014 Year in Review’ (pdf). I believe it’s mainly a public relations exercise to assure everyone that Android is safe and that Google is being proactive in improving security. However, having read the report it’s easy to come away with the impression that everything’s ok. There are few places in the report I thought “Yes, but…”.

First an obvious one. Google say they “provided device manufacturers with ongoing support for fixing security vulnerabilities in devices, including development of 79 security patches”. However, what they don’t say is that very few of them made their way onto consumers devices.

Google say “Fewer than 0.15% of devices that download only from Google Play had a Potentially Harmful Application (PHA) installed”. This doesn’t sound many. As an end user you will probably be comforted by such a statistic. However, what if you are a company with say 1000 employees? Statistically, at least one of them might be leaking company information. What if you are a bank with millions of customers using a banking app? If your app doesn’t adequately secure data then a very large number of people could be affected. I think what this means for developers is that just because there’s a low chance of infection, apps should still take exceptional steps to protect their own sensitive data and not solely rely on the fact the platform is secure most of the time. The fact that Android is “secure most of the time” is only of significance for end users.

androidphas

There’s lots of emphasis on Google’s Verify Apps that checks apps at time of install. This won’t catch everything. Attackers are getting good at installing skeleton apps and later downloading extra functionality after Verify Apps has stopped looking.

Also remember, security isn’t only about PHAs being installed. It’s also about the ability to easily obtain information from stolen devices, reverse engineer apps and other such activities that can cause nefarious deeds without even installing an app under Google’s Verify Apps.

GSMA Mobile Economy Report 2015

GSMAThe GSMA has a recent free report (PDF) into The Mobile Economy 2015. The 78 pages are a mine of information for any startup needing a global view of mobile. Here are a few insights I found interesting.

There’s often talk of how much (or little) money there is in devices or apps. However, how do these actually compare to each other and how do they compare to the money made by network operators? The following chart shows the World GDP split by mobile area. It shows the majority of the commerce is actually in network operators…

gsmagdp

 

Another is interesting chart is the one showing commercial NFC-based payment launches over time…

gsmanfcpayments

I didn’t realise there were so many launches outside of Apple Pay.

iOS Mobile App Security

imasI have written a lot about Android security so here’s something on iOS to help redress the balance. iOS has similar challenges with encrypting data, enabling authentication and needs similar techniques such as detecting tampering via jailbroken phones or attached debuggers. This week I came across iMAS that helps developers solve some of these problems.

iMAS is a free set of open source components that “helps developers encrypt app data, prompt for passwords, prevent app tampering, and enforce enterprise policies on iOS devices”. As on Android, it’s often best to use pre-defined components rather than re-invent your own mobile that are more likely to have security flaws.

Android for Embedded Projects

linuxdotcom.pngThe use of Android as an embedded platform interests me as I have worked on three such projects and those projects seem to have the most potential. Embedded projects are those that use Android to power a single-purpose device where the user interacts with just one app. According to VDC Research

“Embedded products running Android will gain share over the next few years. Over the last three years, Android shipments that did not include smartphones, tablets, and E-readers grew at a CAGR of 149.2 percent, culminating in about 15 million units shipped in 2014.”

VDC say that Android is currently eating into the share of Windows Embedded rather than Linux in areas such as automotive infotainment, medical devices, military handhelds, retail and signage. However, Android isn’t currently being used in areas more typically labeled IoT such as connected home and industrial automation.

Smartphone Shipments Cause Mobilegeddon

idc.gifIDC have some new research that shows how smartphone shipments are already much larger than for desktops and laptops and how the difference is likely to become even larger in the near future.

idcglobalsmartdeviceshipments.png

Expect more and more companies to develop for mobile first. It also explains Google’s “Mobilegeddon” changes coming April 21 when Google will have a great search engine result shuffle based on mobile-friendliness. However, the end goal for Google is probably to be able to target mobile and non-mobile ads more effectively.

Google’s Android for Work is Insecure

androidsecuritylogo.pngThere’s a very interesting article on "Android for Work: Demystified" that dissects Android for Work and concludes it isn’t that secure. The repercussions provide some important learnings for all apps that need to handle sensitive data.

Android for Work and Android disk encryption in general, suffer from a similar expectation and affliction. The expectation is that encrypted drives protect data which isn’t fully true. The affliction is that they only protect data ‘at rest’ while the phone isn’t running. Once the phone is running the drives are seen decrypted from software and can be accessed via root or via exploits that provide access as root.

The solution to the problem is, as the article hints, to encrypt the data itself and not just rely on the drive encryption. This is the crux of the message on my Android security web site. You need to define what data needs to be kept secure and protect it appropriately. Assume your app can and will be attacked and do your best to secure only the data that has to be secured. Don’t solely rely on mobile device management (MDM), drive encryption, apk re-packaging or any other higher level wrapper.

Tablet Growth Has Flatlined

idc.gifIDC has new research into tablet shipments and as a result has now reduced the forecast up to 2019. Android currently remains the leader with an expected 67.4% share this year while iOS is expected to have 25.6% share. Windows trails at 7%. The following chart shows how growth has flatlined…

idctabletshipmentsgrowth.png 

App Security Requirements

androidsecuritylogo.pngI believe that many Android (and iOS) developers have a blind spot for app security. Clients, product owners, product managers or whoever is responsible for the app rarely have security requirements and time-starved developers tend to ignore the problem.

What’s the problem? Well, on Android (see later for iOS) there are so many ways attackers can attack your app. Whether it’s re-packaging your app with malware, repackaging to circumvent functionality, stealing ip or stealing secure data an attacker has many choices of ways to attack. Methods include:

  • Unzipping, decompilation, recompilation and re-packaging of your code
  • Patching Android OS calls at runtime to intercept data
  • Examining runtime memory to see data
  • Taking a backup of app data and reading it offline

Some of these things are possible on unrooted devices and all these things are possible via a rooted device or, more seriously, via exploits that allow temporary access as root. Determined attackers can also create custom ROMs or emulator images that can intercept your app at given points in its lifecycle.

I encourage all Android developers to do some background reading. The droidsec Wiki is a great place to start to see the scale of the problem and the tools available. Unfortunately, there’s a lot more information on how to hack than there is on how to prevent hacking presumably because it’s more fun to break things than fix them. My Android Security site offers a ‘coding first’, guideline-based approach to prevent, as opposed to detect, security problems.

If you are a product owner or product manager I suggest you also research this area, define your secure data and, if necessary, uncover security requirements for your app.

For those iOS developers thinking, "Oh that’s Android, we are safe on iOS", you might like to take a look at Lookout’s latest assessment of iOS security and my previous post on Android vs iOS security.