Safetynet:google ' s tamper detection-part 1

Original address: https://koz.io/inside-safetynet/

Update 1:you can now also read the second part of this series with details on "How to" implement SafetyNet in your app prop erly, download an Android application that demonstrates the "safetynet" APIs and what the results look like for y We device and get its source. Moreover can read more on designing your application in a way then safetynet is used securely in Cigital ' s Justice Lea GUE Blog.

Update 2 (Feb 2016): This blog post was a few months old; An update would happen soon in the order of cover recent changes in SafetyNet. One of these are the verification of the Whole/system partition. What is SafetyNet

The Android Pay application got released a few days ago. Some people using rooted devices discovered that it refused to work. I have not looked into the Androidpay app. detail, but this is highly likely to being related to safetynet.

SafetyNet Attestation is Google telling the app their opinion regarding the ' CTS compatibility ' status of a device. CTS stands for Compatibility Test Suite, which is a suite of tests a device must Include Google play Services. It appears that term are now overloaded with more meanings, like ' the device was in a non-tampered '.
Tampered state has multiple definitions and can include ' being rooted ', ' being monitored ' and ' being infected with malware '.

It must be noted the ' CTS compatible ' does not mean vulnerability-free. Google does not check if a device be up to date or vulnerable to public exploits as part of the SafetyNet service-just I F it is tampered compared to a expected normal and safe state. One can argue that this is what application developers want:vulnerability status of the device would do RS but not so much to developers. The reason is this is unrealistic:if a application refused to run onvulnerable devices, very few apps would work EV En in the most recent Android devices. SafetyNet is about assuring app. developers that device are ' safe ', as oposed to ensure end users-different target Gro Up.

Google obviously didn ' t want to use a very loaded term like rooting or tamper detection, so it went with the ' neutral ' CTS Compatible ". Using SafetyNet Attestation

SafetyNet Attestation is a newish feature, at least to 3rd party application developers. Any application developer can use it in his app.

The process has a few Steps:an application Calls safetynetapi.attest (). This is provided by the Google play Services SDK. The request uses googleapiclient to reach the Google servers. The request must include a nonce. This is very important to prevent replay attacks. Best practice is for a server to generate this nonce and send it to the device to the request. Google responds with the attestation result. This is In json Web Signature (JWS)  format-a type of signed JSON object. The response includes the various signatures and the following:  "Ctsprofilematch": True|false the developer needs to Verify the fields of the response manually. The signature of the response can also be verified by Google itself using another API call, and that is the best practice. Assuming the response is verified, If ctsprofilematch is True, then the developer can be have a degree of certa Inty the device has not been tampered (.. is CTS compatible).

What is interesting was that the response can also to verified on the developer ' s server. An app can grab the "JWS attestation response and send it to" application server it normally connects to. That's server can then directly ask Google to verify the JWS signature and proceed to act on the results on the server side, For example deny APIs access to the client.

This is great design:security decisions happen on the server and not the client. Even if the client is manipulated, the server would refuse to provide services. From what I can tell, in Androidpay, the attestation be used as a parameter in pretty much every wallet & pay a Pi. Having said that, this doesn ' t mean the attestation system can ' t be fooled-a malicious the environment feed could Red data to the collectors. Moreover, it doesn ' t mean that's attestation result is always fresh. But better something than nothing.

Developers can find instructions in using this feature here:https://developer.android.com/training/safetynet/index.html

But How to does it all work? safetynet System Design

SafetyNet is a collection system used by Google to gather security-related information from 1 billion play-enabled Android Devices.

The idea is this Google play Services, a Closed-source package on the device starts a always-running service named SNet. This service frequently collects various pieces of data from the device and sends it back to Google.

Google uses this is information for multiple purposes, such as ecosystem analysis and threat profiling of devices.

It turns out this based on the collected information, Google are in a position to determine if a device. Being I n a multitude of ways. Google maintains this information and knows the at any point in the if a specific device is in a suspicious state.

Attestation is the How this information are exposed to the 3rd party developers. When an application performs a attestation request, Google sends back a signed response it includes about "CTS Compatibility", based on analysis of information previously collected from the device.

The actual checks and analysis of the collected data are done server-side, leaving less to room for manipulation; Again good security design.

Course, understanding the which pieces of data are collected could mean that someone could eventually develop a hooking System that constantly feeds snet with ' non-malicious ' information.

However, this isn't very easy:the mechanism used to update snet is very flexible, as discussed. Google does not disclose how exactly it determines ' CTS compatibility ' based on the collected data. For so much of this data it isn't very obvious what would constitute ' safe ' and what not. For example, if Google collects a list of the paths of files in the filesystem, a attacker would have to figure out W Hat to hide by trial and error. Even though he would was able to make educated guesses, he wouldn ' t know what the Google is exactly for. SafetyNet Internals

When a 3rd party application wants the attestation request, it calls com.google.android.gms.safetynet.safetynetapi;-& Gt;attest (Mgoogleapiclient, nonce), the attest method of the play Services SDK included in the app.
This library transacts and the Com.google.android.gms.safetynet.internal.ISafetyNetService service running on the Device through Binder.

The Safetynetservice is one of the Google play Services. The service handling code is packaged into the Google play Services package This ships with google-endorsed Android devices and is updated through the play Store.

However, digging a bit deeper reveals a very interesting:

The actual implementation of SNET is not inside any apks.

The SafetyNet service reaches out to a Google server and downloads a binary package with the code.
It goes to great lengths to validate the integrity of the package, for example using hardcoded certificates (pinning). This binary package is essentially a JAR file, contains a classes.dex file with Java bytecode. Play Services caches it Dalvik-cache (snet.dex) and loads it dynamically using reflection.

This is very convenient for google:the actual implementation to the collection methods can be very easily updated, even W Ithout pushing apps through Google play.

Here are two versions of the package:
Https://www.gstatic.com/android/snet/12042014-1626247.snet
Https://www.gstatic.com/android/snet/07172015-2097462.snet

These files are are not obfuscated to any way (not even using Proguard)-although Google play packages are. After talking to the "Android security Team", it appears this are done on purpose:they want a implementation tha n can be easily reviewed. My guess is this they want to make sure this people know they are not collecting sensitive/privacy related. Obfuscation could cast doubts.

As you can to the package dates, parts of this system are not new on all-safetynet exists since at least 2014 but it ' s been considerably enhanced in recent versions.

This JAR file holds the implementation of the Com.google.android.snet.Snet class. The Entersnet method is where the fun begins-this are what play Services call through reflection.

Google Downloads security-related code in the more occasions. For example, Android devices also download a native shared library named Droidguard and run it, but let ' s leave this for a Nother post. entersnet

The system is very modular:snet can being started by play Services using a configuration file that defines which collection Modules would be used. Not all of them are enabled by default.

Let ' s and what each of the modules does in detail: default_packages

This is creates a list of the preferred packages for certain actions and reports back which packages are used for Web Browsin G and package installations. It specifically checks if the preferred web browser is Com.android.browser or com.android.chrome.
I can assume this are done to detect situations where a user has authorised a non-standard browser it could be a malware -Google could maintain a list on their backend. Su_files

Reports back if the files/system/bin/su or/system/xbin/su exist. If They does, it is a clear indication of tampering.

I do hope that the attestation result is not solely based on this check-although there ' s evidence it plays a major role. On a non-infected, just rooted device, moving this files elsewhere to result in a seems positive. The same result are achieved via actions like "Disable Supersu". Maybe Google is being extra cautious. Settings

Collects various security-related fields from Android.provider.settings$secure or Android.provider.settings$global Depending on the OS version. Settings collected include the values of variables like adb_enabled, Install_non_market_apps, Iskeyguardsecure (), Getnoti Ficationvisibility (), Lock_screen_lock_after_timeout, Lockscreen.password_type, Lock_pattern_autolock.
Obviously all this are indications that something might to be ' interesting ' about the device. locale

Reports back to the current locale configuration of the device.
I assume this is the they can risk profile users according to locality and adjust their as thresholds. Ssl_redirect

This is a interesting module. It tries to establish if the device correctly follows SSL redirects. It collects information like the type of the active connection, the DNS servers in use, the available connections.

It then creates a request to the following hosts:http://accounts.google.com, http://www.google.com, Http://pubads.g.doub leclick.net-using Random user agent, even mimicking an iPhone, has ' follow redirects ' disabled. All this hosts redirect to HTTPS versions of the sites and the module collects the Location HTTP headers from the redirect Response.
It then does the same request again, this time following the redirects. After the redirects reports the IP and hostname of the final endpoint host. This second request are even done randomly using either apachehttpclient classes or httpurlconnection (!)

Some people asked for more information about the doubleclick.net domain. This is a domain used to serve advertisements to applications and the service are owned by Google. I can only assume it is also a attempt to detect if a ad-blocker is installed. Ssl_handshake

This anothere very interesting module. It attempts to figure out if communications can is intercepted in a number of ways, such as via has an ssl-kill-switch App installed.

The code attempts to contacts three hosts:accounts.google.com, www.google.com, pubads.g.doubleclick.net

For each host the following algorithm are followed and all results of every step are captured, along with any possible erro Rs. The module attempts an SSL socket connection using a ' Accept-all '  trustallx509trustmanager. The peer certificates are retrieved the code finds all trustmanagers of the system each Found trustmanager is in Itialized with no trust anchors and the checkservertrusted ()  method are executed on the retrieved certificate cha In. This would normally throw exceptions but under most SSL Kill Switch implementations it won't. The code verifies if exceptions are thrown (great check) Thedefaulthostnameverifier is used to verify the hostname of The connection Then the module manually validates the certificate chain, also checking if any certificates Thrsa algorithm and public keys shorter than 2048 bits. For each received certificate in the chain, the module checks if the issuer in the CA store of the system (exists etc/Security/cacerts) OR If it has been added by the user (/data/misc/keychain/cacerts-added) The module also includes a HARDC Oded, pinned intermediate certificate for Google and checks if it matches one of the received chain certificates Finally t He enhanced Key Usage Object Identifiers to the leaf certificate are also retrieved and compared with a hardcoded list (!)

After all this checks, all of the information as to whether the connections succeeded, what were the received certificates, If chain validation and trust checks passed, are sent back to Google. Mx_record

For all of the DNS server set up on the device, the