0x00 前言
7月3日,正在开心撸着码的我突然被微信消息炸锅了。
微信的支付WXSDK出现了漏洞 。(⊙o⊙)? 纳尼?
撸着码的我急忙放下了手头的工作,看向了先知论坛
0x01 漏洞概要
漏洞的始发是在seclists.org上的
XXE in WeChat Pay Sdk ( WeChat leave a backdoor on merchant websites)
看描述挺吓人的,微信wechat的SDK有XXE漏洞(微信在商家的网站留了后门)。
报漏洞是好事,但是不要“搞事情”啊,好好写标题不行么:)
但是仔细看的话,出问题的是是在JAVASDK中WXPayUtil.java中
# java-sdk-v3\src\main\java\com\github\wxpay\sdk\WXPayUtil.java
DocumentBuilderFactory documentBuilderFactory = DocumentBuilderFactory.newInstance();
我们知道 DocumentBuilderFactory 是JAVA用来解析xml的一个库。
如果没加 setExpandEntityReferences(false); 可以用来加载外部实体。
因为这个导致了漏洞的产生。这个漏洞存在于微信返回商家后台接口中
我们再回到微信的接口文档查看(毕竟业务比较重要 需要仔细查看)
可以看到 返回的数据 并不需要加载任何实体。可以放心的设置setExpandEntityReferences(false)
0x02 漏洞自查
找业务咨询信息
漏洞比较严重,我们赶紧联系了业务部门询问了接口的情况并拿到了源代码。但是我们后端的微信支付接口是 .net 写的。 并没有直接使用腾讯的SDK。
实际上,很多大一点的厂都会修改官方SDK,以适配自己的支付系统。
所以这次的JAVA SDK,并没有对我们造成影响。
0x03 进一步排查
理论上,一般这个时候,故事就结束了,然而事情并没有那么简单。
对于一个漏洞,甲方更关心
-
它是怎么发生的
-
它影响的范围有多大
-
怎么去修复/应急,排查类似同类问题
它是怎么发生的
很明显,这和SDK其实没太大关系,这是一个常见的XXE问题。
业务系统是否对XML加载是否禁用了外部实体加载。
虽然我们没有用JAVA SDK,但是是否是代表我们就没问题了呢?
答案是否定的,在同事的帮助下,我们搭建了和业务系统一致的环境进行测试。
c# 有两种加载xml的方式,除了日常的libxml,还有原本的 XmlDocument
而业务场景下,是这种方式去加载xml的
var xmlDoc = new XmlDocument(); xmlDoc.LoadXml(xml);
仔细看了一下,=。=? 这不也没有禁止外部实体加载吗?
赶紧找回漏洞页面,寻找测试代码进行测试。
<!DOCTYPE root [
%xxe;
]>
发现页面报错,仔细检查了一下
多一个分号 修改为=>
重新发送,=。= 成功执行了。
它影响的范围有多大
很明显,涉及到xml的基本都存在这个问题,并不只是微信支付这一个点存在风险。
发现蛮多业务线均使用了XML,我们提供了一个简单的排查工具,让业务审查了一下。
难以单个进行修复,商议直接修改基类,替换原来的方法,直接从底层进行修复。
如何修复
虽然这次是微信示例SDK的漏洞,但是这次排查最终演变成企业内部XML使用规范的自检。
通过提供检测工具以及排查方法,最终在一天左右做了重要接口的XML检查和修复。
主流的4种语言 XXE修复方式如下
-
php
-
libxml_disable_entity_loader(true);
-
java
-
DocumentBuilderFactory.setExpandEntityReferences(false);
-
.Net
-
XmlDocument.XmlResolver = null;
-
Python
-
etree.parse(xmlSource,etree.XMLParser(resolve_entities=False))
-
更多语言的修复方式
https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Prevention_Cheat_Sheet#C.2FC.2B.2B
-
微信官方的检查及修复建议
https://pay.weixin.qq.com/wiki/doc/api/jsapi.php?chapter=23_5
-
再不修改代码的情况下,可以借助于WAF或者RASP来修复。
WAF添加关键词过滤规则:
百度开源的OpenRASP也支持检测和拦截XXE攻击。
https://github.com/baidu/openrasp/blob/master/readme-zh_CN.md
声明:本文来自同程安全应急响应中心,版权归作者所有。文章内容仅代表作者独立观点,不代表士冗科技立场,转载目的在于传递更多信息。如有侵权,请联系 service@expshell.com。