☰

新しい Kali VM で SHA256 が間違っているか、apt が壊れている

tag-icon • tag-icon apt kali-linux virtualbox
新しい Kali VM で SHA256 が間違っているか、apt が壊れている

昨日、VirtualBox で新しい Kali ゲスト VM をセットアップしていたのですが、インストール中に問題が発生しました。ソフトウェア パッケージのインストール手順でインストールが失敗するため、数回再試行した後、その手順をスキップすることにしました。インストールの残りの部分は問題なく完了しました。

インストールが完了した後、どのパッケージが不足しているかを調べ始めました。最初に遭遇した問題は、apt を動作させることでした。apt update と install は常に失敗するため、/var/lib/apt をクリーンアップし、リポジトリ ミラーを切り替えてみましたが、何も役に立ちませんでした。apt update を実行したときに表示される具体的なエラーは次のとおりです。

ここに画像の説明を入力してください

その後、SHA チェックサムは一致しないが、MD5Sum は実際に一致することに気付きました。したがって、私の仮説は、ダウンロードやリポジトリに問題はなく、システムが間違ったチェックサムを生成しているため、apt が常に失敗するというものです。

この時点では、おそらく VM を削除してシステムを再インストールする必要がありますが、これを学習経験として活用して問題を解決したいと思います。そこで、次に何をすべきかについての提案を期待しています。

編集@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 を動作可能な状態にすることができました。問題は再現可能で、apt upgrade2.0.2 をインストールして実行すると、問題が再発します。

答え1

Kali パッケージ アーカイブは現在不整合な状態にあります。これについては何もできません。

システムが間違ったチェックサムを生成する可能性は非常に低いでしょう。これが発生する理由はいくつか考えられますが、どれも妥当ではありません。

  • チェックサムを計算するソフトウェア自体にバグがある可能性があります。これは極めてまれです。チェックサムの計算は簡単で、そのためのコードは非常に安定しており、テストも簡単です。
  • ファイルをダウンロードし、保存し、検証するソフトウェアにバグがある可能性があります。エラーが発生するのではなく、間違ったチェックサムを計算するようなバグがある可能性は非常に低いです。
  • ソフトウェアが間違ったファイルをダウンロードしたり、ファイルを切り捨てたり、検出されない方法でエンコードしたりしている可能性があります。これは、ここで最もあり得ない点ではありません。
  • システムが不正アクセスされ、間違ったチェックサムが計算される可能性があります。このような攻撃ができる攻撃者は、目立たない方法で、はるかに有用なことを実行できるため、これはあり得ないことです。

ネットワークが攻撃を受け、ダウンロード中のファイルを攻撃者が積極的に操作している可能性は、やや低くなります。それでも、攻撃者は、apt が行う暗号チェックによって攻撃が検出され、無効になることを知っているため、可能性は低くなります (これらのチェックについては、後で説明します)。この攻撃は、エラーを無視するように設定したり、手動で.debファイルをダウンロードして でインストールしたりするユーザーに対してのみ有効ですdpkg。

もちろん、あり得ないということは、あり得ないということではありません。ファイルをダウンロードし、別の正常なシステムでチェックサムを計算することで、このようなことが起きていないことを確認できます。私もそうしましたが、予想されたチェックサムと実際のチェックサムは同じ値でした。

破損は1つのミラーにある可能性があるので、別のミラーを使用しました（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ダウンロードしたファイルに矛盾したデータが含まれているか、MD5 が弱いと判断されたために apt が計算すら行っていないかのどちらかです。

約束どおり、apt がダウンロードのセキュリティを確保する方法は次のとおりです。次の暗号化インフラストラクチャは、パッケージが本物であることを保証するデータを生成します。

  • ビルドサーバーは、暗号ハッシュ各パッケージの ¹ ( .deb、またはソース パッケージの ファイル)。
  • ハッシュ サーバーは、ビルド サーバーから配布物の各部分に対して送信されたハッシュからパッケージ リスト ( Packages、および圧縮バージョン) を構築し、ファイルのハッシュを含むファイルを生成します。Packages.gzReleasePackages
  • 署名サーバーは、GPGP とは秘密鍵を生成する暗号署名ファイルの署名Releaseとそれを に保存します。データと署名の両方が同じファイルに含まれるRelease.gpgファイルもあります。InRelease

システム上:

  • 初期インストール イメージには、ビルド サーバーの秘密キーの PGP 公開キーと、このキーを使用してファイルが正しく署名されていることを検証するために必要なすべてのツールが含まれています。
  • apt はパッケージ リストをダウンロードするときに、InReleaseファイル (またはReleaseと) をダウンロードし、正しく署名されていることを確認します。また、ファイルの暗号化ハッシュがファイル内の値と一致するRelease.gpgことも確認します。PackageInRelease
  • apt はパッケージをダウンロードするときに、パッケージ ファイルのハッシュがファイル内の値と一致するかどうかを確認しますPackages。

これは次の理由で十分です:

  • 既存のファイルと同じ暗号ハッシュを持つファイルを作成する方法は誰にもわかりません。(これは MD5 や SHA-1 でも同様です。MD5 や SHA-1 では衝突を起こす方法、つまり同じハッシュを持つ 2 つのファイルを作成する方法はわかっていますが、2 番目のプリイメージを計算する方法、つまり特定のファイルと同じハッシュを持つ別のファイルを見つける方法はわかっていません。)
  • 秘密鍵なしで有効な PGP 署名を生成する方法は誰にもわかりません。

以上です。Kali インフラストラクチャとダウンロード ミラーの間、またはダウンロード ミラーとシステムの間でファイルがどのように転送されたかは関係ありません。これらの場合に TLS を使用すると、ネットワーク攻撃者が古いファイルを提供することができなくなるため、セキュリティが向上します (たとえば、重要なソフトウェアのセキュリティ更新が行われなかったかのように装うために、正規の古いパッケージを対応する古いバージョンのファイルReleaseとその署名とともに提供することなど)。

何かが検出されない唯一の方法は、Kali インフラストラクチャ内で、署名キーが侵害された場合、またはビルド サーバーが間違ったハッシュを報告した場合です。

¹この文脈では、「(暗号) チェックサム」、「(暗号) ハッシュ」、および「(暗号) ダイジェスト」は同義語です。非暗号チェックサムとハッシュもありますが、ここでは関係ありません。

答え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」機能 (別名「デバイス ガード」または「仮想化ベースのセキュリティ」) を無効にすることで解決したようです。

Windows Defender Credential Guard を管理する

Windows 10 Enterprise および Windows Server 2016 で導入された Windows Defender Credential Guard は、仮想化ベースのセキュリティを使用してシークレットを分離し、特権を持つシステム ソフトウェアのみがアクセスできるようにします。これらのシークレットに不正にアクセスすると、Pass-the-Hash や Pass-The-Ticket などの資格情報の盗難攻撃が発生する可能性があります。Windows Defender Credential Guard は、NTLM パスワード ハッシュ、Kerberos チケット保証チケット、およびアプリケーションによってドメイン資格情報として保存された資格情報を保護することで、これらの攻撃を防ぎます。 参考リンク

この機能を無効にする方法はいくつかあり、リンクで説明されています。私は「Windows Defender Credential Guardハードウェア準備ツール」を使用しました。ここ。

DG_Readiness_Tool_v3.6.ps1 -Disable -AutoReboot

答え3

Hyper-V を無効にする

Hyper-V を無効にするとうまくいきました。

パーこのコメント、私はまさにそれを実行するために必要なリソースを見つけました。

  1. 管理者特権のコマンドプロンプトを開く
  2. 実行してbcdedit設定を確認してhypervisorlaunchtypeください{current}
  3. 走るbcdedit /set {current} hypervisorlaunchtype off
  4. リブート

これを実行すると、ゲストのステータス バーに「緑のカメ」が表示されなくなります。

再度オンにするには、次の代替手順 3 で上記と同じプロセスを実行します。

  1. 走る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 の問題が解決する可能性があります。

関連情報