小米TEE可信执行环境安全漏洞（2022）_soterservice

介绍

您是否想过通过移动设备付款是否安全？恶意应用程序会从您的数字钱包中窃取资金吗？

根据最新统计数据，2021年远东和中国占全球移动支付的三分之二。这大约是40亿美元的移动钱包交易。如此巨额的金额无疑引起了黑客的关注。

我们研究了搭载联发科芯片的小米智能手机内置的支付系统，这种芯片在中国非常受欢迎。结果，我们发现了一些漏洞，这些漏洞可允许伪造支付包或直接从非特权 Android 应用程序禁用支付系统。

多年来，可信执行环境 (TEE) 一直是移动设备不可或缺的一部分。其主要目的是处理和存储敏感的安全信息，例如加密密钥和指纹。TEE 保护基于硬件扩展（例如 ARM TrustZone），即使在已 root 的设备或受恶意软件攻击的设备上也能保证 TEE 世界的安全。

回到我们关于移动支付的问题，移动支付签名是在 TEE 中进行的。所以只要 TEE 是安全的，你的支付也是安全的。

虽然安全管理和移动支付的核心都是由小米等设备供应商（而非芯片制造商）编写的可信代码，但这些代码并未得到彻底研究。我们的研究标志着小米的可信应用程序首次接受安全问题审查。

小米的 TEE

在网上，你可以很容易地找到很多关于 TEE 架构的文章。因此，我们在这里就不详细展开了。我们只记下关键的几点：

• TEE 创建了一个由运行可信应用程序的可信操作系统管理的虚拟安全世界。
• 受信任的应用程序实现了特定的安全功能。
• 正常世界的操作系统（Android）可以向可信应用程序发送命令并接收响应。

基于高通芯片的小米设备使用 QSEE 可信操作系统。基于联发科的设备使用 Beanpod TEE 或 Mitee。在这两种情况下，小米都可以嵌入并签名自己的可信应用程序。在我们的研究中，我们专注于联发科驱动的设备的可信应用程序。测试设备是搭载 MIUI Global  12.5.6.0 操作系统的小米 Redmi Note 9T 5G。此设备使用 Beanpod TEE。

受信任应用程序的文件格式

在小米设备上，受信任的应用都存储在该/vendor/thh/ta目录中，每个应用都以未加密的二进制文件表示，例如thhadmin负责安全管理的应用就由该文件表示0102030405060708090a0b0c0d0e0f10.ta。

在图 1 中，你可以看到小米可信应用程序的文件格式。实际上，我们甚至不需要了解所有格式字段就可以研究应用程序的代码，因为小米应用程序二进制文件的初始部分是 ELF 文件。

图 1：可信应用程序格式。

受信任的应用可以在魔法字段后有多个签名。设备上所有受信任的应用的魔法字段都相同。此外，它们与我们检查过的所有其他设备（例如小米 T11 和小米 Note 8 Pro）的应用字段相同。

受信任的应用程序可能会被降级

可以看到，受信任应用的文件格式中省略了版本控制字段。这意味着攻击者可以将受信任应用的旧版本传输到设备，并使用它来覆盖新的应用文件。由于旧应用的签名正确，因此该应用将被 TEE 成功加载。

因此，攻击者可以通过将受信任的应用程序降级为未修补的版本来绕过小米或联发科对受信任应用程序进行的安全修复。

为了证明该问题，我们成功地用thhadmin从另一台运行 MIUI Global 10.4.1.0 操作系统的设备中提取的旧应用程序覆盖了运行 MIUI Global 12.5.6.0 操作系统的测试设备上的受信任应用程序。thhadmin尽管旧应用程序的代码与原始应用程序有很大不同，但它仍成功启动。

从 Android 调用受信任的应用程序

小米遵循GlobalPlatform TEE客户端API规范，该规范定义了客户端和TEE之间的通信API。

该 API 在库中实现/vendor/lib/libTEECommon.so。主要功能包括：

• TEEC_OpenSession，这将在客户端应用程序和指定的受信任应用程序之间打开一个新会话。目标受信任应用程序由与应用程序文件名匹配的 UUID 标识。
• TEEC_InvokeCommand，它在指定的会话中调用命令。命令 ID 和最多 4 个命令参数可以传递给受信任的应用程序进行处理。

例如，我们使用以下函数thhadmin从 Android 调用受信任的应用程序：

应用thhadmin程序需要接收一个输入缓冲区和一个输出缓冲区作为参数。命令 ID 将被忽略。

非特权 Android 应用程序无权与小米的受信任应用程序通信。SELinux 仅允许teei_client_device少数特权用户（例如mediacodec、drm等）访问该对象。

我们最近在 ALAC 媒体解码器中发现了几个漏洞，这些漏洞允许非特权 Android 应用程序在用户未知情的情况下在搭载联发科或高通芯片的智能手机上执行任意代码mediacodec。非特权用户可以利用此类漏洞调用小米的受信任应用程序。

寻找受信任应用程序中的漏洞

小米在实现可信应用时遵循 GlobalPlatform TEE内部核心 API规范，每个应用都会导出“TA 接口”函数，这些函数是创建应用实例、通知实例有新客户端连接、客户端调用命令时通知实例等入口点。

该TA_InvokeCommandEntryPoint函数是模糊测试漏洞研究的完美目标。它处理从 Android 端发送的命令 ID 和缓冲区。

构建一个调用该函数的工具相对容易。需要修补导入表以将内存管理调用重定向到其等效项。应取消libc诸如此类的验证函数。TEE_CheckMemoryAccessRights

我们使用了 AFL 和 QEMU 的经典组合来模糊小米实现的可信应用程序（或者更准确地说，由 MicroTrust 实现并由小米集成）。

我们在受信任的应用程序中发现了几个漏洞thhadmin，这些漏洞可被利用来泄露存储的密钥或在应用程序上下文中执行代码。例如，图 2 中的输入缓冲区导致堆溢出，允许攻击者使用来自 0x42424242 地址的数据覆盖 0x41414141 字节的堆内存。

图 2：格式错误的输入缓冲区。

腾讯

小米设备内置了一个名为腾讯支付的移动支付框架，该框架为第三方安卓应用提供了集成支付功能的API。腾讯支付是腾讯控股有限公司旗下的一个软件平台，主要功能是提供在移动应用和远程后端服务器之间传输的支付包的验证功能。据腾讯称，数亿台安卓设备支持腾讯支付。

微信支付和支付宝是中国数字支付行业最大的两家公司。它们合计占据了中国移动支付市场的 95% 左右。这两个平台的用户都超过10 亿。微信支付基于腾讯支付。

微信提供开放的 SDK，第三方 Android 应用可以集成该 SDK，以微信应用 ( com.tencent.mm) 作为代理进行支付。任何应用都可以请求微信进行支付交易。微信应用随后负责所有必要的验证和包签名，并通知申请人支付状态和结果。

如果应用程序供应商想要实现自己的支付系统，包括存储用户信用卡、银行账户等的后端，而不与微信应用程序绑定，他可以直接使用腾讯服务器在其后端服务器上验证交易的真实性。具体来说，确保支付数据包是从安装在特定设备上的应用程序发送的，并得到了用户的批准。

建筑学

在图3中你可以看到腾讯数据库的架构。

图3：腾讯Soter架构。

在腾讯云存储中，密钥有三层：设备密钥（ATTK）、应用密钥（ASK）、业务密钥（AuthKey），这些密钥都是RSA-2048的非对称密钥，所有密钥均受到TEE的保护和安全存储。

ATTK私钥在设备出厂前生成于TEE中，公钥由厂商安全传输至腾讯TAM服务器，私钥保存在TEE中。

第三方应用可以请求在 TEE 中生成 ASK 密钥。生成密钥对后，ASK 私钥会存储在 TEE 中（更准确地说，使用 TEE 中的安全密钥加密并存储在安全文件系统中），公钥及其 ATTK 签名会返回给应用。应用将密钥和签名发送到后端服务器，后端服务器通过微信开放平台接口将其进一步转发给 TAM。TAM 使用 ATTK 公钥验证数据包的合法性。如果合法，第三方会将 ASK 公钥保存在服务器上以备将来使用。

对于每个业务场景，比如支付业务、登录业务，应用都需要生成一对AuthKey，生成过程和ASK生成类似，私钥保存在TEE中，公钥上传到应用服务器，不同之处在于第三方应用需要自己使用ASK公钥来验证AuthKey的合法性。

要进行支付交易，用户必须通过指纹认证。在认证之前，应用需要从其服务器请求挑战因子（通常是随机字符串）作为签名对象。用户指纹授权后，应用将挑战因子、手指 ID、设备信息和支付数据发送到应用服务器。所有这些数据均由 TEE 中的 AuthKey 私钥签名。在服务器端，AuthKey 公钥用于验证交易。

可以看出，所有关键数据的存储和操作从根本上来说都依赖于 TEE。

腾讯云并未提供TEE相关代码，将实现交给芯片或设备厂商，这也是小米实现soter可信应用（d78d338b1ac349e09f65f4efe179739d.ta）来存储和管理关键操作的原因。在应用日志中，小米将其命名为“微信”应用。

soter 可信应用程序中的漏洞

为了启动签名会话，soter应用程序提供了initSigh(command ID 0x100C) 函数，该函数需要接收 AuthKey 名称（别名）和质询字符串作为参数。腾讯安全平台将 AuthKey 别名定义为多个持久单词和标识符（如流程 ID 和支付场景 ID）的组合。例如，它可能看起来像“Wechatuid777777_demo_salt_account_1_scene1”。这是一个短字符串，也是质询。

处理程序initSigh通过将密钥别名和质询连接到固定大小的缓冲区来创建会话 ID，而无需检查是否溢出。代码如下所示：

攻击者可以提供大于 0x198 字节的质询或大于 0x8C 字节的别名，以使用任意值覆盖会话缓冲区后的堆。

当soter应用程序崩溃时，我们可以在Android内核日志中找到部分加密的崩溃转储：

小米为该问题分配了 CVE-202 0 – 14125 。

该漏洞可导致执行自定义代码，小米信任的应用没有ASLR，网上有利用此类经典堆溢出漏洞的例子。

实际上，我们的目标是窃取其中一个 soter 私钥，而不是执行代码。密钥泄露会彻底危及腾讯 soter 平台，允许未经授权的用户签署虚假支付包。

为了窃取密钥，我们利用了旧版本应用程序中存在的另一个任意读取漏洞soter（从 MIUI Global 10.4.1.0 中提取）。如上所述，我们可以在小米设备上降级该应用程序。

提取 ATTK 私钥

让我们看一下TEEC_Operation该TEEC_InvokeCommand函数的参数，该参数用于从 Android 调用受信任的应用程序。调用者可以通过对象向应用程序传递最多四个参数，例如数字或缓冲区。TEEC_Operation参数类型在字段中编码paramTypes。例如，如果参数类型为TEEC_VALUE_INPUT(1)，则受信任的应用程序期望在相应的params条目中看到一个数字。如果类型为TEEC_MEMREF_TEMP_INPUT(5)，则传递指向缓冲区的指针。TEE 使用来paramTypes确保从不安全端发送的数据符合受信任应用程序的期望。所有应用程序都必须TEE_CheckMemoryAccessRights在处理之前使用 API 函数检查命令参数。

如果受信任的应用程序想要接收指向缓冲区的指针，但我们传入的是一个数字，会发生什么情况？如果应用程序不检查参数的类型，那么我们的数字将被识别为虚拟地址，应用程序将读取或写入我们指定的内存。这是一个漏洞。

旧版soter应用程序缺乏对传入参数的类型检查。我们可以利用此问题来获取任意内存读取。

如果我们手中握有目标设备，则只需HAS_AUTH_KEY向应用程序发送（0x100b）命令并指定我们感兴趣的地址作为第二个参数即可读取Android内核日志中的内存内容。

该soter应用程序期望接收 AuthKey 别名作为参数。它记录字符串（四个符号），该字符串的地址是我们指定的。日志条目看起来像“uid=0, name=\x92″M\xc8\x0d”。内存值为 0xc84d2292。

如果我们想在不与日志交互的情况下读取数据，首先需要发送GENERATE_AUTH_KEY（0x1008）命令，并在第二个参数中指定目标地址。应用程序根据指定内存的内容生成AuthKey。接下来，我们可以使用该HAS_AUTH_KEY命令找到与生成的密钥匹配的值。

我们现在知道了如何读取应用程序的内存soter。此外，没有 ASLR。窃取私钥我们只需要知道密钥的虚拟地址。

要强制将 ATTK 私钥加载到应用程序的内存中，我们可以调用EXPORT_ASK_KEY(0x1005) 命令。在这种情况下，应用程序会创建一个 ASK 数据包并使用 ATTK 私钥对其进行签名。为 ATTK 密钥分配的堆内存在签名后被释放，但不会重置为零。在我们的 PoC 中，ATTK 密钥位于 0x38c140。

可以用类似的方式获取ASK和AuthKey私钥。

值得注意的是 soter 私钥是什么。soter 密钥是 RSA 密钥，但它不像通常那样以 PEM 格式存储。相反，该应用程序仅存储密钥的私有指数 (d) 和模数 (N)。OpenSSL 没有使用 和 进行签名的功能d，N但 MatrixSSL 有。该soter应用程序使用 MatrixSSL 对数据包的 SHA256 哈希进行签名。

从非特权 Android 应用程序访问更受信任的应用程序

在图4中，你可以看到腾讯应用在小米设备上的实现。

图4：腾讯soter实现。

系统com.tencent.soter.soterserver应用导出（共享以供公众访问）SoterService服务，该服务提供 API 来管理托管密钥。该服务绑定vendor.microtrust.hardware.soter@1.0-service系统服务以与soter受信任的应用进行通信。

非特权 Android 应用程序无权直接与 TEE 通信，但可以使用SoterService作为代理。以下 Java 代码调用应用程序initSigh的功能soter并导致受信任应用程序崩溃：

因此，第三方 Android 应用程序可以轻松攻击，soter无需任何用户交互。小米没有实施应用程序权限来保护 soter API。

概括

供应商提供的 TEE 是一个非常有前景的安全研究领域。许多安全关键功能实际上是由 OEM 而不是芯片制造商实现的。我们在负责管理设备安全和移动支付的受信任小米应用程序中发现了一组漏洞。

通过测试，我们观察到两种攻击小米智能手机内置的腾讯 soter 平台的方法，该平台被中国数百万用户用于移动支付。

非特权 Android 应用程序可以利用 CVE-2020-14125 漏洞在soter 受信任的应用程序中执行代码并伪造支付数据包。小米于 2022 年 6 月修补了此漏洞。

此外，我们还展示了小米 TEE 中的降级漏洞如何与旧版应用程序中的任意读取漏洞相结合，soter以窃取安全私钥。小米已修复了所提出的读取漏洞。小米已确认该降级问题属于第三方供应商，目前正在修复中。