内容标识: 本文部分技术分析由AI模型辅助生成,核心发现与代码定位均由人工独立完成。静态反编译分析使用jadx工具。

前8篇文章已从微信平台移除(蚂蚁集团经代理律师事务所提出投诉)

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

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

IPFS存证:QmapnEoic1d2mJjZEKj8vgJomRvbWBzq3aJfpXXQKratCK

学术论文:IACR ePrint 2026/526

The Nora Chronicles | Vol.24

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

阅读时间: 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请求体。

值得注意的是:一个日均处理数十亿笔交易的金融应用,在应用层加密配置上选择了"默认关闭"。经反复核对代码上下文(TransportConfigureItem.java:187 → ContentEncryptUtils.java:163),这一默认值确认无误。


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,是一种架构模式:加密保护作为可选项而非强制项存在


07 独立验证:完整复现指南

所有发现均可通过以下公开资源独立复现:

· · ·

预防性说明:为何"正常运维"的解释不成立

1. 行业对比:加密是铁律,不是选项。 在金融领域,银行App的核心加密措施被硬编码在客户端,不允许远程关闭。国际支付卡行业数据安全标准(PCI DSS)明确要求对持卡人数据的加密是强制性的,不存在"可配置"的开关。中国人民银行《金融数据安全 数据安全分级指南》(JR/T 0197-2020)对4级以上数据同样要求强制加密传输。

2. 架构区分:UI灵活性 ≠ 安全可配置。 远程配置UI主题色是常规运维;远程关闭核心加密保护是安全架构缺陷。二者本质不同。一个负责任的安全架构中,加密模块必须独立于业务配置,核心加密策略应强制执行且不可旁路。

3. 密码法红线:不可商量。 《密码法》第二十七条要求关键信息基础设施"使用"商用密码进行保护——是"使用",不是"可选使用"。在代码中预留远程关闭SM4加密的能力,无论是否实际触发,其存在本身就使"密码应用安全性评估"(密评)无法通过。

· · ·

08 全球监管机构沟通进展(更新至2026年3月25日)

已向MITRE提交36份CVE报告(11个跟踪工单),覆盖密码学、热修复、隐私、认证等多个领域。

以下9+国家/地区的监管机构已受理或正在协调:

  • 卢森堡:CSSF(金融监管)、CNPD(数据保护)、CIRCL(应急响应)
  • 中国香港:HKMA(香港金融管理局)
  • 新加坡:PDPC + MAS(金融管理局)
  • 马来西亚:BNM(国家银行)
  • 中国大陆:CNNVD(国家信息安全漏洞库)、CNCERT(国家互联网应急中心)

厂商于2026年3月10日回复"正常功能"。随后8篇相关技术分析文章从微信平台被移除

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 | 联系: [email protected]

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: Tickets (36 CVEs across 11 tickets)