У центра сертификации eMudhra обнаружили восемь закрытых ключей, которые можно восстановить за доли секунды. Ошибка позволяла создавать поддельные HTTPS-сертификаты для любых сайтов, а некоторые программы продолжали доверять таким сертификатам даже после раскрытия проблемы.
Исследователь Скотт Хелме восстановил все восемь ключей непосредственно из общедоступных сертификатов. Один закрытый ключ оказался равен числу 4, другой 56, третий 115. Для взлома не понадобились суперкомпьютеры или сложные криптографические атаки. Каждый ключ удалось подобрать на обычном ноутбуке менее чем за секунду.
Проблема затронула шесть промежуточных центров выдачи TLS-сертификатов и два центра подписи программного кода. Промежуточный центр получает полномочия от корневого удостоверяющего центра и может самостоятельно подписывать сертификаты сайтов. Если злоумышленник узнает его закрытый ключ, то сможет выпускать поддельные документы, которые некоторые приложения будут считать настоящими.
Самое неприятное обнаружилось при проверке реальной опасности. Хелме создал поддельный сертификат для платёжного API api.stripe.com и поднял тестовый сервер на собственном компьютере. Утилита curl успешно проверила сертификат, Python установил защищённое соединение, а Node.js подтвердил подлинность сервера. Аналогичные результаты исследователь получил на протестированных системах Linux и macOS.
Эксперимент не затрагивал настоящие серверы Stripe, но показал, как могла бы работать атака. Если злоумышленник получит возможность перехватывать или перенаправлять сетевое соединение, поддельный сертификат позволит выдать подконтрольный сервер за настоящий. Уязвимое приложение может передать атакующему пароли, токены доступа и другие конфиденциальные сведения, не обнаружив подмены.
Причина катастрофической слабости ключей оказалась удивительно простой. eMudhra использовала криптографический алгоритм на эллиптической кривой P-384, где закрытый ключ должен быть случайным числом размером около 384 бит. Вместо полноценного случайного значения система создала ключи, содержавшие всего один ненулевой байт. Для восстановления каждого секрета достаточно проверить не более 255 вариантов.
Сам алгоритм P-384 никто не взломал. Ошибка возникла при создании ключей, а внешне сертификаты выглядели совершенно нормально. Их структура соответствовала стандартам, открытые ключи были математически корректными, а обычные проверки не обнаруживали нарушений. Выявить проблему удалось только после анализа криптографической стойкости самих ключевых пар.
Все восемь слабых ключей появились 30 апреля 2025 года. Каждый использовался в двух промежуточных сертификатах, один подписала сама eMudhra, второй в мае 2025 года дополнительно подписала Sectigo. Таким образом, существовало 16 сертификатов с восемью одинаково уязвимыми ключевыми парами. Возможность восстановить закрытые ключи сохранялась около 17 месяцев, причём злоумышленникам не требовалось проникать в инфраструктуру удостоверяющего центра.
Первые защитные меры приняли 17 октября 2026 года после обращения исследователя, обнаружившего проблему. Google заблокировала опасные ключи в Chrome через механизм CRLSet, а Mozilla распространила блокировку через OneCRL. Пользователям с обычными настройками не понадобилось даже перезапускать браузеры. Аналогичную защиту для Android Google начала распространять через сервисы Google Play 19 октября.
Дополнительным барьером стала система Certificate Transparency, которая требует публично регистрировать сертификаты сайтов. Google не обнаружила в журналах ни одного TLS-сертификата, выпущенного шестью проблемными центрами до их блокировки. Поэтому поддельные сертификаты не могли пройти стандартную проверку Chrome, требующую подтверждения регистрации. Однако далеко не все программы используют такой механизм.
Основной риск теперь связан с приложениями, которые проверяют сертификаты иначе, чем современные браузеры. Серверные API, автоматические установщики программ, системы непрерывной сборки и развёртывания CI/CD, облачные инструменты и пакетные менеджеры часто полагаются на локальное хранилище доверия. Многие клиенты по умолчанию не проверяют отзыв сертификатов и не требуют регистрации в публичных журналах. Поэтому формально отозванный сертификат всё ещё может пройти проверку.
Особенно сложная ситуация складывается с маршрутизаторами, камерами, промышленными контроллерами и другими устройствами, которые редко получают обновления. Некоторые системы используют собственные наборы доверенных сертификатов, встроенные непосредственно в прошивку. Без исправления такие устройства потенциально могут принимать поддельные сертификаты до окончания срока действия соответствующих цепочек доверия. Для части затронутых сертификатов срок истекает только в июле 2039 года.
Отдельную опасность представляют два скомпрометированных центра подписи программного кода. Их ключи позволяют создавать цифровые подписи, которые могут выглядеть действительными для проверяющих систем Windows. При отсутствии проверки отзыва злоумышленники потенциально способны использовать такие подписи для вредоносных программ. Угроза не означает автоматического обхода всех механизмов защиты Windows, но создаёт дополнительную возможность маскировать происхождение исполняемых файлов.
Mozilla 20 октября выпустила Firefox 158.0.1 и обновления веток ESR 115.43.1 и 153.5.1. Дополнительно разработчики подготовили NSS 3.131.1 с удалением доверия к корневому сертификату emSign ECC Root CA - G3. Google также решила исключить соответствующий корневой сертификат из Chrome Root Store. Массовое распространение такого изменения запланировано на 27 октября. Владельцам сайтов, использующим затронутую корневую цепочку, потребуется заменить сертификаты, иначе соединения могут перестать работать.
Cloudflare проверила собственную инфраструктуру и не обнаружила признаков эксплуатации проблемы в своих сервисах. Компания обновила клиенты WARP и Cloudflare Tunnel, а также внедрила дополнительные ограничения в CDN и сервисах Zero Trust. Администраторам рекомендуют обновлять системные наборы сертификатов, библиотеки проверки TLS и контейнерные образы. Проверять необходимо именно приложения, поскольку исправленный браузер не гарантирует безопасность остальных программ на компьютере.
Компания eMudhra объяснила произошедшее предварительными результатами внутреннего расследования. Во время создания ключей специалисты использовали аппаратные криптографические модули Ultimaco HSM. В сценарий генерации внесли изменения для проверки операций экспорта ключей, после чего программная ошибка привела к появлению дополнительных слабых ключевых пар. Из-за похожих обозначений сотрудники выбрали неправильные ключи для запросов на выпуск сертификатов.
По версии eMudhra, первоначально оборудование создало полноценные криптографические ключи, но при дальнейшей работе сотрудники использовали слабые дубликаты. Ошибочные запросы подписали собственным корневым центром, а затем передали Sectigo для дополнительной подписи. Разработчик считает, что аппаратные модули не были непосредственной причиной проблемы, однако расследование ещё продолжается. Компания также признала несколько человеческих ошибок на разных этапах процедуры.
В ходе разбирательства Mozilla обнаружила ещё одну подозрительную деталь. В мае 2025 года те же промежуточные центры уже фигурировали в инциденте с некорректными подписями списков отозванных сертификатов. Представители eMudhra пояснили, что первоначально такие списки подписывали правильными ключами, а после обнаружения несовпадений повторно подписали ошибочными. Насколько ранний инцидент был связан с нынешним, специалисты продолжают выяснять.
eMudhra утверждает, что семь проблемных промежуточных центров вообще не использовались в рабочей инфраструктуре, а восьмой не выпустил ни одного конечного сертификата. Компания также заявляет, что закрытые ключи корневых центров и остальных промежуточных центров не пострадали. Все восемь скомпрометированных сертификатов отозваны, а Sectigo отдельно отозвала собственные сертификаты с перекрёстной подписью.
Подтверждённых случаев злонамеренного применения восстановленных ключей пока нет. Однако отсутствие записей в публичных журналах не исключает атак на программы, которые не используют Certificate Transparency. Установить, восстанавливал ли кто-нибудь закрытые ключи до публичного раскрытия, практически невозможно. Инцидент показал, что даже правильно работающие криптографические алгоритмы не спасают систему, если удостоверяющий центр допускает ошибку при генерации ключей, а приложения годами продолжают доверять скомпрометированным сертификатам.
