Disclosure and the Many Flavors of Android

Inside the different Android versions and flavors. What happens when a security device vulnerability has been found and the vendor fixes it.

By

Recently we announced a major security vulnerability on Android devices we had found with the help of our friends at Orange. It led to several interesting conversations around security disclosure from some friends in the industry. There were some people who stated we shouldn’t publicly disclose any issue because it makes Android look bad. It was funny because I’m old and crusty enough to remember these types of conversations before there was Android or iOS which led to things like RFPolicy.

I think it’s worth discussing why disclosure is vital but also why not disclosing creates a dangerous environment. The modern way of thinking about security doesn’t revolve around a binary state of being (i.e., are we secure or not?). But security is about risk; understanding what your risks are and what steps you’re taking to mitigate those risks.

There are companies such as Apple, but also Android vendors, which take a secretive approach to security. They disclose as little information as needed about security issues that have been found, and their impact. They tend to view security more in the context of PR than risk. This creates a strange paradox because people feel their device is secure. But as demonstrated in recent attacks on iMessage, Apple subscribes to the illusion of security and not the practicality of security. Without visibility, you’re giving a sense of security, but paradoxically, you have no insight into whether that is a valid state or not. This really isn’t security. Cybersecurity is about understanding and mitigating risk. It’s not possible to mitigate or understand your risk without visibility. This is why disclosure is important.

Disclosure is important in the context of when an issue has been found. It’s important to disclose when the vendor chooses to ignore an issue and just as important to disclose when an issue has been found and the vendor fixes it. Why? Because it shows that the vendor is either taking security seriously in the latter case, or doesn’t care in the former case. It also allows the end users to understand what the issue is and how urgently they need to mitigate the issue or not.

Orange, who takes their security very seriously, engages Quokka to actively audit their devices before they hit the market. They’re not reacting to disclosures–they are actively seeking them out. If you’re a CIO looking at which devices you should use for your fleet, picking a device from a manufacturer which doesn’t view security as simply a matter of PR but proactively audits their devices might be a good place to start your search.

This isn’t a cautionary tale of pitting Android and iOS against each other. Whilst people like to split the mobile market conveniently into those 2 sections, the reality is different because there isn’t a company which sells a pure Android device.

The breakdown of the mobile markets at the time of writing this is approximately:

Many Flavors of Android

You’re probably wondering who some of those vendors are, right? Well, you may not recognize their name and logos but you will recognize many of their phones currently on the market because a lot of mobile operators’ own brand devices will be rebadged devices from these vendors.

Normally, we would lump these together to 14% Apple, 86% Android. But the thing is, it really isn’t accurate. There are significant differences between all those vendors. Just like there isn’t a single Linux distro, there isn’t a single Android platform. That Android device really is a base of stock Android coupled with system apps. If you’re on an Android device you can go to Settings->Apps->All Apps, then click on the Hamburger and select Show System.

What are System Apps?

So what are system apps? Technically, they’re apps which are preinstalled in the Android ROM for your device. These apps can’t be removed and most of them have escalated permissions compared to normal installed apps. Some of them are installed as part of stock Android, but other ones are needed as device drivers; if you removed them or stopped them, they would break the phone.

Let’s say you have decided to make a new Android device. You’re pulling components off the shelves. You grab Adreno 620 to be your GPU like a Pixel 5. Well, you’re going to need to add the Adreno Graphics Driver APK and so on. You’ll most likely also create your own system apps to add your secret sauce.

When you’re creating your device, you want to make sure that you’re using the latest version of Android because it’s the most secure. You’ve already lined up a roadmap to make sure you’re ready to support all the security updates for your device. You’re using Kryptowire to make sure all those custom apps of yours don’t have issues. All in all, you feel good. You’ve created a great device and you feel like the device you’ve created will be secure. Now you’re off to the races, shipping millions of these devices. Good for you.

I’ve got a question for you: is the device secure? Chances are you don’t know. Why? You did everything a responsible mobile device manufacturer did, you’re running the latest Android patches, you’ve checked your apps you created for that device.

Why am I making the assertion that you don’t know? Because of those drivers we talked about earlier. This is even more prevalent if you’re not building a device but rebadging another one. Those drivers have elevated permissions and they can’t be removed. But do you know what they’re doing? Even more importantly, how are they doing it?

Are all types of Android the same?

This is why not all Android devices using the same version are the same. Because those APKs which run with elevated privileges are unknown and they can have a huge impact on the risks associated with that device. In the case of the recent disclosure, it was one of those apps AutoSLT broke the security model, and broke it in a very bad way.

Orange was proactive and audited the device using Kryptowire so they were able to head off any issues before a single one of those phones was shipped. Kryptowire was able to flag the issue, allowing Orange to successfully rectify the issue.

So, it’s important to realize not all Android devices are the same, and it’s really disingenuous to lump them all together from a security standpoint. Companies like Orange put time and effort into security, and the results make mobile devices better, safer, and respectful of the user’s privacy.

Why did Orange pick Kryptowire to help with the auditing? Well, when we state we’re an Android and iOS security company, we mean it. It’s not just SAST, DAST, IAST, MAST–it’s about being a holistic security company on Android and iOS. Understanding every layer of the platform and how they interact with each other. We understand these platforms in a way few other companies do–from the hardware layer to the downloaded app. And because of this we’re able to offer services which wouldn’t be possible for other more generalist companies.

There is a paradigm shift. The future of consumer computing is Android and iOS. This change brings new challenges and new ways of thinking about security. Kryptowire is at the forefront of tackling these challenges. We help you to understand and mitigate these issues both as a developer and as an enterprise as a whole. Check out the Kryptowire website for Enterprise Mobile Security to understand how we do that.

Related Content