科普:哈希长度扩展攻击

貌似大多数渗透师都很少测试密码学方面的漏洞。我一直都对密码学颇有兴趣,于是决定研究web应用开发者误用加密算法的情况,以及如何利用这些漏洞。

[[111558]]

一月份的时候,我研究了下对于一些比较弱的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=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://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

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

原文地址:https://blog.whitehatsec.com/hash-length-extension-attacks/

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/124473.html<

(0)
管理的头像管理
上一篇2025-02-23 07:18
下一篇 2025-02-23 07:19

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注