Safetynet:google ' s tamper detection-part 2

It's been six months since my last blog post on Android ' s safetynet. I was then examining a Mid-july 2015 version of the system. As expected, there have been updates since; The last was released Mid-december 2015. I ' ll briefly describe the differences in this post; For a more complete overview of the checks inside the safetynet system and it usage please read through I previous posts . safetynet Changes

A Few but important new modules have been in added recent and versions some. older Dalvik Cache Module

This module is attempts to find modified Dalvik cache files. As is known, Dex code inside a APK gets optimised during installation and are kept in a separate folder in "Odex" files [o n old Android versions which still use Dalvik]. Malicious actors could modify these optimized files directly instead of modifying APKs.
The module Monitors/data/dalvik-cache/arm Or/data/dalvik-cache and maintains the results, comparing the hashes of odexed Files with their stored versions. LOG DEVICE State module

This module retrieves a few system properties from Android.os.SystemProperties and sends them BACK:RO.BOOT.VERIFIEDBOOTST Ate ro.boot.veritymode ro.build.version.security_patch ro.oem_unlock_supported ro.boot.flash.locked LOG SYSTEM PARTITION FILES Module

This module has been previously discussed. A New Submodule has been now been added, named Systemintegritychecker (SIC). This is attempts to remotely verify the state of The/system partition; An interesting concept from many aspects.

SIC retrieves the SHA256 hash oof the/system entry from SafetyNet ' s data store. It then performs a HTTPS request to a SIC server containing the hash and some meta-information about the directory. The response would contain a hashmatches integer flag. SafetyNet'll use this flag and the through appropriate safetynet APIs.

The

As far as I can tell the SIC system isn't yet in use. I am not sure why a request to a separate SIC server needs to happen; The only reasonable explanation seems is that entities other than Google might need to maintain their own SIC servers, e.g. device manufacturers. Still, the whole process could possibly happen through backend APIs instead. 
in no case, someone are going to ha ve to maintain a list of hashes of the system partitions of various devices/configurations or the ' last seen hash ' for EAC h user, so that changes are detected. ,
We ll know soon enough I guess. How are The /system hash created?

SafetyNet runs a process that recursively walks "/system" and calculates a hashtree over its contents.
For every file it encounters it captures meta-information (timestamps, permissions, SELinux, etc.) and its SHA256 ha SH into a local data store. For every directory, it generates a hash that considers the store entry of every file inside the directory. If There are hash mismatches between previous and current recursive walks, the Over/system files offending are Separate lists to be audited.

The LOG SYSTEM PARTITION FILES module continues to include the results of the Systempartitionfilefinder sub-module.
As a reminder, this module retrieves the status of various files In/system. The list of "files of interest" is configured over the air. Currently, the following files are checked, along with 5 random files:

      /system/app/providerdown.apk,/system/priv-app/cameraupdate.apk,/system/app/cameraupdate.apk, S ystem/priv-app/thememanags.apk,/system/app/htmlviewer.apk,/system/app/com.android.hardware.ext0.apk,/ system/app/com.android.wp.net.log.apk,/system/app/com.google.fk.json.slo.apk,/SYSTEM/APP/COM.GOOGLE.MODEL.MI . apk,/system/app/settingprovider.apk,/system/app/securitycertificate.apk,/system/app/livewallpaper.ap K,/system/app/batterycontrol.apk,/system/app/models.apk,/system/bin/.daemon,/system/bin/.daemo
      N/mis,/system/bin/.daemon/nis,/system/bin/daemonnis,/system/bin/nis,/system/bin/.sr/nis,
      /SYSTEM/BIN/.SR,/system/bin/.memnut,/SYSTEM/BIN/.SUV,/system/bin/.sc/mis,/system/bin/uis, /SYSTEM/USR/.SUV,/system/xbin/.memnut,/SYSTEM/XBIN/.SUV,/system/xbin/ku.sud,/SYSTEM/XBIN/.R T_daemon,/system/Xbin/.rt_bridge,/system/xbin/.monkey.base,/system/xbin/.ext.base,/system/xbin/.like.base,/syst Em/xbin/.look.base,/system/xbin/.must.base,/system/xbin/.team.base,/system/xbin/.type.base,/sy Stem/xbin/.view.base,/system/xbin/.word.base,/system/xbin/.zip.base,/system/xbin/.bat.base,/sy Stem/xbin/com.android.wp.net.log,/system/xbin/.b,/SYSTEM/XBIN/.DF,/SYSTEM/XBIN/.C,/system/xbin
 /.sys.apk,/system/xbin/.ld.js,/system/xbin/.ls

safetynet Modules

This is a up-to-date list of all safetynet logging modules. My previous blog post describes most.

Log_apps_tag = "APPS";  
Log_attestation_tag = "attest";  
Log_captive_portal_test_tag = "Captive_portal_test";  
Log_dalvik_cache_tag = "Dalvik_cache_monitor";  
Log_device_admin_tag = "Device_admin_deactivator";  
Log_device_state_tag = "Device_state";  
Log_event_log_tag = "Event_log";  
Log_files_tag = "Su_files";  
Log_gmscore_info_tag = "Gmscore";  
Log_google_page_info_tag = "Google_page_info";  
Log_google_page_tag = "Google_page";  
Log_handshake_tag = "Ssl_handshake";  
Log_locale_tag = "LOCALE";  
Log_logcat_tag = "Logcat";  
Log_mx_records_tag = "Mx_record";  
Log_packages_tag = "Default_packages";  
Log_proxy_tag = "PROXY";  
Log_redirect_tag = "Ssl_redirect";  
Log_sd_card_tag = "Sd_card_test";  
Log_selinux_tag = "Selinux_status";  
Log_settings_tag = "SETTINGS";  
Log_setuid_tag = "Setuid_files";  
Log_sslv3_tag = "Sslv3_fallback";  
Log_suspicious_page_tag = "Suspicious_google_page";  
Log_system_ca_cert_store_tag = "System_ca_cert_store"; Log_system_partition_files_TAG = "System_partition_files";  
 

Extras

SafetyNet is isn't just about the modules described here. During The attestation process some other checks happen via different systems; For example there are code that acts as old-fashioned root-detection, trying to figure out if the following ES exist in the filesystem (or if traces of them appear in device).

I do hope this output of the rest of the SafetyNet modules is also taken to account during the calculation the Ctsco Mpatibility Response.

"/system/bin/su" "
/system/xbin/su"
"/system/bin/.su" "
/system/xbin/.su" "
/system/xbin
" " System/bin "
/system/sd/xbin"
"/system/bin/failsafe" "
/data/local" "
/system" "
/system/bin" /.ext "
"/data/local/xbin ""
/data/local/bin "

Over-the-air Configuration

As mentioned above, SafetyNet is configured by Google at runtime; Even though the code itself is also updated once every three months on average.

The following are some of the more interesting configuration options: Signal Tags whitelist-idle Mode

This configures which modules are used by the SafetyNet "idle mode" logger.

  N: "Snet_idle_tags_whitelist"
  V: "System_partition_files,
      System_ca_cert_store,
      setuid_files,
      Dalvik_cache_monitor,
      Logcat,
      event_log,
      device_state "

Signal Tags whitelist-normal Mode

This configures which modules are used by the SafetyNet "Normal mode" logger.

  N: "Snet_tags_whitelist"
  V: "Default_packages, 
      su_files,
      settings,
      locale,
      ssl_redirect,
      Ssl_handshake,
      sslv3_fallback,
      Proxy,
      selinux_status,
      sd_card_test,
      Google_page_ info,
      captive_portal_test,
      gmscore,
      logcat,
      event_log "

Event Log Tags

This is used by the Event Logger module. The SafetyNet service is configured to retrieve and log the following event tags:

  N: "Snet_report_event_logs"
  V: "50125:2,
      50128:2,
      conscrypt:3,
      78001:2,
      65537:2,
      90201:2,
      90202:2,
      70,151:2 "

The tags correspond to/system/etc/event-log-tags:50125:2 SMS denied by user Exp_det_sms_denied_by_user (app_signature|3 ) 50128:2 SMS denied by user Exp_det_sms_sent_by_user (app_signature|3) conscrypt:3 Unexpected (early) Changecipherspec me Ssage 78001:2 frameworklistener dispatchcommand overflow exp_det_dispatchcommand_overflow 65537:2 FrameworkListener Dispatchcommand overflow exp_det_netlink_failure (uid|1) 90201:2 log whether user accepted and activated device admin EXP_ Det_device_admin_activated_by_user (app_signature|3) 90202:2 Log whether user declined activation of device admin Exp_det _device_admin_declined_by_user (app_signature|3) 70151:2 Exp_det_attempt_to_call_object_getclass (app_signature|3) SIC Server URL

  N: "Snet_sic_server_url"
  V: ""

This is currently empty, but would eventually be the server URL for the ' System Integrity Checker ' service described above. Droidguard

These posts are aimed primarily at providing some clarity on the safetynet system to developers who wish to adopt ation APIs in their applications. It must be noted this attestation is just a small aspect of the safetynet system; The main use was to retrieve data so, Google can monitor the security of the Android ecosystem and track on-going incid Ents.

As I ' ve hinted in me previous post, while performing this investigation I stumbled upon Droidguard, a set of components th At communicates with remote Google play APIs and are used for fraud detection, anti-abuse and operations like DRM.

SafetyNet interacts, along with many other components, with Droidguard. Although these two systems could co-operate for some checks, Droidguard is a independent system that serves different SES, more inline with Google ' s anti-malware efforts. I Will not be revealing details about this system; As I such details would only benefit malware authors, not application developers this want to keep their D Apps protected. Similarly, revealing details on ' How to bypass SafetyNet ' isn't the goal here. Such details are shared directly with Google and enterprise developers interested in assessing the system before using it. improving SafetyNet

Here's a bucket list of things I ' d like to the safetynet and some thoughts. SafetyNet is isn't a root detection system although it goes a long way towards that goal. It suffers from some early symptoms of the more traditional on-device checking systems:it ' s designed for large scale data gat Hering and does not adequately protect itself against targeted attacks. It'll tell Google this x percent of devices are tampered, but, for now, it'll stop short of trying to actively resist Ng by malware This specifically wants to present a false image to the checkers. Of course this is a ultimately futile effort, but the bar can be raised. I ' d like to least some degree's code protection for the checkers. It ' d be great if checks were performed using a range of high-level and low-level APIs. I ' d also be good if more safetynet checkers influence the compatibility decision; More than the straightforward SU binary tests. How much of the compatibility decision is influenced by historical Data about a device is an open question. Moving away from Point-in-time checks could to be a worthwhile goal. Some clarity around the SIC server system would is nice to have. Making use of Trustzone multi-platform support for the attestation APIs would is interesting to (IOS attestation ...)
Original address: https://koz.io/inside-safetynet-2/