如何击败 Apple DeviceCheck 和 AppAttest？

Apple 的 DeviceCheck 及其继任者 App Attest（DeviceCheck 框架的一部分）依赖于安全隔离区（Secure Enclave），以加密方式证明某个应用在真实的 Apple 设备上运行。虽然它们足以应对简单的伪造攻击，但并非无懈可击。成熟的攻击者已经开发出绕过这些检查的工作流程，主要手段包括：将证明令牌与物理设备分离，或通过操纵运行时环境来伪造“合法应用”信号。 本文将详细介绍这些绕过机制，介绍所涉及的工具与服务架构，并说明 Approov 如何作为一个关键的防御层，提供跨平台的应用证明（attestation）能力。 一、攻击面：黑客如何规避 App Attest Apple 模型中的根本弱点在于：虽然硬件加密操作是安全的，但触发这些操作的软件运行环境可以被操纵。 1. 动态检测与挂钩（“Shim”攻击） 证明依赖于应用要求操作系统对一段数据进行签名。黑客使用动态检测框架来挂钩这些 API 调用。

• 攻击方式：攻击者在越狱设备上运行 App（通常会隐藏越狱状态），并使用工具拦截对 DCAppAttestService 的调用。

• 绕过原理：
  攻击者并不让 App 自己安全地处理 attestation 对象，而是通过 Hook 捕获 Secure Enclave 返回的有效签名令牌。随后，这个令牌可以被：

  • 从完全不同的环境中（例如机器人脚本）重放给后端

  • 或在签名前篡改 payload（如果 App 的完整性校验较弱）

• 常用工具： Frida、Objection、Cydia Substrate。

2. 越狱隐藏与系统调整 App Attest 在设计上会对受损设备失败或标记告警，但其检测逻辑通常依赖于系统异常特征（例如是否存在 Cydia、是否开启 SSH 等）。

• 攻击方式：攻击者使用“越狱隐藏（Jailbreak Hide）”类 Tweaks，清除文件系统和进程列表中的相关痕迹。
• 绕过原理： 设备在 DCAppAttestService 看来是“干净的”，从而可以生成一个有效的密钥对和证明对象，进而被用于授权欺诈活动。

3. “设备农场”与令牌采集 这是最具规模化、商业化的攻击方式。由于加密密钥是硬件绑定的，攻击者会实际囤积合法的 iPhone。

• 攻击方式： “设备农场”（Device Farm）将数百台 iPhone 连接到中央控制服务器。这些设备运行正版应用以生成合法的 App Attest 令牌。
• 绕过原理： 攻击者通过 API 出售对这些令牌的访问权。运行在 PC 上的机器人向设备农场发送请求；农场将挑战转发给真实的 iPhone，由安全隔离区签名，并将有效的令牌返回给机器人。后端看到的是一个完全合法的 iOS 设备请求，但流量实际上是由脚本生成的。

4. 重放攻击与中间人（MitM）攻击 如果后端对“nonce”（随机挑战）的实现存在缺陷，则令牌可能会被重复使用。

• 攻击方式：攻击者使用代理拦截有效的证明交换。
• 绕过原理： 如果后端不对证明对象强制执行严格的一次性使用或严格的时间窗口限制，攻击者就可以反复重放这次“合法”的握手，用于后续的欺诈请求。

二、服务提供商与工具环境 安全团队经常问：“谁在出售这些？”

市场大致分为两类：开源工具（研究人员 / 黑客）和 灰黑产商业服务（欺诈团伙）。

A. 工具（“如何做到”）

• Frida： 动态检测的行业标准。存在专门用于转储 App Attest 密钥或挂钩 generateAssertion 方法的脚本。
• Shadow / Liberty Lite： 常见的越狱检测绕过工具。
• SSL Kill Switch 2： 在低级网络 API 禁用证书锁定，允许攻击者检查和修改携带证明令牌的流量。

B. “服务提供商”（市场） 这些并非正规 SaaS 公司，而是灰色/黑市供应商。

1. 中国设备农场： 常见于论坛、Telegram，甚至可在某些平台看到，提供“真实设备流量”服务。他们明确宣传能够通过 iOS 完整性校验。
2. 签名即服务（SaaS）： 按量收费（如每 1000 个有效令牌），服务商维护真实 iPhone 基础设施。
3. 应用克隆器： 提供“修改版”IPA（iOS 应用包）的服务，移除安全校验，并注入代码，将用户设备生成的有效令牌上传至攻击者服务器。

三、防御策略：Approov 与 App Attest App Attest 回答的问题是 “这是一台真实的 iPhone 吗？”，而 Approov 回答的问题是 “这是我的正版应用吗，它现在是否在一个安全的环境中运行，并正在与我的后端通信？” 下表概述了为什么仅依赖 App Attest 通常是不够的，以及 Approov 如何填补这些空白。 四、实施指南：使用 Approov 进行保护 为减轻上述“设备农场”和“检测”攻击，建议将 Approov 作为主要的访问控制关口，并可将 App Attest 作为其中一个信号。 1. 跨平台一致性

无需分别维护 iOS（App Attest）和 Android（Play Integrity）的逻辑，Approov 向后端统一提供一个 JWT。

• 益处：后端逻辑简化为：if (approov_token.isValid) { allow_request }

2. 动态 RASP 与检测检测 Approov 的 SDK 持续监控应用的内存空间。

• 防御效果： 一旦检测到 Frida 等工具试图 Hook 网络栈或证明调用，Approov 会立即使令牌失效，后端实时拒绝请求—即便设备本身是真实的 iPhone。

3. 缓解设备农场攻击 Approov 会分析真实用户与机架式设备之间的行为和环境差异（例如，传感器数据、设备运行时间异常、相同的 IP 子网）。

• 防御效果：可识别并封禁来自“农场”的令牌。

4. 秘密保护 黑客经常绕过证明来窃取 API 密钥。

• 防御方式： 使用 Approov 安全秘密 (Secure Secrets)。不要将您的后端 API 密钥硬编码到 iOS 二进制文件中。相反，让 Approov SDK 仅在证明成功后动态获取 API 密钥。如果应用被修改或在农场中运行，证明会失败，应用将永远收不到进行请求所需的 API 密钥。

五、结论 Apple 的 App Attest 是一个强大的硬件锚点，但它不是一个完整的应用安全解决方案。它容易受到中继攻击和运行时操控。对于 CISO 或安全负责人来说，“纵深防御”策略需要一个层来验证软件完整性和运行时环境以及硬件。