Уязвимость была идентифицирована в Juju от версии 3.2.0 до 3.6.19 и от версии 4.0 до 4.0.4, где внутренний кластер базы данных Dqlite не вы…
Уязвимость была идентифицирована в Juju от версии 3.2.0 до 3.6.19 и от версии 4.0 до 4.0.4, где внутренний кластер базы данных Dqlite не выполняет надлежащую аутентификацию TLS-клиента и сервера. В частности, конечная точка базы данных контроллера Juju не проверяет сертификаты клиента, когда новый узел пытается присоединиться к кластеру. Неаутентифицированный злоумышленник с доступностью сети к порту Dqlite контроллера Juju может использовать этот недостаток для присоединения к кластеру базы данных. После присоединения злоумышленник получает полный доступ к основной базе данных, что позволяет получить полный компрометацию данных.
Продукт не проверяет или некорректно проверяет сертификат.
https://cwe.mitre.org/data/definitions/295.html →Открыть в коллекции CWE →Злоумышленник эксплуатирует слабость, возникающую вследствие применения хеш-алгоритма с низкой устойчивостью к коллизиям, для генерации запросов на подпись сертификата (CSR), содержащих блоки коллизий в разделах «подписываемых данных». Злоумышленник отправляет один CSR на подписание доверенному удостоверяющему центру, а затем использует подписанный блок для того, чтобы второй сертификат выглядел подписанным тем же удостоверяющим центром. Вследствие хеш-коллизии оба сертификата, будучи различными, дают одно и то же хеш-значение, и подписанный блок одинаково работает с обоими сертификатами. В итоге второй сертификат X.509 злоумышленника, который удостоверяющий центр никогда не видел, оказывается подписанным и верифицированным этим удостоверяющим центром.
https://capec.mitre.org/data/definitions/459.html →Открыть в коллекции CAPEC →Злоумышленник эксплуатирует криптографическую слабость в реализации алгоритма проверки подписи для генерации действительной подписи без знания ключа.
https://capec.mitre.org/data/definitions/475.html →Открыть в коллекции CAPEC →