分享

科普:哈希长度扩展攻击浅析

 JP_Morgen 2014-05-18

  貌似大多数渗透师都很少测试密码学方面的漏洞。我一直都对密码学颇有兴趣,于是决定研究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:///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–Damgrd结构。这类算法有一个很有意思的问题:如果你知道message和MAC,只需再知道key的长度,尽管不知道key的值,也能在message后面添加信息并计算出相应MAC。

  Example: message + padding +extension

  继续用上面的例子,对文件下载的功能进行长度扩展攻击:

  http:///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

  Length 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:///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

  尽管仍有一些疯狂的人类在写自己的加密算法,绝大多数人已经渐渐发现自己写加密算法不是什么好主意。然而,不单纯的套用公开的加密算法也是有其意义的,前提是你能够正确的使用这些加密算法。除非你彻底吃透你使用的加密算法的原理,并懂得如何正确使用,否则还是直接用那些经过了专业级审查的高级算法库要安全些。

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多