论文:[1] Y. Chen, L. Xing, Y. Qin, X. Liao, X. W. 0001, K. C. 0012, and W. Zou, “Devils in the Guidance – Predicting Logic Vulnerabilities in Payment Syndication Services through Automated Documentation Analysis.,” USENIX Security Symposium, 2019

问题背景

图一:

支付宝,微信,PayPal等支付应用广泛应用,上图是支付宝API的使用流程。一个商家开发一个APP的支付体系需要全面的包括支付宝、微信、京东支付,…等等…..,其中包括各种检查,公钥私钥之类的东西,程序员开发起来比较复杂,门槛也未免太高,这个时候一站式集成支付解决方案出来啦!下图是BeeCloud解决方案。

图二:

这一类的东西,在文章中被称为"payment syndicator",他们相当于是对支付宝微信一类的软件API进行了封装,更方便商家程序员开发。

常见这样的“payment syndicator”,有BeeCloud全套式支付解决方案,Ping++聚合式支付解决方案,PayMax聚合支付解决方案,TrPay聚合支付等等。

但是倘若这样的payment syndicator出现某种问题,那么必将会影响大部分APP。

这里举一个例子,在用户支付之后,需要验证异步支付结果,做一些只检查之类的,但是由于一站式解决方案的程序员疏忽大意,对信息进行了不完整的检查或者是缺少检查,那么商家APP——商家后台这个交易体系就是存在逻辑漏洞的。在本文中,作者提出了一种依据“payment syndicator”官方文档,去发现商家APP——商家后台是否存在逻辑漏洞的方法。称为:Document analysis for flaw detection,简称Dilution,大体上是使用自然语言处理相关方法对"payment syndicator"的官方文档提取自动机模型,然后与“支付宝、微信等”的官方文档手动提取出来的有限自动机模型进行比较,以此来发现"payment syndicator"漏洞,又或者是文档本身的漏洞(比方说没有通知到开发者要进行必要的安全检查,进而造成了一些开发者没有在他们的app中进行这些检查,导致一部分app出现漏洞)。

具体方法

文章花了很长的段落介绍背景,以及作者使用他所提出的方法发现的成果。

下面是该方法所相关的几个知识(这里花的时间比较长):

NLP中的依存句法分析(Dependency Parsing):简单的说是按照语法结构构建自然语言句子的语法树,下图是一个例子:

这篇文章中利用从待测试官方文档中的句子生成的语法树来定位支付过程中涉及的各方以及它们之间传输的内容。

NLP中的Word2Vec:简单的说是把单词按照某种方法转为向量。判断单词相似性的有欧氏距离和余弦距离,在这篇文章中利用Word2vec为每个单词生成一个语义向量,并通过向量之间的余弦距离来测量它们的语义差异。

威胁模型:在这里假定攻击者作为一个中间人,具有修改和伪造网络包的能力,它意图免费或者更低价格购入商品。

方法流程框架

预处理步骤是在系统中手动完成的,包括提取"支付宝、微信等"的有限自动机和安全检查要求标签。由于重点是“payment syndicator”,所以认为这一步是一次性的:对于每一个第三方支付,识别出的信息可以用来自动分析数十个"payment syndicator",每个服务都有一个包含数十万字的文档。Documentation Analyzer检查这些文档,它利用NLP技术将第三方支付的有限自动机扩展为表示“payment syndicator”动作的状态,并进一步从文档中恢复每个安全检查要求的描述。然后,扩展的有限自动机和参数由Logic-flaw Predictor进行分析,以确定APP和"payment syndicator"不能满足的安全检查要求,以及那些在文档中没有向开发者正确解释的安全检查要求。此外,Logic-flaw Predictor预测的逻辑缺陷在APP使用“payment syndicator”时得到验证,确认这些漏洞是否真正的存在。

举例子展示:下图(a)是直接使用支付宝时的有限自动机,在mf状态有安全检查要求:“检查支付金额是否和商品金额一致”。Documentation Analyzer分析Fuqianla的文档,发现订单发送给"payment syndicator"(“APP发送一个支付查询给fuqinla 服务器),支付宝发出的通知在转发给商户之前,将被发送给“payment syndicator”(“Fuqianla拉服务器将收到支付服务发出的支付通知”)。然后使用从文本中恢复的语义将图(a)中的状态m1替换为状态w1,并将状态w2添加到有限自动机,将其转换为图(b)中所示的"payment syndicator"有限自动机。这个扩展的有限自动机和它所携带的所有参数然后由Logic-flaw Predictor进一步检查。让我们来看看前面提到的mf的安全检查要求。在这种状态下,Logic-flaw Predictor的结论是,"syndicator"不能检查支付金额,因为它从买方而不是商人那里获得价格信息,这是不可信任的。另一方面,尽管商家可以进行安全检查,但Logic-flaw Predictor无法在最后一次通信(从w2到mf)描述之后找到一个句子,通过对所有涉及主题(商家)相关的句子的NLP依存句法分析,将安全价差要求告知开发者,安全检查的对象(价格和付款金额)和预期操作。这导致了,即安全检查要求可能没有传达给开发者,因此可能没有在商家APP里实现。

Syndication FSM Discovery

从Syndication文档中构建出自动机模型。

首先下图是对图5的一个总结,这里展示了从直接Payment到使用Syndication,自动机上的扩展改变。

如何从文档中提取出扩展后自动机模型成为了关键。

Extension discovery from document

为了构建出自动机,每一个转换需要三个信息(Sender、Receiver,Content)。这些信息从文档中获取,但是存在的一个问题是表示发送的单词有很多,它们意思相近,例如:"send",“call”,“invoke”,作者训练了一个word2vec模型,根据余弦距离,寻找相近意思的单词,以此来进行简化。现在问题的关键是如何从句子中得到三者(Sender,Receiver、Content),如下图,比方有句子:“Client sends payment_element to your server”,作者使用LTP平台进行分词,生成树结果如图所示,这个树的三个叶子分别为(Client,your server,payment_element),与(Sender、Receiver,Content)相对应。

依据这个相同的思路从文档中获取SR(必要的安全检查),模型为(SR_{state}, SR_{obj}, SR_{para}

自己的思考

这种基于文档的漏洞发现方法是一个新方向,使用条件应该是去挖局一些在常用sdk上进行二次开发的sdk,拥有文档的sdk,之所以作者选定支付集成解决方案作为漏洞挖掘目标,正是因为这个原因。

推广:基于文档的漏洞发现思路很新,但是感觉应用面不是很广泛,目前没想到可以去挖掘什么其他的sdk。

相关资料:

  1. word embedding:word2vec use python https://www.geeksforgeeks.org/python-word-embedding-using-word2vec/
  2. understanding Word2Vec: https://gist.github.com/aparrish/2f562e3737544cf29aaf1af30362f469
  3. dependency parsing in NLP: https://www.youtube.com/watch?v=1_LQscB4Wso