SHA256 неверен или может быть поврежден на новой виртуальной машине Kali

Архив пакетов 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] файлы.
• Подписывающий сервер, который имеет закрытый ключ PGP , генерирует криптографическую подпись файла Releaseи сохраняет ее в Release.gpg. Также есть файл InRelease, который содержит и данные, и подпись в одном файле.

В вашей системе:

• Ваш исходный установочный образ содержит открытый ключ PGP для закрытого ключа сервера сборки, а также все инструменты, необходимые для проверки правильности подписи файла этим ключом.
• Когда apt загружает список пакетов, он загружает InReleaseфайл (или, возможно, ReleaseиRelease.gpg)и проверяет правильность подписи. Он также проверяет, совпадают ли криптографические хэши файлов Packageсо значением в файле InRelease.
• Когда apt загружает пакет, он проверяет, совпадают ли хэши файла пакета со значениями в файле Packages.

Этого достаточно, потому что:

• Никто не знает, как создать файл с тем же криптографическим хешем, что и у другого существующего файла. (Это справедливо даже для MD5 и SHA -1, для которых мы знаем, как сделать коллизию, т.е. как сделать два файла с одинаковым хешем, но не как вычислить второй прообраз, т.е. найти другой файл, хэш которого совпадает с данным файлом.)
• Никто не знает, как сгенерировать действительную подпись PGP, не имея закрытого ключа.

Вот именно. Обратите внимание, что не имеет значения, как файлы были переданы между инфраструктурой Kali и зеркалом загрузки или между зеркалом загрузки и вашей системой. Использование TLS для них является улучшением безопасности, поскольку оно не позволяет сетевому злоумышленнику обслуживать устаревшие файлы (, например, делать вид, что обновления безопасности для критической части программного обеспечения никогда не было, путем обслуживания подлинных, но устаревших пакетов с соответствующей устаревшей версией. файла Releaseи его подпись ).

Единственный способ остаться незамеченным — внутри инфраструктуры Kali :, если ключ подписи скомпрометирован или если серверы сборки сообщают о неправильных хэшах.

¹ _{В данном контексте «(криптографическая )контрольная сумма»,«(криптографический )хэш» и «(криптографический )дайджест» являются синонимами. Есть не -криптографические контрольные суммы и хэши, но они здесь не задействованы.}