phphashhmac无效技巧_技能分析哈希设计缺陷分析

你从某个在线商店（或店铺）中选择商品。

在网站上输入你的信用卡卡号。

信用卡卡号、金额等信息经由署名后返回给浏览器，浏览器会将这些信息自动POST到中间支付网关。

中间支付网关将信息转换为MIGS可识别的格式，利用MIGS密钥署名后，将信息返回给浏览器。
这一次浏览器会将信息自动POST到MIGS做事器。

如果不须要3DSecure做事，则转到步骤6。
如果须要3DSecure做事，MIGS会将要求重定向到发卡银行，银行会要求OTP（One-time Password，动态口令）信息，然后天生HTML页面，将数据自动POST到MIGS。

MIGS将署名后的数据返回给浏览器，然后将数据自动POST回中间网关。

中间网关会根据署名确认数据是否有效。
如果不是有效数据，则会天生缺点页面。

支付网管根据MIGS的相应将支付状态转发给商家。

须要把稳的是，通信过程由用户的浏览器来完成，用户无需与做事器打交道，而且所有数据都经由署名。
从理论上讲，如果署名过程以及验证过程精确，那么全体过程不会涌现任何问题。
不幸的是，实际情形并没有那么完美。

这个问题非常大略。
MIGS利用的哈希算法为：

MD5(Secret + Data)

这种办法不会受到哈希长度扩展攻击的影响（目标采取了某些检讨机制以阻挡这类攻击）。
个中，Data的创建过程如下：系统对以vpc_开头的每个查询参数进行排序，然后不该用分隔符，直接将这些值连接起来。
比如，对付如下数据：

对应的查询参数为：

对这个参数进行排序

提取参数值，连接起来：

现在如果我改了要求参数，如下所示：

排序结果如下：

提取参数值，连接起来：

天生的MD5值与第一种情形相同。
以是大体上来讲，当数据被发送到MIGS时，我们可以在金额（amount）后面插入额外的参数，这样就能覆盖掉末了面的数字，也可以插在前面，这样就能覆盖掉前面的数字，这样一来，支付的金额会被减少，我们就能用2美元来购买代价2000美元的MacBook。

中间网关以及商家可以检讨MIGS返回的金额与要求的金额是否同等，这样就能办理这个缺点。

关于这个漏洞，MasterCard褒奖了我8500美元。

新的HMAC-SHA256哈希机制中存在一个毛病，如果我们可以向中间支付网关插入无效值，我们就能利用这个毛病。
经由我的测试，我创造至少有一个支付网关（Fusion Payments）受这个问题影响。
从Fusion Payments那里我得到了500美元的褒奖。
其他支付网关如果连接到MIGS，可能也会受到这个问题影响。

在新版本中，他们在各字段之间添加了分隔符（&）以及字段名，不像原来那样只有字段值，并且利用了HMAC-SHA256作为哈希算法。
还是谈论前面的那个数据，新的散列数据为：

这段数据中我们无法改变任何信息，统统看起来都特殊美好。
然而，如果某个值包含“&”或者“=”或者其他分外符号，会涌现什么情形呢？

从这个文档中，我们找到这样一段话：

“把稳：为了便于哈希处理，所有的字段名-字段值中的值都不应该经由URL编码处理。
”

我将“不”字重点标记出来。
这意味着，如果我们利用如下字段：

这些信息会利用如下办法进行哈希处理：

而如果我们利用如下字段（金额中包含“&”及“=”字符）：

这些信息的哈希处理办法变成：

得到的结果完备同等。
目前这还不是一个真正的问题。

当然，我第一反应是文档可能出了点问题，可能这些数据须要经由编码处理。
然而我检讨了MIGS做事器的反应，创造做事器的反应与文档描述的同等。
可能它们不想处理不同的编码（比如不想看到“+”变成“%20”）。

这看起来貌似不存在什么问题，MIGS会检讨任何无效的值，无效值会导致缺点涌现（比如无效的金额会被网关谢绝）。

然而我把稳到，对某些支付网关来说，它们不会在做事端验证输入的有效性，而是直接署名所有数据，然后将结果发送给MIGS。
这种办法可以减轻处理的繁芜度，毕竟在客户端利用JavaScript检讨输入数据更加方便，做事端只须要大略署名数据后，让MIGS判断数据是否精确即可，比如MIGS可以判断卡号是否精确、CVV该当为3个或者4个数字、信用卡过期韶光是否精确等等。
这种处理办法背后的逻辑在于：MIGS会重新检讨输入数据，并且会做得比支付网关更加出色。

我创造Fusion Payments这个支付网关的确存在这种征象：它们许可用户在CVV字段发送任意长度的任意字符（检讨过程只依托JavaScript来完成），署名要求数据后，直接将数据发往MIGS。

4.1 漏洞利用

为了利用这个漏洞，我们须要布局一个字符串，这个字符串对应一个有效的要求，同时也须要准备一个有效的MIGS做事器相应数据。
我们完备不须要与MIGS做事器通信，只须要强制客户端自己署名有效数据即可。

比如，要求格式如下所示：

从做事器返回的相应如下所示：

对Fusion Payments而言，我们可以在vpc_CardSecurityCode（CVV）这个字段中插入额外数据来利用这个漏洞：

客户端以及支付网关会为该字符串天生精确的哈希值。

现在，我们可以将这段数据POST回客户端（完备不须要与MIGS做事器通信），我们会轻微修正这段数据，以便客户端可以读取精确的变量值（大多数客户端只会检讨vpcTxnResponseCode以及vpcTransactionNo）：

须要把稳的是：

这段数据的哈希结果与之前的数据同等。

客户端会忽略vpc_AccessCode变量以及该变量内部的值。

客户端会处理vpc_TxnResponseCode等变量，然后认为交易过程没有问题。

我们可以认为这是个一个MIGS客户端漏洞，然而正是MasterCard选择的哈希算法导致这种情形发生，如果变量值经由编码，那么这个问题就不会存在。

4.2 MIGS的回应

MasterCard还没有回答HMAC-SHA256中存在的这个问题。
我同时将这个问题抄送给了处理过前一个漏洞的那几个人，然而我没有收到任何回答邮件，他们乃至没有回答“我们正在确认这个问题是否存在”之类的邮件。
在谈论MD5漏洞时，我将自己的Face

book见告过他们，以便他们能及时联系上我。

某些人总是不愿正面面对他们收到的漏洞报告，乃至会去否认这些报告，以是现在在报告漏洞时，我会将干系信息保存到经密码保护的文章中（这也是为什么你会在我的博客中看到几篇密码加密的文章）。
目前为止，至少有3个来自MasterCard的IP地址访问过这篇文章（3次密码输入行为）。
他们必须输入密码才能阅读报告，因此他们不可能在不阅读这篇文章的条件下欠妥心点击到文章链接。
现在每个星期我都会敦促他们给我个回答。

我希望他们能警告连接到他们系统的每个用户，让这些用户把稳检讨及过滤这类注入攻击。

我们还须要把稳的是：只管支付网关一贯在跟金钱打交道，然而它们并没有人们想象的那么安全。
在渗透测试过程中，我创造几个中间网关在设计支付协议时存在一些毛病。
不幸的是，我不能给出详细细节（渗透测试这个词意味着我须要遵守某些保密协议）。

我也在详细实现上找到过一些毛病。
比如哈希长度扩展攻击（Hash Length Extension Attack）、XML署名验证缺点等等。
个中最为大略的一个缺点是我在Fusion Payments上创造的。
我找到的第一个问题是：他们根本不会去检讨MIGS返回的署名。
这意味着我们可以修正MIGS返回的数据，将交易结果标记为成功状态。
也便是说，我们只要将一个字符从F（false）改成o（success）即可。

以是，我们只须要输入任意信用卡号，MIGS会返回缺点相应，然后我们只须要修正相应数据，就能得到支付成功结果。
这是一个市值2000万美元的公司，然而这个报告我只拿到了400美元的褒奖。
不单单这个支付网关存在这个漏洞，我在另一个支付网关也找到过同样一个漏洞。
在我联系过的网关中，Fusion Payments是唯一一个具有明确的漏洞褒奖操持的网关，他们很快就回答了我的邮件，并且修复了这个漏洞。

支付网关没有你想象的那么安全。
在褒奖金额相对较低的情形下（某些时候我报告了漏洞却收成了0美元），我想知道有多少人已经利用过支付网关中的漏洞。