Less than 1% of popular Android apps tested use the Google SafetyNet Attestation API

Google SafetyNet helps Android developers add a layer of security to their apps to protect their apps and users from a number of potential security threats including rooted/modified devices, known malicious URLs, malware, and malicious traffic. Recently Google has tried to encourage more developers to use the SafetyNet Attestation API, which allows an app to check whether it’s running on a known, standard build of Android (and not a modified, rooted, or potentially compromised device). We recently conducted a study of 3,000 apps published on the Google Play™ store to see whether its use has caught on with developers. We found that barely a smattering of the more popular Android apps have taken advantage of the APIs, and of those apps that have, not all of them have implemented the attestation API correctly.

What’s the problem with rooted Android devices anyway?

Rooting an Android device grants a user privileges above and beyond the norm (i.e., “root access”) to the installed Android OS. With root access, a user can modify the OS or install software the device manufacturer doesn’t allow. Rooting a device does not necessarily make it less secure, but many enterprises disallow it and rooting can create an adverse security environment for a mobile app.

The rooting process sidesteps certain security features built into standard Android builds (e.g., isolating apps from one another). In addition, rooting a device makes the user an administrator on the device. This combination of diminished security defenses and escalated privileges allows malware to wreak more havoc and steal more sensitive data such as credentials, contacts, confidential communications, and more.

In its security guidelines for developers of mobile payment acceptance apps, the PCI Security Standards Council recommends implementing controls that prevent root privileges on the device because “bypassing permissions can allow untrusted security decisions to be made, thus increasing the number of possible attack vectors.”

Guidance from the Federal Financial Institutions Examination Council (FFEIC) about mobile financial services and security recommends that financial institutions educate users on the risks of using a jailbroken/rooted device and carefully consider whether a rooted/jailbroken mobile device will be allowed to access their mobile services.

How does the Google SafetyNet Attestation API make Android Apps more secure?

As part of Google Play Services, SafetyNet helps a developer assess the health and safety of the devices upon which their app is installed. If an app uses the Attestation API check, for example, it won’t run on a rooted device or on a device that uses a modified OS. Google created the SafetyNet Attestation API to protect users from malware that monitors, or “spies on” mobile banking apps or payment apps such as Android Pay.

In 2016, a strain of Android malware called CopyCat infected 14 million devices and rooted approximately 8 million of them. Users don’t always know that their device has been compromised, and a rooted/modified OS can be a symptom of an infection. Malware with root access may also reside on a compromised device and attempt to steal sensitive files from the app or record keystrokes to steal a user’s banking credentials or other sensitive data. The SafetyNet Attestation API can prevent an app from running on a compromised device and potentially spilling sensitive user data.

Using the attestation API is a great way to make sensitive apps as secure as possible. On the other hand, people that use a modified version of Android won’t be able to use apps that implement the check. In May, Netflix stopped allowing the download of their mobile app to rooted devices to prevent the circumvention of digital rights management systems and protect against piracy. It was reported in January 2016 that 5 percent of Android devices are rooted.

Four Google SafetyNet API capabilities

SafetyNet consists of four different APIs:

• SafetyNet Attestation API – Profiles the device the app is attempting to run on, compares it to known device profiles, and identifies whether the profiled device may be rooted/modified or potentially compromised. With the API implemented, a mobile banking app can shut down if it’s running on a non-standard phone and protect a user against malware that might abuse root access. For an in-depth review of how the attestation API works, check out John Kozyrakis’s “Inside SafetyNet” blog series.
• SafetyNet Safe Browsing API: Examines a given URL within a mobile app, compares it to a list of URLs known by Google to be malicious, and presents a warning or blocks the website if it’s potentially a threat.
• SafetyNet reCAPTCHA API: Based on information from a Google risk analysis engine, an app verifies whether a person is interacting with the app. If it’s suspected that an automated script is interacting with the app, the app can shut itself down (e.g., to protect against brute-force attacks).
• SafetyNet Verify Apps API: Checks the device to determine whether any known potentially harmful apps are installed on the device. This can help prevent malware on a device from eavesdropping on a user’s interaction with a banking app with the objective of stealing credentials or other sensitive information.

Out with it, already: What percentage of popular Android apps use the Google SafetyNet Attestation API?

To survey how many popular apps on the Google Play store currently take advantage of Google SafetyNet, we downloaded 3,000 apps in a variety of genres and analyzed them to identify which apps made calls to any of the four SafetyNet APIs.

Roughly, the sample consisted of:

• The top 600 apps overall on the Google Play store
• 1,000 finance-related apps
• 1,200 of the top apps in other genres

A surprisingly small number of apps in the sample, only 23 or 0.77 percent, used SafetyNet. Google SafetyNet is a great feature to help developers include an additional layer of security in their apps and make users more secure. It’s good to see developers trying to do the right thing, however, our research shows that not all developers are implementing this security feature correctly.

One app in particular failed to follow Google’s instruction to “make sure that the compatibility check response actually came from the SafetyNet service and includes data that matches your request data.” In this app, the attestation check only occurred locally, which puts the trust in the client — a bad security model (see “Client-Side Enforcement of Server-Side Security” entry in the Common Weakness Enumeration list). SafetyNet Attestation API documentation also states, “We don’t recommend that you perform the verification directly in your app because, in that case, there is no guarantee that the verification logic itself hasn’t been modified.”

Other notable findings include:

• Four other apps in the sample incorporated a popular software development kit (SDK). That SDK uses two different implementations of the attestation API. The apps that leverage the SDK initially use a local check for rooted devices (which is not verified). However, at the time of an actual transaction, a second proper/secure implementation of the attestation API is used (i.e., with remote verification).
• Four other apps referenced the attestation API, but the checks failed to follow Google’s recommendations for performing those checks (e.g., didn’t verify that the result came from Google, didn’t validate the SSL certificate, or didn’t verify the signature of the message).
• 22 of 23 apps that used Google SafetyNet used the attestation API specifically. The one app that did not used only the Safe Browsing API.

Why aren’t more Android apps using the Google SafetyNet Attestation API?

We can’t say for sure why more Android developers don’t take advantage of the attestation API. We recommend that developers do everything they can to protect themselves, their apps, and their users against mobile app security, privacy, and compliance violations.

Developers should implement the Google SafetyNet Attestation API in their apps to protect against the potential risks associated with rooted devices running their apps. Sample apps available on GitHub use the API and provide examples of proper implementations: SafetyNet Helper and SafetyNet samples provided by Google.

Using the API, however, is only one part of an in-depth approach to mobile app security. For more than 50 tips on addressing security threats, addressing compliance gaps, and preventing privacy issues in mobile apps, download our Secure Mobile Development Best Practices guide.

We’re in the process of reaching out to the developers of the apps we identified that are not properly implementing the Google SafetyNet Attestation API. If you’re implementing aspects of Google SafetyNet into your mobile apps and want guidance from NowSecure, please use our contact form.