【译】 SafetyNet: Google's tamper detection - Part 2

最新推荐文章于 2022-08-15 16:42:14 发布

Omni-Space

最新推荐文章于 2022-08-15 16:42:14 发布

阅读量2k

点赞数

原文链接：https://koz.io/inside-safetynet-2/

版权

Android Security 同时被 2 个专栏收录

209 篇文章 17 订阅

订阅专栏

Google Safetynet

7 篇文章 0 订阅

订阅专栏

自从我上一篇关于Android的SafetyNet的博客发布以来已经过去了六个月。然后，我正在研究该系统的2015年7月中旬版本。正如预期的那样，此后已有更新。最后一篇发表于2015年12月中。我将简要介绍这篇文章中的区别；有关SafetyNet系统内部检查及其用法的更完整概述，请通读我以前的文章。

SafetyNet更改

在最新版本中添加了一些但重要的新模块，并对一些较旧的模块进行了重组。

Dalvik缓存模块

该模块尝试查找已修改的 dalvik缓存文件。众所周知，APK中的dex代码在安装过程中会得到优化，并保存在“ odex”文件中的单独文件夹中（在仍使用Dalvik的旧Android版本上）。恶意行为者可以直接修改这些优化文件，而不是修改APK，以逃避检测。该模块监视/data/dalvik-cache/arm或/data/dalvik-cache维护结果，将经过解密的文件的哈希值与其存储版本进行比较。

日志设备状态模块

此模块从中检索一些系统属性android.os.SystemProperties并将其发送回：

ro.boot.verifiedbootstate
ro.boot.veritymode
ro.build.version.security_patch
ro.oem_unlock_supported
ro.boot.flash.locked

日志系统分区文件模块

之前已经讨论过该模块。现在已添加了一个名为SystemIntegrityChecker （SIC）的新子模块。这将尝试远程验证/system分区的状态。一个有趣的概念，来自多个方面。

SIC /system从SafetyNet的数据存储中检索条目的SHA256哈希。然后，它向SIC服务器执行HTTPS请求，其中包含哈希值和有关目录的一些元信息。响应将包含一个hashMatches整数标志。SafetyNet将使用此标志并通过适当的SafetyNet API进行报告。

据我所知SIC系统尚未使用。我不确定为什么需要对单独的SIC服务器进行请求；唯一合理的解释似乎是，除Google以外的其他实体可能需要维护自己的SIC服务器，例如设备制造商。尽管如此，整个过程还是有可能通过后端API进行。在任何情况下，某人都必须维护各种设备/配置的系统分区的哈希列表或每个用户的“最后看到的哈希”，以便能够检测到更改。我猜我们很快就会知道。

/system哈希是如何创建的？

SafetyNet运行一个递归遍历“ / system”的过程，并根据其内容计算HashTree。对于遇到的每个文件，它将捕获元信息（时间戳，权限，selinux上下文等）并将其SHA256哈希存储到本地数据存储中。对于每个目录，它都会生成一个哈希，该哈希将考虑目录中每个文件的存储条目。如果先前的递归遍历与当前的递归遍历之间存在哈希不匹配/system，则将有问题的文件输入单独的列表中以进行审核。

LOG SYSTEM PARTITION FILES模块继续包含SystemPartitionFileFinder子模块的结果。提醒一下，此模块检索中的各种文件的状态/system。“感兴趣的文件”列表是通过无线方式配置的。当前，将检查以下文件以及5个随机文件：

      /system/app/providerdown.apk,
      /system/priv-app/cameraupdate.apk,
      /system/app/cameraupdate.apk,
      /system/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.apk,
      /system/app/BatteryControl.apk,
      /system/app/Models.apk,
      /system/bin/.daemon,
      /system/bin/.daemon/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/.rt_daemon,
      /system/xbin/.rt_bridge,
      /system/xbin/.monkey.base,
      /system/xbin/.ext.base,
      /system/xbin/.like.base,
      /system/xbin/.look.base,
      /system/xbin/.must.base,
      /system/xbin/.team.base,
      /system/xbin/.type.base,
      /system/xbin/.view.base,
      /system/xbin/.word.base,
      /system/xbin/.zip.base,
      /system/xbin/.bat.base,
      /system/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模块

这是所有SafetyNet日志记录模块的最新列表。我以前的博客文章描述了其中的大多数。

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";

附加功能

SafetyNet不仅涉及此处描述的模块。在认证过程中，其他一些检查是通过不同的系统进行的；例如，有一些代码充当老式的根检测程序，试图找出文件系统中是否存在以下文件/目录（或者它们的踪迹是否出现在设备日志中）。

我确实希望在计算ctsCompatibility响应时也要考虑其余SafetyNet模块的输出。

"/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"

空中配置

如上所述，SafetyNet是由Google在运行时配置的；即使代码本身也平均每三个月更新一次。

以下是一些更有趣的配置选项：

信号标签白名单-空闲模式

这可以配置SafetyNet“空闲模式”记录器使用的模块。

  n: "snet_idle_tags_whitelist"
  v: "system_partition_files,
      system_ca_cert_store,
      setuid_files,
      dalvik_cache_monitor,
      logcat,
      event_log,
      device_state"

信号标签白名单-正常模式

这将配置SafetyNet“正常模式”记录器使用的模块。

  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 Logger模块使用。SafetyNet服务配置为检索和记录以下事件标签：

  n: "snet_report_event_logs"
  v: "50125:2,
      50128:2,
      conscrypt:3,
      78001:2,
      65537:2,
      90201:2,
      90202:2,
      70151:2"

标签对应于/system/etc/event-log-tags：

50125：2
- 短信被用户拒绝
- exp_det_sms_denied_by_user (app_signature|3)
50128：2
- 短信被用户拒绝
- exp_det_sms_sent_by_user (app_signature|3)
conscrypt：3
- 意外的（早期）ChangeCipherSpec消息
78001：2
- FrameworkListener dispatchCommand溢出
- exp_det_dispatchCommand_overflow
65537：2
- FrameworkListener dispatchCommand溢出
- exp_det_netlink_failure (uid|1)
90201：2
- 记录用户是否接受并激活了设备管理员
- exp_det_device_admin_activated_by_user (app_signature|3)
90202：2
- 记录用户是否拒绝激活设备管理员
- exp_det_device_admin_declined_by_user (app_signature|3)
70151：2
- exp_det_attempt_to_call_object_getclass (app_signature|3)

SIC服务器网址

  n: "snet_sic_server_url"
  v: ""

当前为空，但最终将是上述“系统完整性检查器”服务的服务器URL。

DroidGuard

这些文章的主要目的是为希望在其应用程序中采用证明API的开发人员提供有关SafetyNet系统的一些信息。必须注意的是，证明只是SafetyNet系统的一小部分。主要用途是检索数据，以便Google可以监视Android生态系统的安全性并跟踪正在进行的事件。

正如我在上DroidGuard一篇文章中所暗示的那样，在执行此调查时，我偶然发现了一组与远程Google Play API进行通信的组件，这些组件用于欺诈检测，反滥用和DRM之类的操作。

SafetyNet与DroidGuard以及许多其他组件进行交互。尽管这两个系统可以配合使用以进行某些检查，但DroidGuard是一个独立的系统，可以实现不同的目的，与Google的反恶意软件工作更加契合。我不会透露有关该系统的详细信息；因为我认为这样的细节只会使恶意软件作者受益，而对希望保护其Android应用程序的应用程序开发人员没有好处。同样，披露“如何绕过SafetyNet”的细节也不是这里的目标。此类详细信息将直接与Google和有兴趣在使用该系统之前对其进行评估的企业开发人员共享。

改善SafetyNet

这是我想在SafetyNet中看到的一些事情和一些想法的清单。

SafetyNet并非rooting检测系统，尽管它在实现该目标方面还有很长的路要走。它具有更传统的设备上检查系统的一些早期症状：它是为大规模数据收集而设计的，不能充分保护自己免受目标攻击。它将告诉Google X％的设备已被篡改，但是目前，它将停止尝试主动抵制恶意软件的篡改，这些恶意软件特别想向检查人员提供虚假图像。当然，这最终是徒劳的，但是可以提高标准。
我希望至少对检查程序进行某种程度的代码保护。
如果使用一系列高级和低级API执行检查，那就太好了。
如果更多的SafetyNet检查器影响兼容性决定，我也很好。不仅仅是简单的su二进制测试。
一个设备的历史数据会影响多少兼容性决定是一个悬而未决的问题。摆脱时间点检查可能是一个值得的目标。
围绕SIC服务器系统的一些清晰度将很高兴。
利用信任区
有趣的是，对证明API的多平台支持（iOS证明...）

原文地址： https://koz.io/inside-safetynet-2/

Omni-Space

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
【译】 SafetyNet: Google's tamper detection - Part 2

自从我上一篇关于Android的SafetyNet的博客发布以来已经过去了六个月。然后，我正在研究该系统的2015年7月中旬版本。正如预期的那样，此后已有更新。最后一篇发表于2015年12月中。我将简要介绍这篇文章中的区别；有关SafetyNet系统内部检查及其用法的更完整概述，请通读我以前的文章。SafetyNet更改在最新版本中添加了一些但重要的新模块，并对一些较旧的模块进行了重组。...
复制链接

扫一扫