어제 VirtualBox에 새로운 Kali 게스트 VM을 설정하고 있었는데 설치 중에 몇 가지 문제가 발생했습니다. 소프트웨어 패키지를 설치하는 단계에서 설치가 실패하므로 몇 번 재시도한 후 해당 단계를 건너뛰기로 결정했습니다. 나머지 설치는 문제 없이 완료되었습니다.
설치가 완료된 후 어떤 패키지가 누락되었는지 알아보기 시작했습니다. 내가 겪은 첫 번째 장애는 일을 시작하는 것이었습니다. apt 업데이트 및 설치가 항상 실패하므로 /var/lib/apt를 정리하고 repo 미러 전환을 시도했지만 아무 도움이 되지 않았습니다. apt update를 실행할 때 발생하는 구체적인 오류는 다음과 같습니다.
그런 다음 SHA 체크섬은 일치하지 않지만 MD5Sum은 실제로 일치한다는 것을 알았습니다. 따라서 내 작업 가설은 다운로드나 저장소에 아무런 문제가 없으며 내 시스템이 잘못된 체크섬을 생성하므로 apt가 항상 실패한다는 것입니다.
이 시점에서는 아마도 VM을 핵으로 설정하고 시스템을 다시 설치해야 할 것입니다. 그러나 저는 이것을 학습 경험으로 사용하여 문제를 해결하고 싶습니다. 그래서 다음에 무엇을 해야할지에 대한 제안을 기대하고 있습니다.
편집하다@Gilles 'SO- 악한 행동을 멈춰라'에 대한 훌륭한 답변입니다.
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
MD5가 약한 것으로 간주되어 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 인프라 내부입니다. 즉, 서명 키가 손상되었거나 빌드 서버가 잘못된 해시를 보고하는 경우입니다.
1 이 맥락에서 "(암호화) 체크섬", "(암호화) 해시" 및 "(암호화) 다이제스트"는 동의어입니다. 비암호화 체크섬과 해시가 있지만 여기에는 관련되지 않습니다.
답변2
이 답변에서는 Windows 10 호스트를 가정합니다.
VirtualBox에서 2020-2 amd-64 ISO의 "기본 시스템 설치" 단계 중 "Packages.gz"에서 동일한 "해시 합계 불일치" 오류로 보이는 오류가 발생했습니다. 또한 Kali 2020-2 amd-64 VirtualBox OVA를 부팅했는데 apt-get update
. "Device Guard" 또는 "가상화 기반 보안"이라고도 알려진 "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를 비활성화하면 저에게 효과적이었습니다.
당이 댓글, 나는 그 일을 하는 데 필요한 자원을 찾았습니다.
- 관리자 권한 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
메모:
Windows용 Docker는 Hyper-V를 사용하므로 Docker를 사용하는 경우 Docker를 종료하면 VBox 문제가 해결될 수도 있습니다.