Inside Safetynet-part 3

This are part of the A series:inside safetynet Part 1 (OCT 2015) Inside safetynet Section 2 (Feb 2016) Inside safetynet part 3 (Nov 2016) How to implement attestation securely using Server-side checks (my blog, cigital blog) safetynet Playground (POC server-side Implementation) Play Store-android source-php Source

It's been more than 8 months since I last blog post on Android ' s safetynet. In that post I am describing an end-of-2015 version of the system (version code 2495818). As expected, there have been several updates since; I thought I should write one more post in this series, probably the last. I ' ll briefly describe the differences of that reviewed version versus version 10000700; This is Second-to-last version. The latest version I ' ve seen is 10000801, but it doesn ' t have many.

For a, complete overview of the client-side checks inside the safetynet system and its usage please read through my PR Evious posts. SNET version Codes

I thought I ' d just list some of the SNET versions I ' ve observed in the wild; I ' m sure there are many more. 1626247 (December 2014) 1839652 (April 2015) 2097462 (July 2015) 2296032 (September 2015) 2495818 (December 2015) 10000700 (August 2016) 10000801 (September 2016) design changes

SafetyNet got partially integrated into the Chimera system as a dynamite module. Chimera is a sort-of package management system for Google Play Services components, allowing Google to flexibly and Indepe ndently upgrade each one. As Chimera manages part of the download and provisioning process, this change made the SNet package and more lighter ble. Chimera also has a nice interface, found through going into Google Settings and enabling "Debug items". You ' ll be an ' [internal] ' menu item called "Chimera Modules". The SafetyNet module is called Com.google.android.gms.flags, currently version 1. You'll also find this droidguard is another dynamite module.

basicintegrity

At least since last July, Attestation responses objects contain a new Boolean flag called basicintegrity.this new field do Es not appear in Google ' s published documentation yet. I ' m sure it'll soon.

{"
    nonce": "r2rra24fvm5xa2mg",
    "Timestampms": 9860437986543,
    "Apkpackagename": " Com.package.name.of.requesting.app ",
    " apkCertificateDigestSha256 ": [" base64 encoded, SHA-256 hash of the Certificate used to sign requesting app ","
    apkDigestSha256 ":" Base64 encoded, SHA-256 hash of the app ' s APK ",
    " ct Sprofilematch ': True,
    ' basicintegrity ': true,
}

But What is this field? Here are some thoughts, the way I understand it:

In September 2016, Google decided to introduce more aggressive checks into ctsprofilematch, e.g. acting on Verifiedboot St ATUs. Due to this changes, devices that are not "rooted" but could only use a different bootloader would cause Ctsprofilematch to is set to false.

In such cases, Basicintegrity would still remain true. It seems It is set to False only if a su binary is placed in expected locations. The Basicintegrity field currently seems to behave like Ctsprofilematch did before the recent. One could the it as a way to maintain the previous Ctsprofilematch behavior and so this 3rd party apps can choose the level O F checks they want to base their decisions on. I have yet to-to-I case where basicintegrity is true while Ctsprofilematch is false; Let me know in the comments if your do.

I also updated cigital ' s SafetyNet Playground app Google play. It now checks and reports the value of basicintegrity. Check it out!

Droidguard

It's safe to say this droidguard plays a bigger role into attestation than I have previously. It is (and has always been) a packed native library, designed to somewhat withstand reverse engineering, which makes Ng with it more interesting. Another blogpost on this may come in the future. Safe Browsing

Safetynet-from a 3rd party app perspective, used to initially is only about attestation and CTS compatibility.

It now offers another flavor:a Lookupuri () API This allows apps to check if A given URI is classified as potentially Harm Ful App by Google ' s threat intelligence systems. More details is here and here.

I ' ve not described Safe browsing into any my blog posts yet, this may come in the future-just like Verify & Dr Oidguard. minification

As of version 10000801 SafetyNet is making the Proguard-style minification (some call it obfuscation). This is a interesting change of heart. Initially Google seemed to leave things unobfuscated on purpose in order to increase transparency, however this appears to Have changed.

It is important to the "happened" at the same time as the cat-and-mouse game between SafetyNet and various "Bypasses" intensified after the recent device integrity change. I am sure that safetynet re-implementations as this might have affected this decision. safetynet Module Changes

A Few but important new modules have been in added recent and versions some. older As mentioned above, SafetyNet is configured by Google on runtime or via play services updates; The SNet module itself updated independently less often.

What follows is the list of snet modules this are currently enabled by default. Note that a few extra modules have been-enabled compared to a year ago. But the real differences are of course not here; The real differences are of the way data from each module affects backend attestation. Idle mode Modules

Idle mode checks appear to run every hours. The last time a idle mode scan run is stored in SNet's shared preferences inside the play Services app private files. The following modules are now always enabled by default in idle mode. Gmscore system_partition_files system_ca_cert_store setuid_files dalvik_cache_monitor device_state locale selinux_ Status Logcat Event_log

The Gmscore, locale and selinux_status modules have now been in turned to a year ago. The Gmscore module retrieves info about the COM.GOOGLE.ANDROID.GMS package installed on the device via Packagemanager APIs , including Versioncode, hashes, signatures etc. The locale module obviously retrieves the current locale, including country code. The Selinux_status modules is described in a moment. Normal mode Modules

The following modules are now always enabled by default in normal mode. Normal mode ' checks ' appear to run when a 3rd party app requests a attestation or at a maximum every. Default_packages su_files settings Locale ssl_redirect ssl_handshake proxy selinux_status sd_card_test google_page_info Captive_portal_test attest Gmscore device_state carrier_info logcat

The following Non-default modules are also currently enabled by play Services Config:mx_record Sslv3_fallback

Compared to a year ago, the "Only differences appear" is that the following two modules are now turned on:device_state a nd carrier_info. The Device_state module is of course very important and are directly related to the recent boot verified. It ' s described in the more detail below. SU Files Module

The SU finding modules has been partially redesigned since it was the. It reports back information about two sets of Files:files explicitly by Google Su requested

The category of files comes from snet configuration options, shipped separately from SNet itself as part of Google p Lay services. It currently includes a single file:/proc/sunxi_debug/sunxi_debug. This file is a-known kernel backdoor allowing easy root on some devices.

The second category has been split out into a new rooting file finder submodule. This works as follows:

SNET assembles a combined list of two types of directories to search into:

Interesting Directories:these by default Include/system/bin and/system/xbin and all directories specified in PATH, if Su CH environment variable exists.

Systemless Root directories:snet attempts to identify directories that might is bind-mounted by Parsing/proc/self/mounti NFO and figuring out If/bin Or/xbin are using mounted. I won't go over the details of how systemless root works in this post.

SNET attempts to find if the SU binary exists into any of these directories. If it does, it gathers information about it, including its SHA256 hash, if it's a symlink and its target, Ownership/permis Sions/selinux info (lstat) etc. It now also checks if the file is Executable-this are done via java.libcore.io.Os.access (file, X_OK). Settings Module

This module is used to retrieve various pieces of information about system settings and are run as part of the ' Normal-mode ' Checks. It has changed to also retrieve two more pieces of info:

Storage Encryption Status

This is retrieved via the Getstorageencryptionstatus () of the Device_policy system service if SDK >= 11.

Fingerprint Status

This is retrieved via the ishardwaredetected () and Hasenrolledfingerprints () methods of the fingerprint system service if SDK >= 23. This can return the following values:fingerprint_enrolled = 1 fingerprint_not_supported = 0 fingerprint_unenrolled = 2 device State Module

This module is used to gather the following data:verified Boot state via Ro.boot.verifiedbootstate Verity mode via RO.BOOT.V Eritymode security Patch level via Ro.build.version.security_patch Unlock Support via ro.oem_unlock_supported State of Fla SH Lock (oemlocked): Via ro.boot.flash.locked

Now the following have been Added:device Brand via Ro.product.brand Device Model via Ro.product.model Kernel Version /proc/version List of System properties explicitly specified by Google via play services. Currently just Ro.build.characteristics

On api>23, Flash lock ' Now ' retrieved via Persistentdatablockmanager.getflashlockstate () which is a new wrapper API to the Ro.boot.flash.locked property.

Possible Values are:flash_lock_state_locked = 1 (0x1) Flash_lock_state_unknown =-1 (0xFFFFFFFF) Flash_lock_state_unlock ED = 0 (0x0)

Some people were surprised back into September this year, when Google started blocking the devices that were not rooted but H Ad unlocked their bootloader. Unlocked bootloaders cause verified boot to fail-that what ' s triggering ' snet. Not much changed in Client-side Code:safetynet is retrieving ro.boot.verifiedbootstate and Ro.boot.veritymode all along, Gathering metrics, until someone made the decision to make this indicators influence the Ctsprofilematch Boolean flag (b UT not basicintegrity). dm-verity Correction Info checks

For Idle-mode checks, the Device state communicated back to Google now also includes dm-verity correction information for SDK > 23.Some of Know tha Android N introduced verified Boot with Error correction. This is all described. Forward Error Correction is of the course used to recover from filesystem corruption. An interesting security "Side-effect" was that the definition of ' curruption ' extends to ' tampering ', so this feature can E ffectively repair rooted filesystems)

SafetyNet searches All device mapper directories (e.g./sys/block/dm-0,/sys/block/dm-1) and looks for a directory named F EC, signalling that's a partition is using Forward Error correction. If FEC is found, SNET retrieves the partition name (/sys/block/dm-x/dm/name) and the FEC record file (/sys/block/dm-x/fec/ Corrected) and sends these are back, allowing the Google to track how this new feature is used. System Partition Files module

In the I previous blogpost I briefly described this system performs integrity measurements, retrieving hash trees over the/s Ystem directory and reporting them back, along with other info, to a System Integrity service separate from SNET.

A year ago The SIC Server URL is empty but this has now been filled in. It Is:https://sb-ssl.google.com/safebrowsing/clientreport/system-integritythis appears to be a undocumented part of The Safe browsing system. SELinux Checking Module

Previously this module only retrieved:whether the SELinux is supported if it's in enforcing mode Via/sys/fs/selinux/enforce.

Now, it also retrieves:the version via/selinux_version the SHA256 hash of the policy file (/sepolicy) SSL handshake Module

As discussed before, this module attempts to figure out if communications can is intercepted in a number of ways, such as Via has an Ssl-kill-switch app installed. It basically attempts to find malicious trustmanagers. In the last few versions it has been significantly refactored.

Like before, the code attempts to contact accounts.google.com and www.google.com. The third host is play.google.com, replacing Pubads.g.doubleclick.net.

For each host, the module attempts to does an SSL handshake (sslcontext.getsocketfactory (). Createsocket (hostname, 443)) and Now, separately, a HTTPS connection (new URL ("HTTPS", hostname, ""). OpenConnection ()) Both use a custom all-trusting x509t Rustmanager to establish a secure connection and retrieve the server ' s SSL certificates. Then the module finds the system ' s X509trustmanager (instead of all of them like it did before).

It then uses this TrustManager (via checkservertrusted () to verify the server ' s chain. It is interesting to "now", on Api>=21, the module uses x509trustmanagerextensions.checkservertrusted () instead of Checkservertrusted (), in order to retrieve the validated certificate chain. This is good news; Bad things happen the differ, as seen in cve-2016-2402. In a change since previous versions, even on api<21 there ' s code to re-create the validate certificate St Uff. As discussed before the This module also checks if certificates are valid because they have been added by a user or not; These are methods now, for APIs >=21 use X509trustmanagerextensions.isuseraddedcertificate () instead of manually checking/d Ata/misc/keychain/cacerts-added. SDcard Analyzer Module

This module is now also retrieves the "last modification" of JPEG file it attempts to store on the SD card. Carrier Info Module

One new module is introduced into SafetyNet: "Carrier Info" This just retrieves the Name of the ' current Carrier by usin G The Getnetworkoperatorname () method of the phone system service.
Original address: https://koz.io/inside-safetynet-3/