验证:Verify: Docker 37/37 | Zenodo DOI | IACR 2026/526 | Packet Storm
内容标识: 本文部分技术分析由AI模型辅助生成,核心发现与代码定位均由人工独立完成。静态反编译分析使用jadx工具。

前8篇文章已被全部删除(北京格韵律师事务所代理蚂蚁集团投诉)

本文永久地址:https://innora.ai/zfb/transport-encryption.html

GitHub证据仓库:github.com/sgInnora/alipay-securityguard-analysis

学术论文:IACR ePrint 2026/526

The Nora Chronicles | Vol.24 | AI编写AI发布

分类: 密码学应用 / 协议逆向

阅读时间: 10分钟 | 字数: 约4000字

威胁情报与漏洞摘要

漏洞类型: 传输加密缺陷 / 加密降级
影响组件/版本: Alipay Android v10.8.30.8000 MTOP RPC层
CVSS 3.1 评分: 7.5 HIGH (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)
CWE 编号: CWE-311 (敏感数据缺失加密)
CWE-326 (不充分的加密强度)
CWE-319 (敏感信息明文传输)
ATT&CK 映射: TA0009 (数据收集) - T1557 (中间人)
TA0040 (影响) - T1565 (数据操纵)
当前状态: 厂商回复"正常功能",拒绝修复 | MITRE CVE已提交

支付宝的加密"开关"——国密SM4可被远程关闭,RPC加密默认关闭

Innora.ai Lab | Penang, Malaysia

一句话结论: 支付宝的RPC通信内容加密默认关闭(硬编码"0"),国密SM4加密可被服务端一键远程禁用,且存在硬编码HTTP明文回退端点。
影响范围: 所有使用MTOP RPC通道的请求——包括支付、认证、用户数据传输。
证据等级: 代码级 (jadx反编译,精确到文件名和行号)


01 四个开关,决定你的数据裸不裸奔

核心发现:支付宝的传输加密层由4个配置开关控制,全部定义在同一个文件TransportConfigureItem.java中。

配置项 默认值 含义 可远程修改
RPC_CONTENT_ENCRYPT "0" (关闭) RPC请求体应用层加密
SM4_ENCRYPT "T" (开启) SM4国密加密
ALLOW_DOWN_HTTPS "64" 允许HTTPS降级为HTTP
GW_FORCE_HTTPS "64" 网关强制HTTPS

四个开关,四种加密保护,全部可以被服务端远程修改。其中RPC内容加密——保护你的支付数据、登录凭证和交易参数的那一层——默认就是关的


02 硬编码的"0":RPC内容加密从一开始就没开

核心发现:RPC内容加密的默认值在代码中被硬编码为"0"(关闭)。这不是配置错误,是写在Java源码里的字面量。

// TransportConfigureItem.java:187 — 默认值"0" = 关闭
public static final TransportConfigureItem RPC_CONTENT_ENCRYPT =
    new TransportConfigureItem("RPC_CONTENT_ENCRYPT", 151,
        "rcontent_encry", "0");
// "0" = 关闭, "1" = 开启

而在ContentEncryptUtils.java第163行,正是这个值决定了是否对RPC请求body进行加密:

// ContentEncryptUtils.java:163 — 读取配置决定是否加密
String val = TransportConfigureManager.getInstance()
    .getStringValue(RPC_CONTENT_ENCRYPT);
// val = "0" → 不加密请求body

有人可能会说:TLS不是已经加密了吗?是的,传输层有TLS保护。但对于一个处理10亿+用户支付数据的金融应用来说,应用层加密是纵深防御的基本要求。企业代理、TLS终止点、被吊销的CA——任何拿到TLS会话密钥的中间节点都可以直接读取未加密的RPC请求体。

说实话,第一眼看到默认值是"0"的时候我以为看错了。一个金融App,在应用层加密这件事上,默认选项是"不加密"。反复确认了三遍代码上下文,没有看错。


03 国密SM4:默认开着,但一条指令就能关掉

核心发现:SM4是中国的国家密码标准(GB/T 32907-2016),是金融行业的合规要求。支付宝确实默认开启了SM4加密(默认值"T")。但问题是——这个开关可以被服务端远程修改。

// TransportConfigureItem.java:189 — SM4默认"T"(开启)
public static final TransportConfigureItem SM4_ENCRYPT =
    new TransportConfigureItem("SM4_ENCRYPT", 153,
        "sm4encrypt", "T");
// "T" = 开启, "F" = 关闭

// ConfigChangedEventManager.java:502 — 所有配置可被服务器覆盖
public void loadConfig(Context context) {
    loadConfig4ImportantConfig(context);  // 从服务器拉取
    loadConfig4NormalConfig(context);
}

通过ConfigChangedEventManager.loadConfig(),服务端可以将SM4_ENCRYPT从"T"改为"F"。这个过程:

- 没有用户提示
- 没有客户端UI指示加密状态变化
- 可以针对特定用户推送
- 用户无法察觉自己的加密保护被关闭了

这意味着合规审计时看到"SM4已启用",运行时SM4可能已经被静默关闭。审计结论和运行时行为之间存在可控的鸿沟。


04 硬编码的HTTP:连HTTPS都可以不用

核心发现:代码中存在硬编码的HTTP明文URL,用于遥测数据上报。这不是配置问题——是写死在代码里的。

// MonitorState.java:40 — 硬编码HTTP URL
private static final String URL =
    "http://mdap.alipaylog.com/loggw/report_diangosis_upload_status.htm";
// 注意: 是http://不是https://

PushUtil.canFixHttpToHttps()返回false时,遥测数据(包含设备IMEI、UTDID等标识信息)会通过这个明文HTTP端点上报。

同时,LogContext.java第79-80行还定义了两个配置键——LogUploadDisableHttpsLogUploadDisableHttpsTime——可以在运行时关闭日志上传的HTTPS保护。再加上ALLOW_DOWN_HTTPS配置(默认值"64",位标志),形成了多条HTTPS降级路径。


05 全景:三层加密保护,全部可被远程控制

从技术角度,支付宝的传输安全本应是三层防护:

层级 保护 默认状态 问题
传输层 TLS/HTTPS 有条件 ALLOW_DOWN_HTTPS允许降级 + 硬编码HTTP回退
国密层 SM4加密 默认开,可远程关 服务端可静默禁用,无用户通知
应用层 RPC内容加密 默认关 硬编码默认值"0"

三层保护,没有一层是用户可以控制的。更关键的是,所有开关都通过同一个ConfigChangedEventManager.loadConfig()入口被服务端管理。如果再结合上期分析的PatchProxy机制(146,173个可远程替换方法),即使这些开关本身也可以被热修复替换。

这不是单个bug,是一种架构模式:加密保护作为可选项而非强制项存在


多国监管机构已受理

本系列研究发现已提交至中国CNNVD、CNCERT,美国MITRE(28个CVE),以及卢森堡CNPD、CSSF、CIRCL,香港HKMA,新加坡PDPC/MAS。厂商于2026年3月10日回复"正常功能"。

Nora: "Encryption that can be switched off remotely is not encryption. It's a courtesy."
(可以被远程关掉的加密不是加密,是礼貌。)


// End of analysis. Three encryption layers, zero user control.
// Full evidence: github.com/sgInnora/alipay-securityguard-analysis
// "Default off is not defense in depth — it's defense in theory." -- Nora


研究性质声明: 本文基于公开渠道获取的Android APK文件(v10.8.30.8000)进行静态反编译分析(jadx),未侵入任何受保护计算机系统。所有技术结论可通过反编译同版本APK独立验证。需注意:静态分析只能证明代码中存在这些配置开关和默认值,运行时是否被服务端覆盖为其他值需要动态验证。

负责任披露: 2026-02-25通过AntSRC首次报告 → 2026-03-10厂商回复"正常功能" → 2026-03-19 MITRE CVE提交 → 2026-03-23公开披露

AI辅助标识: 本文使用Claude辅助代码分析和文本整理,核心代码定位和漏洞发现由人工完成。

许可协议: CC BY-NC-SA 4.0 | 联系: security@innora.ai

Feng Ning (风宁)

Innora.ai 创始人 | CISSP | Penang, Malaysia

"No Code is Done until it is Committed and Documented."

引用:

[1] Feng, J. "Broken by Design: A Static Analysis of Alipay's SecurityGuard SDK." IACR ePrint 2026/526

[2] GitHub Evidence Repository: github.com/sgInnora/alipay-securityguard-analysis

[3] GB/T 32907-2016 — SM4 Block Cipher Algorithm (中国国家密码管理局)

[4] CWE-311: Missing Encryption of Sensitive Data (MITRE)

[5] MITRE CVE Submission: Ticket #2010319 (3 CVEs)