☰

SHA256 falsch oder Apt defekt auf neuer Kali VM

tag-icon • tag-icon apt kali-linux virtualbox
SHA256 falsch oder Apt defekt auf neuer Kali VM

Gestern habe ich eine neue Kali-Gast-VM in VirtualBox eingerichtet und hatte während der Installation einige Probleme. Beim Schritt der Installation von Softwarepaketen schlug die Installation fehl, also habe ich nach einigen Versuchen beschlossen, diesen Schritt zu überspringen. Der Rest der Installation wurde ohne Probleme abgeschlossen.

Nachdem die Installation abgeschlossen war, versuchte ich herauszufinden, welche Pakete fehlten. Das erste Problem, auf das ich stieß, war, Apt zum Laufen zu bringen. Apt Update und Install schlugen immer fehl, also reinigte ich /var/lib/apt und versuchte, die Repo-Mirrors zu wechseln, aber nichts half. Der spezifische Fehler, den ich beim Ausführen von Apt Update erhalte, ist:

Bildbeschreibung hier eingeben

Dann fiel mir auf, dass die SHA-Prüfsummen nicht übereinstimmen, die MD5-Summe jedoch schon. Meine Arbeitshypothese ist also, dass mit den Downloads oder Repos alles in Ordnung ist, mein System falsche Prüfsummen erzeugt und Apt deshalb immer abstürzt.

An diesem Punkt sollte ich die VM wahrscheinlich löschen und das System neu installieren, aber ich möchte dies lieber als Lernerfahrung nutzen und das Problem beheben. Ich hoffe also auf Vorschläge, was ich als nächstes tun soll.

Bearbeitenals Antwort auf @Gilles „Also, hör auf, böse zu sein“, tolle Antwort.

Ich habe versucht zu überprüfen, ob die Datei Packages.gz nicht mit den Metadaten in InRelease synchronisiert ist.

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

Soweit ich das beurteilen kann, wird die Datei Packages.gz korrekt heruntergeladen und die tatsächlichen Hashes stimmen mit den Erwartungen aus der InRelease-Datei überein. Aber apt meldet immer noch falsche Hashes.

Bearbeitung 2:

Nach einigem Herumprobieren habe ich Apt schließlich in einen funktionierenden Zustand gebracht, indem ich Apt manuell auf Version 1.8.4 heruntergestuft habe (die ursprüngliche Version war 2.0.2). Das Problem ist reproduzierbar, wenn ich apt upgrade2.0.2 installiere, tritt es wieder auf.

Antwort1

Das Kali-Paketarchiv befindet sich derzeit in einem inkonsistenten Zustand. Sie können nichts dagegen tun.

Es ist sehr unwahrscheinlich, dass Ihr System falsche Prüfsummen erzeugt. Dafür gibt es mehrere Gründe, aber keiner davon ist plausibel.

  • Die Software, die die Prüfsumme selbst berechnet, könnte fehlerhaft sein. Das ist äußerst unwahrscheinlich: Die Berechnung der Prüfsummen ist einfach und der Code dafür ist sehr stabil und leicht zu testen.
  • Die Software, die die Dateien herunterlädt, speichert, überprüft usw., könnte fehlerhaft sein. Es ist sehr unwahrscheinlich, dass sie so fehlerhaft ist, dass sie falsche Prüfsummen berechnet, anstatt einen Fehler auszugeben.
  • Die Software lädt möglicherweise die falschen Dateien herunter, kürzt sie oder verschlüsselt sie auf eine Weise, die nicht erkannt wird. Dies ist der am wenigsten unwahrscheinliche Punkt hier.
  • Ihr System könnte so manipuliert sein, dass es falsche Prüfsummen berechnet. Das ist unwahrscheinlich, denn ein Angreifer, der dazu in der Lage ist, kann auf weniger auffällige Weise weitaus nützlichere Dinge tun.

Es ist etwas weniger unwahrscheinlich, dass Ihr Netzwerk angegriffen wird und ein Angreifer die Dateien, die Sie herunterladen, aktiv manipuliert. Es ist immer noch unwahrscheinlich, da der Angreifer aufgrund der kryptografischen Prüfungen, die apt durchführt, weiß, dass der Angriff erkannt und wirkungslos wäre (ich erkläre diese Prüfungen weiter unten). Der Angriff wäre nur gegen einen Benutzer nützlich, der den Fehler ignoriert oder .debDateien manuell herunterlädt und sie mit installiert dpkg.

Unwahrscheinlich heißt natürlich nicht unmöglich. Sie können überprüfen, ob dies alles passiert, indem Sie die Dateien herunterladen und ihre Prüfsumme auf einem anderen, zweifelsohne einwandfrei funktionierenden System berechnen. Ich habe das getan und die erwarteten und tatsächlichen Prüfsummenwerte sind identisch.

Die Beschädigung könnte in einem Spiegel sein, also habe ich einen anderen Spiegel verwendet (https://http.kali.org/dists/kali-rolling/). Die InReleaseDatei enthält die erwarteten Prüfsummen und Packages.gzist die Datei, deren Prüfsummen überprüft werden.

$ 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

Wie Sie sehen, sind die erwarteten und tatsächlichen Prüfsummen unterschiedlich. Die erwarteten und tatsächlichen Größen sind ebenfalls unterschiedlich. Ich habe eine andere, ältere Version als Packages.gzSie, obwohl ich sie erst vor kurzem heruntergeladen habe, aber von einem anderen Spiegel.

Ich habe die Dateien auch heruntergeladen vonder gleiche Spiegel wie duund dort hatten die Dateien die erwarteten Prüfsummen, sodass das Problem auf diesem Spiegel behoben ist. Es sieht aus wie ein vorübergehender Fehler und die Lösung wurde noch nicht vollständig verbreitet.

Ich weiß nicht, was das Problem verursacht hat. Es könnte sich um einen Angriffsversuch handeln (aber wenn ja, scheint er fehlgeschlagen zu sein, da nicht alle Dateien, die beschädigt werden mussten, beschädigt wurden). Wahrscheinlicher war ein Synchronisierungsfehler irgendwo innerhalb der Kali-Infrastruktur.

Ich weiß nicht, warum Sie einen übereinstimmenden MD5-Wert sehen. Entweder InReleaseenthält die von Ihnen heruntergeladene Datei inkonsistente Daten oder apt macht sich nicht einmal die Mühe, den MD5-Wert zu berechnen, weil er als schwach gilt.

Wie versprochen stellt apt die Sicherheit von Downloads folgendermaßen sicher. Die folgende kryptografische Infrastruktur generiert die Daten, die die Echtheit der Pakete garantieren:

  • Ein Build-Server berechnet diekryptografischer Hash¹ jedes Pakets ( .deboder jeder Datei eines Quellpakets).
  • Ein Hashing-Server erstellt die Paketliste ( Packagesund eine komprimierte Version Packages.gz) aus den vom Build-Server für jeden Teil der Distribution gesendeten Hashes und generiert eine ReleaseDatei, die die Hashes der PackagesDateien enthält.
  • Ein Signaturserver, der über einePGPprivater Schlüssel, generiert einekryptografische Signaturder ReleaseDatei und speichert sie in Release.gpg. Es gibt auch eine Datei InRelease, die sowohl die Daten als auch die Signatur in derselben Datei enthält.

Auf Ihrem System:

  • Ihr anfängliches Installationsimage enthält den öffentlichen PGP-Schlüssel für den privaten Schlüssel des Build-Servers sowie alle erforderlichen Tools zum Überprüfen, ob eine Datei korrekt mit diesem Schlüssel signiert ist.
  • Wenn apt die Paketliste herunterlädt, lädt es die InReleaseDatei (oder vielleicht Releaseund Release.gpg) herunter und überprüft, ob sie richtig signiert ist. Es überprüft auch, ob die kryptografischen Hashes der PackageDateien mit dem Wert in der InReleaseDatei übereinstimmen.
  • Wenn apt ein Paket herunterlädt, überprüft es, ob die Hashes der Paketdatei mit den Werten in der PackagesDatei übereinstimmen.

Dies ist ausreichend, weil:

  • Niemand weiß, wie man eine Datei mit demselben kryptografischen Hash wie eine andere vorhandene Datei erstellt. (Dies gilt sogar für MD5 und SHA-1, bei denen wir wissen, wie man eine Kollision herstellt, d. h. wie man zwei Dateien mit demselben Hash erstellt, aber nicht, wie man ein zweites Urbild berechnet, d. h. wie man eine andere Datei findet, deren Hash mit dem einer bestimmten Datei identisch ist.)
  • Niemand weiß, wie man eine gültige PGP-Signatur generiert, ohne über den privaten Schlüssel zu verfügen.

Das ist alles. Beachten Sie, dass es keine Rolle spielt, wie die Dateien zwischen der Kali-Infrastruktur und dem Download-Mirror oder zwischen dem Download-Mirror und Ihrem System übertragen wurden. Die Verwendung von TLS für diese ist eine Sicherheitsverbesserung, da es einen Netzwerkangreifer daran hindert, veraltete Dateien bereitzustellen (z. B. vorzutäuschen, dass ein Sicherheitsupdate für eine kritische Software nie erfolgt ist, indem echte, aber veraltete Pakete mit der entsprechenden veralteten Version der ReleaseDatei und ihrer Signatur bereitgestellt werden).

Die einzige Möglichkeit, wie etwas unentdeckt bleiben kann, besteht innerhalb der Kali-Infrastruktur: wenn der Signaturschlüssel kompromittiert ist oder wenn die Build-Server die falschen Hashes melden.

¹ In diesem Kontext sind „(kryptografische) Prüfsumme“, „(kryptografischer) Hash“ und „(kryptografischer) Digest“ Synonyme. Es gibt auch nicht-kryptografische Prüfsummen und Hashes, die hier aber nicht relevant sind.

Antwort2

Diese Antwort setzt einen Windows 10-Host voraus.

Ich bin auf den scheinbar gleichen „Hash Sum mismatch“-Fehler bei „Packages.gz“ gestoßen, während ich bei einem der 2020-2 amd-64 ISOs auf VirtualBox den Schritt „Installieren des Basissystems“ ausgeführt habe. Ich habe auch die Kali 2020-2 amd-64 VirtualBox OVA gebootet und beim Versuch, eine zu installieren, den gleichen Fehler erhalten apt-get update. Das Problem scheint für mich gelöst worden zu sein, indem ich die Funktion „Windows Defender Credential Guard“ deaktiviert habe, die auch als „Device Guard“ oder „Virtualization Based Security“ bekannt ist.

Verwalten von Windows Defender Credential Guard

Windows Defender Credential Guard wurde in Windows 10 Enterprise und Windows Server 2016 eingeführt und verwendet virtualisierungsbasierte Sicherheit, um Geheimnisse zu isolieren, sodass nur privilegierte Systemsoftware darauf zugreifen kann. Unbefugter Zugriff auf diese Geheimnisse kann zu Angriffen zum Diebstahl von Anmeldeinformationen führen, z. B. Pass-the-Hash oder Pass-The-Ticket. Windows Defender Credential Guard verhindert diese Angriffe, indem es NTLM-Kennworthashes, Kerberos Ticket Granting Tickets und von Anwendungen als Domänenanmeldeinformationen gespeicherte Anmeldeinformationen schützt. Referenzlink

Es gibt mehrere Methoden, diese Funktion zu deaktivieren, wie im Link erklärt. Ich habe das „Windows Defender Credential Guard Hardware Readiness Tool“ verwendet, verfügbarHier.

DG_Readiness_Tool_v3.6.ps1 -Disable -AutoReboot

Antwort3

Deaktivieren von Hyper-V

Das Deaktivieren von Hyper-V hat bei mir funktioniert.

Prodieser Kommentarhabe ich die Ressourcen gefunden, die ich genau dafür brauchte.

  1. Öffnen Sie eine Eingabeaufforderung mit erhöhten Rechten
  2. Führen Sie die Aktion aus bcdeditund überprüfen Sie die Einstellung für hypervisorlaunchtypeunter{current}
  3. Laufenbcdedit /set {current} hypervisorlaunchtype off
  4. Neustart

Nachdem ich dies getan habe, sehe ich die „grüne Schildkröte“ nicht mehr in der Statusleiste des Gastes.

Um es wieder einzuschalten, führen Sie den Vorgang wie oben beschrieben mit diesem alternativen Schritt 3 aus:

  1. Laufenbcdedit /set {current} hypervisorlaunchtype auto

https://www.tenforums.com/tutorials/139405-run-hyper-v-virtualbox-vmware-same-computer.html#Part1

Notiz:

Mir ist aufgefallen, dass Docker für Windows Hyper-V verwendet. Daher ist es möglich, dass das Herunterfahren von Docker die VBox-Probleme behebt, wenn Sie Docker verwenden.

verwandte Informationen