A Look Back at Google’s Android Security Improvements in 2016
We are three months into the new year, but it’s never a bad idea to look back at 2016 and take stock of what happened. Google’s Android Security 2016 Year in Review makes it pretty easy to do so.
Google’s report highlights the steps they took in the past year to keep Android devices safe, such as the release of the Safe Browsing API, file-based encryption, and media server hardening, to name a few. More importantly, they quantify the impacts of many of these improvements.
Using Duo’s population of nearly one million active Android devices, we are able to provide some context and make some apt comparisons in the areas of security update adoption, device compatibility and integrity, and screen lock usage. Moreover, since our data is compromised of Android devices used for work purposes, we can illuminate the differences between these devices and Android devices in general.
SafetyNet and Device Checks
In the past year, Google made an important change to the SafetyNet Attestation API by adding the basicIntegrity field. Now, in addition to checking that the device matches a known-good Android profile, developers can also check whether a device has likely been tampered with. At the end of 2016, we began leveraging the SafetyNet API to improve our assessments of device health.
In addition to checking the basic integrity of the device, we also use the ctsProfileMatch to ensure that devices match the profile of a device which has passed Android’s Compatibility Test Suite. Our SafetyNet data shows that 95.7% of devices used in the US have a CTS profile match. That number is on par with the 94% reported by Google.
These figures show that the vast majority of Android devices, whether they were used for work or not, fulfill Android’s security and compatibility requirements.
Patching Again; Yes, Patching
While the Android security bulletins began in 2015, 2016 was the first full year of their monthly patches. Google mentions in their report that “over half of the top 50 devices worldwide had a recent security patch.” That number is pretty impressive when you consider the fact that devices that aren’t part of the Nexus or Pixel family are at the mercy of their OEM or carrier as to when (or if) they would receive these updates.
Even though we’ve previously written about the importance of applying these security patches, the Duo Labs team took another look at our endpoint data to see how Android users were doing as of the end of February 2017. When we analyzed the rates at which users applied the monthly security updates for the top 50 models in our dataset, we found that only 35.9% of devices were on one of the patches that had been released in 2017, which means that most Android devices are vulnerable to some, if not all of the 38 critical CVEs that have been patched this year.
So that’s the state of affairs as it relates to patches released in 2017, but let’s see how things look for the patches associated with QuadRooter. For those who may not be familiar with QuadRooter, it was a set of vulnerabilities that could be leveraged to perform privilege escalation on Android devices built using a Qualcomm chipset if a user installed a malicious app and didn’t have Verify Apps turned on.
The thing to note here is not the set of vulnerabilities or its potential impact, but that the last patch for these vulnerabilities was released back in September. When analyzing the data associated with the affected devices, we found that 39.8% of them had not applied the aforementioned update.
With a sizable amount of devices still being susceptible to attacks associated with vulnerabilities that were patched five months ago, it is apparent that we still have a lot of work to do when it comes to relaying the importance of these monthly updates. While the numbers above might not look that great, it’s not all gloom and doom. It appears 96.2% of Android devices are on an OS version or could upgrade to an OS version that would allow them to receive the monthly security patches.
In the category of on-device protections, Google also improved Smart Lock in 2016. In their Year in Review, they stated, “Devices running Android 7.0 and above prompt users to set a lock screen and enable Smart Lock’s on-body detection to remove the friction of entering a PIN or password.” With lock screens being the first line of defense to attackers who have access to the phone, advancements in this area that are more user-centric are a welcome sight.
While those opinions are purely qualitative, Google reported that 48.9% of devices enabled a secure screen lock; the numbers that we have in our dataset are a good deal higher with 70.7% of Android devices having a screen lock enabled. A potential reason for that difference is because devices in our dataset are more likely to be subject to some type of policy which makes users enable a screen lock on their devices. Nevertheless, that 70.7% stands as a 5% increase over the numbers we saw around this time last year.
So, there’s a substantial difference when we compare Android devices used for work and Android devices in general as it relates to having a secure screen lock, but things get even more interesting when we make comparisons across platforms. When looking at our endpoint data and specifically iOS devices, we found that 99% of devices were using a passcode. That’s a pretty huge number; however, the aforementioned figures only describe the what and not the why.
One hypothesis is that Touch ID plays a role. Out of the box, iOS users on newer hardware are guided through setting up Touch ID, which requires a screen lock to be configured. In our dataset, we see that 91% of iOS devices support Touch ID and 86% of those devices have configured it. Those numbers are a bit lower when it comes to Android with 71% of devices supporting fingerprint unlock and 65% of them having it configured.
First, we think it’s great that Google has released this report and hope that they continue to publish data like this in the future. Second, our analysis above shows that there are substantial differences in the areas that we covered as it relates to the devices in our dataset and Google’s. While these differences can be partially explained by the reasons we outline in their respective sections, another reason is because our dataset focuses on a particular subset of devices used for work and predominantly by individuals in North America and Western Europe.
Last, we believe that Google continues to create and improve the security mechanisms on the device to protect their users. And while creating these features is half the battle, the next step (and potentially harder challenge) is getting users to adopt them.