Positive Technologies 的网络安全研究员 Arseniy Sharoglazov 近日在社交平台分享了一个简单的实验并指出,加密的 ZIP 文件可能存在两个正确的密码,并且都可以提取出相同的结果。

“创建 ZIP:7z a http://x.zip/etc/passwd -mem=AES256 -p
使用这个密码:Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You

提取它:7z e http://x.zip
使用这个密码:pkH8a0AqNbHcdw8GrmSp

Magic!”

Sharoglazov 制作了一个名为 x.zip 的受密码保护的 ZIP 文件,选择的密码是 1987 年的热门英文歌曲的双关语:

Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You

但实验结果表明,当他使用一个完全不同的密码(pkH8a0AqNbHcdw8GrmSp)提取 x.zip 时,不会收到任何的报错信息。

对此,BleepingComputer 使用不同的 ZIP 程序成功地对该实验进行了复现。该网站使用了 p7zip(相当于 macOS 的 7-Zip)和另一个叫 Keka 的 ZIP 工具,与 Sharoglazov 一样在创建时采用了较长的密码,并启用了 AES-256 加密模式。结果表明,虽然 ZIP 使用较长的密码加密,但使用任一密码都能成功提取了存档。

一些网友在 Sharoglazov 的动态下针对该实验进行了讨论,一位 ID 为 Unblvr 的用户指出,造成这个结果的原因可能在于:

ZIP 使用 PBKDF2,如果输入太大,它会 hash 输入 。该 hash(作为原始字节)成为实际密码。尝试使用 SHA1 对第一个密码进行 hash,并将十六进制摘要解码为 ASCII… :)

在启用 AES-256 模式生成受密码保护的 ZIP 存档时 ,如果密码太长,ZIP 格式会使用 PBKDF2 算法并对用户提供的密码进行 hash 处理。在这种情况下,这个新计算的 hash 将会成为文件的实际密码。研究人员解释称,太长是指超过 64 个字节(字符)。

当用户试图提取文件,并输入一个超过 64 字节的密码时,用户的输入将再次由 ZIP 应用程序进行 hash,并与正确的比较密码(现在本身就是一个 hash)。如果匹配,将可以成功进行文件提取。

示例中使用的替代密码 pkH8a0AqNbHcdw8GrmSp 实际上是较长密码 SHA-1 hash 的 ASCII 表示。Nev1r-G0nna-G2ve-… 的 SHA-1 checksum = 706b4838613041714e62486364773847726d5370。此校验和在转换为 ASCII 时产生:pkH8a0AqNbHcdw8GrmSp。

但是值得注意的是,在加密或解密文件时,仅当密码长度大于 64 个字符时才会进行 hash 处理。换句话说,较短的密码在压缩或解压缩 ZIP 的任何阶段都不会出现这种情况。这也是为什么在加密阶段选择长的 “Nev1r-G0nna-G2ve-…” 字符串作为密码时,ZIP 程序设置的实际密码实际上是该字符串的 (SHA1) hash。

如果在解密阶段输入 Nev1r-G0nna-G2ve-…,它将被 hash 并与之前存储的密码(即 SHA1 hash)进行比较。但是,在解密阶段输入较短的 “pkH8a0AqNbHcdw8GrmSp” 密码将使应用程序直接将此值与存储的密码(也就是 SHA1 hash)进行比较。更多的技术见解可参见 Wikipedia 上 PBKDF2 的 HMAC collisions 小节。

“当使用 HMAC 作为其伪随机函数时,PBKDF2 有一个有趣的特性。可以轻松地构造任意数量的不同密码对,每对密码对都存在冲突。如果提供的密码长于底层 HMAC hash function 的块大小,则首先要将密码 pre-hashed 成一个 digest,然后将该 digest 作为密码使用。”

不过,同一个 ZIP 有两个可能的密码这一事实并不代表存在有安全漏洞;因为生成密码的 hash 的前提是需要知道原始密码。

发表回复

后才能评论