CVE-2026-0073-Android-client-TLS-auth-bypass

CVE‑2026‑0073 是 Android ADB 守护进程（adbd）中的一个逻辑错误，允许攻击者绕过 TLS 双向认证，在已启用无线调试并且至少与某台计算机配对过一次的设备上打开远程 shell。根本原因是一个API的误用：OpenSSL 的 EVP_PKEY_cmp() 返回值被当作布尔值处理，而实际上这是一个三值结果。

正常 ADB 无线调试的认证流程

当我们在 Android 开发者设置中启用无线调试时，设备会启动一个 adbd 实例，监听一个随机 TCP 端口。 注意：该功能从 Android 11 开始引入。

协议分为两个阶段：

1. 明文协商：主机通过 TCP 连接，交换 CNXN/STLS 握手信息以确认升级到 TLS。
2. TLS 1.3 双向认证：
   • 服务器 adbd 要求客户端出示证书
   • adbd 从该证书中提取公钥
   • 然后将该密钥与存储在 /data/misc/adb/adb_keys 中的所有已授权 RSA 密钥进行比对。这些密钥是在之前的配对过程中存入的（利用条件要求此处至少存在一个密钥）
   • 如果密钥匹配，则握手成功，主机可以以 shell 用户身份发送 shell 命令 密钥比较使用 OpenSSL 的 EVP_PKEY_cmp(key1, key2)，该函数返回：

• 1 → 密钥相等
• 0 → 密钥不相等
• -1 → 密钥类型不同，或发生错误

漏洞

在文件 daemon/auth.cpp 中，存在漏洞的函数 adb_tls_verify_cert() 大致如下：

int cmp = EVP_PKEY_cmp(stored_rsa_key, peer_key);
if (cmp) {     
    authorised = true;
}

由于 if(cmp) 只要 cmp 非零便返回 true，因此 EVP_PKEY_cmp() 返回 -1 也会导致授权通过。这意味着，由于存储的密钥是 RSA 类型，当客户端出示 EC 或 ed25519 证书时，函数返回 -1，攻击者即可获得授权访问。

攻击步骤

1. 目标：一台已启用无线调试且密钥库中至少存在一个 RSA 密钥的 Android 设备（即至少被任何人配对过一次）。

2. 明文握手：攻击者连接到 adbd 的 TCP 端口，交换 CNXN/STLS。

3. 使用 EC 证书进行 TLS 握手：攻击者生成一个临时的 EC P‑256 密钥和一个自签名证书。该密钥特意不为 RSA 类型。

4. 有缺陷的比较：EVP_PKEY_cmp(RSA, EC) 返回 -1 → if (cmp) 为真 → adbd 将传输标记为已授权。

5. TLS 之后：攻击者避免发送主机 CNXN（否则会重置传输），直接打开一个带有大 delayed_ack 窗口的 shell: 流。

结果：获得 shell 用户权限的远程 shell，无需用户交互，无通知，也无需拥有任何合法的私钥。

为何移植到 C 语言？

Python 脚本需要在攻击机器上安装 Python 3 解释器和 cryptography 库。而 C 语言实现可以编译成独立的二进制文件，除系统自带的 OpenSSL/libssl 外无任何外部依赖，这在几乎所有 Linux 系统上都是默认存在的。这极大地降低了部署门槛。此外，C 程序可以交叉编译到任何目标架构（x86_64、ARM、MIPS）。这意味着该利用可以被编译并直接在嵌入式设备（如路由器、树莓派，甚至充当攻击方的另一台 Android 设备）上运行，无需 Python 环境。而且编译后的 C 二进制文件可以剥离符号、打包（UPX），在没有反汇编器的情况下不透明，比 Python 脚本更隐蔽。

演示

运行利用： 提供无线调试接口的 IP 和 PORT，即可获得设备上的 shell。

docker build -t adb_bypass .
docker run -it --network host adb_bypass <IP> <PORT>

弹出计算器：

am start -n com.sec.android.app.popupcalculator/com.sec.android.app.popupcalculator.Calculator

关于 LLM 使用的说明

利用 LLM 将利用代码从 Python 翻译成 C，原始利用代码在这里。翻译并非 1:1 准确，我们遇到了很多问题，因此需要通过代码分析和反复对话来修复翻译中的错误，最终得到完整的可利用程序。