昨天我在 VirtualBox 中设置一个新的 Kali 来宾虚拟机,在安装过程中遇到了一些问题。在安装软件包的步骤中会安装失败,所以重试几次后我决定跳过这一步。其余的安装完成,没有任何问题。
安装完成后,我开始尝试找出缺少哪些软件包。我遇到的第一个障碍是如何适应工作。 apt 更新和安装总是失败,所以我清理了 /var/lib/apt 并尝试切换 repo 镜像,但没有任何帮助。运行 apt update 时出现的具体错误是:
然后我注意到 SHA 校验和不匹配,但 MD5Sum 实际上匹配。所以我的工作假设是下载或存储库没有任何问题,我的系统生成错误的校验和,这就是 apt 总是失败的原因。
此时,我可能应该对虚拟机进行核攻击并重新安装系统,但我宁愿将此作为学习经验并解决问题。所以我希望得到关于下一步该做什么的建议。
编辑回应@Gilles“所以-停止邪恶”很好的答案。
我尝试验证 Packages.gz 文件是否与 InRelease 中的元数据不同步。
root@kali:/var/lib/apt/lists/partial# rm *
root@kali:/var/lib/apt/lists/partial# apt update
Get:1 http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling InRelease [30.5 kB]
Get:2 http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling/main amd64 Packages [16.3 MB]
Err:2 http://ftp.acc.umu.se/mirror/kali.org/kali kali-rolling/main amd64 Packages
Hash Sum mismatch
Hashes of expected file:
- Filesize:16317378 [weak]
- SHA256:77a3e22e7b5ea34fca2d74d79a9d46f4bb27af0dfb56d6052e2d288b3c684d98
- SHA1:f5b21d796c25dc10d382ffedc1ce4d7bee376057 [weak]
- MD5Sum:257a18dc4dff52c27f94f6e66a5a82bf [weak]
Hashes of received file:
- SHA256:5d1d8ffe97ff7a35ce5537925d7790967b086c75dadd5576688c915830bf0c84
- SHA1:ce0617edf0193841072c1cba00b6797d2b3dd0eb [weak]
- MD5Sum:257a18dc4dff52c27f94f6e66a5a82bf [weak]
- Filesize:16317378 [weak]
Last modification reported: Fri, 03 Apr 2020 15:48:14 +0000
Release file created at: Fri, 03 Apr 2020 15:48:24 +0000
Fetched 16.3 MB in 5s (3368 kB/s)
Failed to fetch http://ftp.acc.umu.se/mirror/kali.org/kali/dists/kali-rolling/main/binary-amd64/Packages.gz
Hash Sum mismatch
Hashes of expected file:
- Filesize:16317378 [weak]
- SHA256:77a3e22e7b5ea34fca2d74d79a9d46f4bb27af0dfb56d6052e2d288b3c684d98
- SHA1:f5b21d796c25dc10d382ffedc1ce4d7bee376057 [weak]
- MD5Sum:257a18dc4dff52c27f94f6e66a5a82bf [weak]
Hashes of received file:
- SHA256:5d1d8ffe97ff7a35ce5537925d7790967b086c75dadd5576688c915830bf0c84
- SHA1:ce0617edf0193841072c1cba00b6797d2b3dd0eb [weak]
- MD5Sum:257a18dc4dff52c27f94f6e66a5a82bf [weak]
- Filesize:16317378 [weak]
Last modification reported: Fri, 03 Apr 2020 15:48:14 +0000
Release file created at: Fri, 03 Apr 2020 15:48:24 +0000[0m
Some index files failed to download. They have been ignored, or old ones used instead.[0m
root@kali:/var/lib/apt/lists/partial# ls
ftp.acc.umu.se_mirror_kali.org_kali_dists_kali-rolling_InRelease
ftp.acc.umu.se_mirror_kali.org_kali_dists_kali-rolling_main_binary-amd64_Packages.gz.FAILED
root@kali:/var/lib/apt/lists/partial# md5sum ftp.acc.umu.se_mirror_kali.org_kali_dists_kali-rolling_ main_binary-amd64_Packages.gz.FAILED
257a18dc4dff52c27f94f6e66a5a82bf ftp.acc.umu.se_mirror_kali.org_kali_dists_kali-rolling_main_binary-amd64_Packages.gz.FAILED
root@kali:/var/lib/apt/lists/partial# sha1sum ftp.acc.umu.se_mirror_kali.org_kali_dists_kali-rollingg_main_binary-amd64_Packages.gz.FAILED
f5b21d796c25dc10d382ffedc1ce4d7bee376057 ftp.acc.umu.se_mirror_kali.org_kali_dists_kali-rolling_main_binary-amd64_Packages.gz.FAILED
root@kali:/var/lib/apt/lists/partial# sha256sum ftp.acc.umu.se_mirror_kali.org_kali_dists_kali-rollinng_main_binary-amd64_Packages.gz.FAILED
77a3e22e7b5ea34fca2d74d79a9d46f4bb27af0dfb56d6052e2d288b3c684d98 ftp.acc.umu.se_mirror_kali.org_kali_dists_kali-rolling_main_binary-amd64_Packages.gz.FAILED
据我所知,Packages.gz 文件已正确下载,并且实际哈希值确实与 InRelease 文件中的预期相符。但 apt 仍然报告错误的哈希值。
编辑2:
因此,经过一番折腾后,我终于通过手动降级 apt 到版本 1.8.4(原始版本是 2.0.2)进入了工作状态。该问题是可重现的,运行apt upgrade
安装 2.0.2 后问题再次出现。
答案1
Kali 包存档当前处于不一致状态。你对此无能为力。
您的系统不太可能产生错误的校验和。发生这种情况的原因有多种,但没有一个是合理的。
- 计算校验和的软件本身可能存在错误。这是极不可能的:计算校验和很容易,并且执行此操作的代码非常稳定且易于测试。
- 下载文件、存储文件、验证文件等的软件可能存在错误。它不太可能出现错误,以至于计算出错误的校验和,而不是出错。
- 该软件可能会下载错误的文件,或者截断它们,或者以未被捕获的方式对它们进行编码。这是这里最不令人难以置信的要点。
- 您的系统可能会受到损害,从而计算出错误的校验和。这是难以置信的,因为能够做到这一点的攻击者可以以不那么引人注目的方式做更有用的事情。
您的网络受到攻击的可能性较小,并且攻击者正在主动操纵您正在下载的文件。这仍然不太可能,因为攻击者知道由于 apt 进行的加密检查,攻击会被检测到并且无效(我将在下面解释这些检查)。该攻击仅对那些安排忽略错误或手动下载.deb
文件并使用dpkg
.
当然,不太可能并不意味着不可能。您可以通过下载文件并在另一个已知良好的系统上计算其校验和来验证这一切都没有发生。我这样做了,并得到了相同的预期和实际校验和值。
损坏可能发生在一个镜像中,所以我使用了另一个镜像(https://http.kali.org/dists/kali-rolling/)。该InRelease
文件包含预期的校验和,并且Packages.gz
是校验和经过验证的文件。
$ wget -q https://http.kali.org/dists/kali-rolling/InRelease https://http.kali.org/dists/kali-rolling/main/binary-arm64/Packages.gz
$ TZ=UTC \ls -log InRelease Packages.gz
-rw-rw-r-- 1 30501 Apr 3 15:48 InRelease
-rw-rw-r-- 1 30501 Apr 3 15:48 InRelease
-rw-rw-r-- 1 16179052 Apr 3 12:04 Packages.gz
$ md5sum Packages.gz
31a332531ecf9d092aaad9a3f4885767 Packages.gz
$ sha1sum Packages.gz
138883655ff0d58a3779acbeda0d61f7552c03eb Packages.gz
$ sha256sum Packages.gz
63ae17c54bc57dc445ba4a3555bec3fa077c5de6eec0b11363680efc23fd09ec Packages.gz
$ grep main/binary-amd64/Packages.gz InRelease
257a18dc4dff52c27f94f6e66a5a82bf 16317378 main/binary-amd64/Packages.gz
f5b21d796c25dc10d382ffedc1ce4d7bee376057 16317378 main/binary-amd64/Packages.g
77a3e22e7b5ea34fca2d74d79a9d46f4bb27af0dfb56d6052e2d288b3c684d98 16317378 main/binary-amd64/Packages.gz
正如您所看到的,预期的校验和与实际的校验和是不同的。预期尺寸和实际尺寸也不同。我有一个与你不同的旧版本Packages.gz
,尽管我最近下载的,但来自不同的镜像。
我还从以下位置下载了文件和你一样的镜子文件具有预期的校验和,因此该镜像上的问题已得到修复。它看起来像是一个临时错误,修复尚未完全传播。
我不知道是什么导致了这个问题。这可能是一次攻击尝试(但如果是这样,它似乎已经失败,因为并非所有需要损坏的文件都已损坏)。更有可能的是,这是 Kali 基础设施内部某个地方的同步失败。
我不知道为什么你会看到匹配的 MD5。您下载的文件InRelease
的数据不一致,或者 apt 甚至懒得计算 MD5,因为它被认为是弱的。
正如所承诺的,以下是 apt 如何确保下载的安全性。以下加密基础设施生成保证包裹真实性的数据:
- 构建服务器计算加密哈希每个包的 ¹(
.deb
或源包的文件)。 - 哈希服务器根据构建服务器为分发的每个部分发送的哈希值构建包列表(
Packages
和压缩版本),并生成包含文件哈希值的文件。Packages.gz
Release
Packages
- 签名服务器,其中有前列腺素私钥,生成一个加密签名文件
Release
并将其存储在Release.gpg
.还有一个文件InRelease
在同一文件中包含数据和签名。
在您的系统上:
- 您的初始安装映像包含构建服务器私钥的 PGP 公钥,以及验证文件是否已使用此密钥正确签名所需的所有工具。
- 当 apt 下载软件包列表时,它会下载
InRelease
文件(或者可能是Release
和Release.gpg
)并验证它是否已正确签名。它还验证文件的加密哈希值是否与文件Package
中的值匹配InRelease
。 - 当 apt 下载软件包时,它会验证软件包文件的哈希值是否与
Packages
文件中的值匹配。
这已经足够了,因为:
- 没有人知道如何创建一个与另一个现有文件具有相同加密哈希的文件。 (即使对于 MD5 和 SHA-1 也是如此,我们知道如何产生冲突,即如何使两个文件具有相同的哈希值,但不知道如何计算第二个原像,即找到另一个哈希值为与给定文件相同。)
- 没有人知道如何在没有私钥的情况下生成有效的 PGP 签名。
就是这样。请注意,文件如何在 Kali 基础设施和下载镜像之间或下载镜像和您的系统之间传输并不重要。对这些使用 TLS 是一种安全改进,因为它可以防止网络攻击者提供过时的文件(例如,通过提供具有相应过时版本的正版但过时的软件包来假装关键软件从未发生过安全更新)Release
文件及其签名)。
唯一不被检测到的情况是在 Kali 基础设施内部:如果签名密钥被泄露,或者构建服务器报告错误的哈希值。
1在这种情况下,“(加密)校验和”、“(加密)哈希”和“(加密)摘要”是同义词。有非加密校验和和哈希值,但这里不涉及它们。
答案2
此答案假设 Windows 10 主机。
在 VirtualBox 上任何 2020-2 amd-64 ISO 的“安装基本系统”步骤中,我在“Packages.gz”上遇到了似乎相同的“哈希和不匹配”错误。我还启动了 Kali 2020-2 amd-64 VirtualBox OVA,并在尝试apt-get update
.通过禁用“Windows Defender Credential Guard”功能(也称为“Device Guard”或“基于虚拟化的安全性”),我似乎已经解决了这个问题。
管理 Windows Defender Credential Guard
Windows Defender Credential Guard 在 Windows 10 企业版和 Windows Server 2016 中引入,使用基于虚拟化的安全性来隔离机密,以便只有特权系统软件才能访问它们。未经授权访问这些机密可能会导致凭证盗窃攻击,例如“哈希传递”或“票证传递”。 Windows Defender Credential Guard 通过保护 NTLM 密码哈希、Kerberos 票证授予票证以及应用程序存储为域凭据的凭据来防止这些攻击。 参考链接
有多种方法可以禁用此功能,如链接中所述。我使用了“Windows Defender Credential Guard 硬件准备工具”,可用这里。
DG_Readiness_Tool_v3.6.ps1 -Disable -AutoReboot
答案3
禁用 Hyper-V
禁用 Hyper-V 对我有用。
每这条评论,我找到了做到这一点所需的资源。
- 打开提升的 cmd 提示符
- 运行并检查下的
bcdedit
设置hypervisorlaunchtype
{current}
- 跑步
bcdedit /set {current} hypervisorlaunchtype off
- 重启
这样做之后,我在客人的状态栏上就不再看到“绿海龟”了。
要重新打开它,请按照上述替代步骤 3 执行保存过程:
- 跑步
bcdedit /set {current} hypervisorlaunchtype auto
https://www.tenforums.com/tutorials/139405-run-hyper-v-virtualbox-vmware-same-computer.html#Part1
笔记:
我注意到 Docker For Windows 使用 Hyper-V,因此如果您使用 Docker,关闭 Docker 可能会解决 VBox 问题。