前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已提交 |
Innora.ai Lab | Penang, Malaysia
一句话结论: 支付宝的RPC通信内容加密默认关闭(硬编码"0"),国密SM4加密可被服务端一键远程禁用,且存在硬编码HTTP明文回退端点。
影响范围: 所有使用MTOP RPC通道的请求——包括支付、认证、用户数据传输。
证据等级: 代码级 (jadx反编译,精确到文件名和行号)
核心发现:支付宝的传输加密层由4个配置开关控制,全部定义在同一个文件TransportConfigureItem.java中。
| 配置项 | 默认值 | 含义 | 可远程修改 |
|---|---|---|---|
| RPC_CONTENT_ENCRYPT | "0" (关闭) | RPC请求体应用层加密 | 是 |
| SM4_ENCRYPT | "T" (开启) | SM4国密加密 | 是 |
| ALLOW_DOWN_HTTPS | "64" | 允许HTTPS降级为HTTP | 是 |
| GW_FORCE_HTTPS | "64" | 网关强制HTTPS | 是 |
四个开关,四种加密保护,全部可以被服务端远程修改。其中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),这一默认值确认无误。
核心发现: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可能已经被静默关闭。审计结论和运行时行为之间存在可控的鸿沟。
核心发现:代码中存在硬编码的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行还定义了两个配置键——LogUploadDisableHttps和LogUploadDisableHttpsTime——可以在运行时关闭日志上传的HTTPS保护。再加上ALLOW_DOWN_HTTPS配置(默认值"64",位标志),形成了多条HTTPS降级路径。
从技术角度,支付宝的传输安全本应是三层防护:
| 层级 | 保护 | 默认状态 | 问题 |
|---|---|---|---|
| 传输层 | TLS/HTTPS | 有条件 | ALLOW_DOWN_HTTPS允许降级 + 硬编码HTTP回退 |
| 国密层 | SM4加密 | 默认开,可远程关 | 服务端可静默禁用,无用户通知 |
| 应用层 | RPC内容加密 | 默认关 | 硬编码默认值"0" |
三层保护,没有一层是用户可以控制的。更关键的是,所有开关都通过同一个ConfigChangedEventManager.loadConfig()入口被服务端管理。如果再结合上期分析的PatchProxy机制(146,173个可远程替换方法),即使这些开关本身也可以被热修复替换。
这不是单个bug,是一种架构模式:加密保护作为可选项而非强制项存在。
所有发现均可通过以下公开资源独立复现:
· · ·
1. 行业对比:加密是铁律,不是选项。 在金融领域,银行App的核心加密措施被硬编码在客户端,不允许远程关闭。国际支付卡行业数据安全标准(PCI DSS)明确要求对持卡人数据的加密是强制性的,不存在"可配置"的开关。中国人民银行《金融数据安全 数据安全分级指南》(JR/T 0197-2020)对4级以上数据同样要求强制加密传输。
2. 架构区分:UI灵活性 ≠ 安全可配置。 远程配置UI主题色是常规运维;远程关闭核心加密保护是安全架构缺陷。二者本质不同。一个负责任的安全架构中,加密模块必须独立于业务配置,核心加密策略应强制执行且不可旁路。
3. 密码法红线:不可商量。 《密码法》第二十七条要求关键信息基础设施"使用"商用密码进行保护——是"使用",不是"可选使用"。在代码中预留远程关闭SM4加密的能力,无论是否实际触发,其存在本身就使"密码应用安全性评估"(密评)无法通过。
· · ·
已向MITRE提交36份CVE报告(11个跟踪工单),覆盖密码学、热修复、隐私、认证等多个领域。
以下9+国家/地区的监管机构已受理或正在协调:
厂商于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)