深入理解hash长度扩展攻击
0×01 引言
为什么会想到这个呢？上周末做了“强网杯”的童鞋们应该都能知道吧，它其中有个密码学的题目就是考的这一点。
0×02 sha1的hash原理
说到要解释sha1的原理其实是非常复杂的，反正我这种智商的暂时还无法理解。所以，只能从面上跟大家谈一下我的理解。
首先，当hash函数拿到需要被hash的字符串后，先将其字节长度整除64，取得余数。如果该余数正好等于56，那么就在该字符串最后添加上8个字节的长度描述符（具体用bit表示）。如果不等于56，就先对字符串进行长度填充，填充时第一个字节为hex(80)，其他字节均用hex(00)填充，填充至余数为56后，同样增加8个字节的长度描述符（该长度描述符为需要被hash的字符串的长度，不是填充之后整个字符串的长度）。以上过程，称之为补位。
补位完成后，字符串以64位一组进行分组（因为上面的余数为56,加上8个字节的长度描述符后，正好是64位，凑成一组）。字符串能被分成几组就会进行多少次“复杂的数学变化”。每次进行“复杂的数学变化”都会生成一组新的registers值供下一次“复杂的数学变化”来调用。第一次“复杂的数学变化”会调用程序中的默认值。当后面已经没有分组可以进行数学变化时，该组生成的registers值就是最后的hash值。
在sha1的运算过程中，为确保同一个字符串的sha1值唯一，所以需要保证第一次registers的值也唯一。所以在sha1算法中，registers具有初始值。如上图中的registers值0。
Hash值的随机性完全依赖于进行“复杂的数学变化”时输入的registers值和该次运算中字符串分组的数据。如果进行“复杂数学变化”时输入的registers值和该次运算的字符串分组相同，那么他们各自生成的新的registers值也相同。
0×03 举个栗子
当需要被hash的字符串为str_a = ”123456”，程序首先判断，len(str_a) % 64 == 56是否成立。这里很明显不成立。那么程序就进行补位操作。首先补位成余数为56的长度。
如上图，蓝色字体就为程序对该字符串进行补位的数据。当满足len(str_a) % 64 == 56后，程序就在该字符串的后面添加8个字节的长度描述符。注意，此处的长度为原始需要被hash的长度。也就是len(str_a) = 6字节*8bit/字节= 48bit=0x30bit。
补位+长度描述符=64个字节，正好是一个分组。所以此处只要进行一次复杂的数学变化就可以了。程序根据该64个字节的数据和registers值0生成新的registers值1。那么该新的registers值1就是str_a的sha1值
0×04 如何利用？
讲了这么多，好像都没讲到如何利用该扩展攻击。那么下面，重点来了。
我们还是利用这篇文章上面的例子进行讲解，转到FreeBuf之前文章。
简单来说，就是服务器上会生成一个salt值，该salt值你是不可预测的。但是你又知道了sha1(salt+filename)的值，该filename的值你也是知道的。假设此处的filename的值report.pdf，最后sha1的值为：0a8d538b724c6f2b4288526eb540ee7c。为了方便理解，我们继续假设salt的长度为16位。
将上图的字符串进行sha1操作时，同样先进行整除，然后取余。最后再补上8位的长度描述符。补位+添加长度描述符后的字符串如下图：
该长度也就满足了64位的分组，只需要进行一次“复杂的数学运算”就可以得到最后的sha1值了。
下面请各位看官思考如何进行下面一个字符串的sha1操作。
同样，还是先进行分组。由于该字符串的长度大于64个字节，且小于128个字节，所以要分成两组，需要进行两次“复杂的数学运算”。这个时候我们发现，第一个分组的数据和上图中补码后的数据完全一样，又因为他们都是第一个分组，初始的registers值也一样。那么经过第一轮“复杂的数学运算”，他们各自生成的registers值也同样是相同的。唯一不同的是，由于上面的长度小于64字节，所以只需要进行一轮运算便得到了最后的sha1值。然后这里的字符串有两个分组，需要将第一轮更新的registers值（也就是第一轮运算出来的sha1值）作为第二轮“复杂的数学运算”的registers值，然后才能得出最终的sha1值。
根据上面例子就说明，如果salt的值你不知道，但是你知道长度，又知道sha1(salt)，那么就也就可以知道sha1(salt+“填充数据”+“任意可控数据”).这里的salt+“填充数据”就是对salt进行sha1时所补全的数据+最后8位的长度描述符。一般来说，salt+”填充数据”的长度就是64字节，正好是一个分组。如果salt的长度就大于了56个字节，那么加入填充数据后的长度应该是N个64字节，等于N个分组。
为什么？你可以想象，sha1程序再对（salt+“填充数据”+“任意可控数据”）进行hash时，只需要进行第二轮及第二轮以后的运算。因为第一轮运算后的registers值就是sha1(salt)的值，该值你已经知道了。
什么？？还是不懂？？你把上面的例子中的“123456789abcdefgreport.pdf”想成是salt,然后再考虑下呢？
http://www.freebuf.com/articles/web/69264.html
貌似大多数渗透师都很少测试密码学方面的漏洞。我一直都对密码学颇有兴趣，于是决定研究web应用开发者误用加密算法的情况，以及如何利用这些漏洞。
一月份的时候，我研究了下对于一些比较弱的Message Authentication codes（MACs）[译者注：关于MAC与hash的区别参见此链接]，如何进行哈希长度扩展（hash length extension）攻击。我发现一些很不错的论文和博文，谈到了这种攻击方式。然而，针对哈希长度扩展攻击的具体细节，却鲜有资料。在这篇文章中，我将会对此进行详细解释。
Message Authentication Codes 101
Message authentication codes (MACs)是用于验证信息真实性的。最简单的MAC算法是这样的：服务器把key和message连接到一起，然后用摘要算法如MD5或SHA1取摘要。例如，假设有一个网站，在用户下载文件之前需验证下载权限。这个网站会用如下的算法产生一个关于文件名的MAC：
def create_mac(key, fileName)
return Digest::SHA1.hexdigest(key + fileName)
End最终产生的URL会是这样：
http://example.com/download?file=report.pdf&mac=563162c9c71a17367d44c165b84b85ab59d036f9当用户发起请求要下载一个文件时，将会执行下面这个函数：
def verify_mac(key, fileName, userMac)
validMac = create_mac(key, filename)
if (validMac == userMac) do
initiateDownload()
else
displayError()
end
End这样，只有当用户没有擅自更改文件名时服务器才会执行initiateDownload()开始下载。实际上，这种生成MAC的方式，给攻击者在文件名后添加自定义字串留下可乘之机。
Length Extension Attacks, The Simple
Explanation
哈希摘要算法，如MD5,SHA1, SHA2等，都是基于Merkle–Damgård结构。这类算法有一个很有意思的问题：如果你知道message和MAC，只需再知道key的长度，尽管不知道key的值，也能在message后面添加信息并计算出相应MAC。
Example: message + padding +extension
继续用上面的例子，对文件下载的功能进行长度扩展攻击：
http://example.com/download?file=report.pdf%80%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%A8/../../../../../../../etc/passwd&mac=ee40aa8ec0cfafb7e2ec4de20943b673968857a5Length Extensions In Depth
为了理解这种攻击方式，你必须先了解hash函数的内部原理。
How Hash Algorithms Work
哈希函数以区块为单位操作数据。比如说，MD5, SHA1, SHA256的区块长度是512 bits 。大多数message的长度不会刚好可以被哈希函数的区块长度整除。这样一来，message就必须被填充(padding)至区块长度的整数倍。用前面文件下载的MAC的例子来说，填充后的message是这样的（‘x'表示key）：
xxxxxxxxxxxreport.pdf\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xA8在本例所用的SHA1算法中，哈希值由五组整数构成。一般我们看到的形式是把这五个整数转换为16进制然后连接到一起。运行算法时，初始值（又叫registers）被设置为这组数：67452301, EFCDAB89,
98BADCFE, 10325476, C3D2E1F0. 紧接着，填充message，再将其分割为512bits的区块。算*流操作每个区块，进行一系列的计算并更新registers的值。一旦完成了这些运算，registers里的值就是最终的哈希值。
Calculating An Extension
计算扩展值得第一步是创建一个新的MAC。我们首先对待扩展的值：上例中的‘/../../../../../../../etc/passwd’进行哈希摘要。但是，在进行摘要之前，我们要把registers里的初始值设置为原始message的MAC。你可以将其想象为让SHA1函数从服务器上的函数运行结束的地方继续进行。
攻击者的 MAC = SHA1(extension + padding) <- 覆盖registers初始值
这个攻击有个前提，在传入服务器的哈希函数时，扩展值必须存在于单独的区块中。所以我们的第二步，就是计算出一个填充值使得 key + message + padding == 512 bits 的整数倍。在此例中，key是11个字符的长度。因此填充之后的message是这样的：
report.pdf\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xA8传送到服务器的填充及扩展之后的message以及新的MAC：
http://example.com/download?file=report.pdf%80%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%00%A8/../../../../../../../etc/passwd&mac=ee40aa8ec0cfafb7e2ec4de20943b673968857a5服务器要进行摘要运算的被攻击者篡改过的message如下：
secret + message + padding to the next block +
extension + padding to the end of that block.服务器算出的哈希值将是ee40aa8ec0cfafb7e2ec4de20943b673968857a5，正好与我们添加扩展字串并覆盖registers初始值所计算出来的一样。这是因为攻击者的哈希计算过程，相当于从服务器计算过程的一半紧接着进行下去。
How To Run The Attack
为了简单，在这个例子中我透露了**长度是11位。在现实攻击环境中，攻击者无法获知**长度，需要对其长度进行猜测。
继续之前的例子，假设当MAC验证失败时，这个存在漏洞的网站会返回一个错误信息（HTTP response code 或者response body中的错误消息之类）。当验证成功，但是文件不存在时，也会返回一个错误信息。如果这两个错误信息是不一样的，攻击者就可以计算不同的扩展值，每个对应着不同的**长度，然后分别发送给服务器。当服务器返回表明文件不存在的错误信息时，即说明存在长度扩展攻击，攻击者可以随意计算新的扩展值以下载服务器上未经许可的敏感文件。
How To Defend Against This Attack
解决这个漏洞的办法是使用HMAC算法。该算法大概来说是这样 ：MAC =
hash(key + hash(key + message))，而不是简单的对**连接message之后的值进行哈希摘要。
具体HMAC的工作原理有些复杂，但你可以有个大概的了解。重点是，由于这种算法进行了双重摘要，**不再受本文中的长度扩展攻击影响。HMAC最先是在1996年被发表，之后几乎被添加到每一种编程语言的标准函数库中。
Summary
尽管仍有一些疯狂的人类在写自己的加密算法，绝大多数人已经渐渐发现自己写加密算法不是什么好主意。然而，不单纯的套用公开的加密算法也是有其意义的，前提是你能够正确的使用这些加密算法。除非你彻底吃透你使用的加密算法的原理，并懂得如何正确使用，否则还是直接用那些经过了专业级审查的高级算法库要安全些。
[via: whitehatsec translate by: Ettack]