Центр сертификации воплотил в жизнь шутку из XKCD
Поразительное раскрытие информации от исследователя безопасности «Wayne» 17 октября выявило глубокий сбой в инфраструктуре открытых ключей: восемь промежуточных сертификатов eMudhra, включая центры сертификации TLS и подписи кода, были скомпрометированы. Закрытые ключи для этих сертификатов, которым доверяли основные браузеры и операционные системы в течение 17 месяцев, представляли собой тривиально малые целые числа — одно из них буквально было числом 4.
Эти ключи основывались на эллиптической кривой P-384, которая обычно требует, чтобы private scalar (d) был большим непредсказуемым 384-битным числом, предлагающим примерно $10^{115}$ вариантов. Вместо этого скомпрометированные ключи eMudhra содержали 47 ведущих нулевых байтов, а последний байт содержал значение, достаточно малое для перебора максимум 255 кандидатов.
Эта катастрофическая слабость позволила мгновенно восстановить закрытые ключи. Идентифицированные значения были:
- 4
- 56
- 66
- 115
- 155
- 156
- 230
- 237
Несмотря на ничтожно малый размер, эти целые числа все равно создают математически корректные точки открытого ключа на кривой. Это означает, что сертификаты прошли стандартные структурные проверки, скрывая лежащую в основе криптографическую хрупкость. Google Chrome и Firefox быстро заблокировали эти сертификаты, за ними последовали Apple и Microsoft.
У ошибки был бумажный след — и пропущенный сигнал тревоги
Сообщенная причина восходит к April 2025 key ceremony, где eMudhra изменила скрипт для тестирования экспорта ключей. Этот скрипт непреднамеренно сгенерировал слабые дополнительные пары ключей на аппаратном модуле безопасности (HSM). Операторы, введенные в заблуждение похожими метками, затем использовали эти скомпрометированные ключи для запросов сертификатов вместо предназначенных для этого криптографически стойких ключей.
Важно отметить, что предупреждение появилось в июне 2025 года. Sectigo, кросс-подписант, сообщил о неверных подписях в списках отзыва сертификатов (CRL) eMudhra. Это несоответствие возникло из-за того, что eMudhra попыталась подписать CRL своими исходными сильными ключами, которые не соответствовали слабым ключам, встроенным в выданные сертификаты.
Вместо того чтобы расследовать основное несоответствие, eMudhra повторно подписала списки отзыва, используя слабые ключи. Это временное решение фактически скрыло симптом, позволив фундаментальной уязвимости безопасности сохраняться еще 16 месяцев.
С операционной точки зрения этот инцидент подчеркивает два критических урока. Церемонии создания ключей требуют independent identity and strength checks для всех сгенерированных криптографических материалов. Кроме того, любое несоответствие подписи, особенно в контексте инфраструктуры открытых ключей, должно вызывать немедленное реагирование на инцидент, а не поверхностное временное решение.
У браузеров были защитные барьеры. У систем сборки их часто нет
Sectigo выполнила кросс-подпись промежуточных сертификатов eMudhra, обеспечив им широкое распространение в хранилищах доверия платформ. Исследователь Wayne продемонстрировал контроль, подписав проверочное сообщение «We have a problem here» каждым из восьми скомпрометированных ключей. Это подтвердило компрометацию ключей и подчеркнуло широкие возможности для злоупотреблений.
Браузеры, такие как Google Chrome и Mozilla Firefox, оперативно отозвали сертификаты, часто в течение нескольких часов. Они обеспечивают соблюдение логов Certificate Transparency (CT), публично записывая все доверенные TLS-сертификаты. Браузеры обычно отклоняют сертификаты, отсутствующие в этих логах, что является критически важной защитой, предотвратившей прямую эксплуатацию в браузерах.
Однако клиентам, не являющимся браузерами, часто не хватает этих надежных средств защиты. Такие инструменты, как curl, Python, Node, Go и Git, часто полагаются на локальные пакеты CA, полностью пропуская проверки CT или аннулирования. Это делает их уязвимыми для атак типа machine-in-the-middle (MITM).
Практические риски существенны. Злоумышленник, обладающий одним из этих поддельных ключей, может нацелиться на:
- API-вызовы
- Скрипты установки
- CI-раннеры
- Облачные учетные данные
Два скомпрометированных ключа подписи кода также вызвали опасения по поводу поддельного программного обеспечения, которое потенциально может распространять вредоносные обновления или приложения. Дополнительные технические подробности см. в Mozilla Bugzilla: eMudhra Private Key Compromise of Intermediate Certificates.
Нравится статья? Получайте такие каждое утро на почту.
одно письмо в день · отписка в два клика · без сторонних трекеров
Обновите хранилище доверенных сертификатов, а затем протестируйте весь конвейер
Разработчики браузеров и операторы платформ быстро предприняли меры, чтобы лишить доверия затронутые сертификаты. Apple, Google Chrome, Microsoft и Mozilla заблокировали скомпрометированные промежуточные сертификаты в течение нескольких дней, а Sectigo прекратила соглашение о перекрестной подписи с eMudhra. Go выпустила целевой экстренный релиз версии 1.27.3, напрямую блокирующий эти восемь промежуточных сертификатов в своей стандартной библиотеке.
Охват обновлений устройств и программного обеспечения все еще может различаться, особенно для встроенных систем. Чтобы снизить риск, немедленно обновите операционную систему и пакеты CA. Обновите среды выполнения языков, такие как Go до версии 1.27.3, и пакет Python certifi до версии 2026.10.19. Пересоберите образы контейнеров и CI/CD раннеры, чтобы убедиться, что все зависимости актуальны.
Протестируйте свои клиенты с помощью опубликованной тестовой конечной точки инцидента: DV G3B eMudhra.we-have-a-problem.com. Если ваш клиент отклоняет цепочку сертификатов с ошибкой, значит, он в безопасности. Этот этап проверки имеет решающее значение для всех систем, которые полагаются на доверие к сертификатам.
Этот инцидент подчеркивает критический урок PKI: проверки формата не могут доказать случайность или намерения. Автоматизируйте проверки надежности ключей как часть процедур управления ключами. Проверяйте, что открытые ключи сертификатов точно соответствуют целевым ключам HSM, а не просто являются структурно правильными. Отслеживайте журналы Certificate Transparency (CT) и рассматривайте недействительные подписи аннулирования — такие как предупреждение Sectigo от июня 2025 года — как серьезные чрезвычайные ситуации в области безопасности.
Часто задаваемые вопросы
Что было не так с закрытыми ключами eMudhra?
Восемь промежуточных сертификатов CA использовали крошечные значения закрытых ключей, включая 4, вместо непредсказуемых 384-битных значений. Соответствующие ключи можно было восстановить, проверив всего несколько вариантов.
Находились ли обычные пользователи браузеров в опасности?
Требования современных браузеров к Certificate Transparency помогли заблокировать незарегистрированные поддельные сертификаты, хотя защита и обновления различались. Программное обеспечение, не являющееся браузером, часто не имеет эквивалентных проверок.
Почему CI-конвейеры вызывали беспокойство?
Инструменты и службы в конвейерах сборки могут доверять локальным пакетам CA без проверки Certificate Transparency или аннулирования сертификатов, потенциально принимая поддельный сертификат сервера.
Что должны делать разработчики?
Обновите хранилища доверенных сертификатов операционной системы и среды выполнения языков, пересоберите затронутые контейнеры и протестируйте поведение проверки сертификатов у клиентов, не являющихся браузерами, и CI-раннеров.