4 — это реально? Отслеживаем эксплуатацию и исправление слабых ключей eMudhra30.10.2026 20:38

19 октября 2026 года мы узнали о восьми шокирующе слабых ключах eMudhra: когда eMudhra доверили выбрать 115-значное число для виртуального кодового замка, защищающего Интернет, они выбрали число 4. Даже не четыре цифры — просто число 4. Остальные семь ключей были столь же слабыми: 56, 66, 115, 155, 156, 230 и 237.

На следующий день мы опубликовали пост в блоге о неотложных мерах, которые мы приняли для устранения последствий этой утечки, и о том, что нужно было сделать клиентам со своей стороны, чтобы обеспечить безопасность. Теперь мы подробно расскажем о свидетельствах эксплуатации уязвимости, которые нам удалось обнаружить, и о том, как продвигается установка исправлений посетителями.

Начнём с масштабов проблемы. Случай с центром сертификации (CA), использующим настолько слабые ключи, беспрецедентен, а возможные последствия весьма серьёзны. В прошлом было немало случаев компрометации центров сертификации, например DigiNotar, TÜRKTRUST и TrustWave, однако доступ к их ключам всегда был в той или иной степени ограничен: в результате этих инцидентов лишь отдельные злоумышленники или организации получали возможность выпускать поддельные сертификаты. Случай eMudhra принципиально иной: затронутые закрытые ключи промежуточных центров можно было практически мгновенно восстановить любому по самим общедоступным сертификатам. Любой мог самостоятельно восстановить те же ключи подписи и создать сертификаты для любых доменов, которые принял бы не обновлённый клиент, не проверяющий прозрачность сертификатов.

eMudhra объявила, что уходит с рынка публичных центров сертификации, и заявила, что причиной стала ошибка в скрипте генерации ключей, однако сам скрипт пока не предоставила. Компания подписала список отозванных сертификатов (CRL) ключом, который, возможно, был сгенерирован правильно, а затем исправила его, подписав слабым ключом.

Как такое могло произойти и почему это не вызвало тревогу? Нужно прояснить многое, в том числе роль аудиторов и организаций, выполняющих перекрёстную подпись. В этой статье мы предлагаем меры и дальнейшие шаги, которые помогут организациям обеспечить свою безопасность.

Установка исправлений в Cloudflare

В первую очередь нас по-прежнему волнует влияние этой ситуации на безопасность Cloudflare, наших клиентов и Интернета в целом. На момент публикации исправления установлены во всех высокоприоритетных системах Cloudflare. В работе остаётся небольшое число подтверждённых задач с низким уровнем воздействия.

Мы немедленно приступили к установке исправлений на системах с высоким уровнем воздействия — 19 октября. К ним относились прокси, взаимодействующие с исходными серверами клиентов и использующие Pingora; на них приходится большинство наших исходящих подключений. За несколько часов мы обновили эти системы, чтобы они отклоняли уязвимые ключи eMudhra. Одновременно мы начали анализировать исходный код с помощью ИИ, чтобы найти все остальные системы, которые доверяют этим слабым ключам. Полный анализ был готов в течение четырёх часов. Для каждой системы мы создали задачу с предварительными результатами анализа и попросили команду подтвердить их и/или скорректировать до конца дня. Для систем с высоким уровнем воздействия мы запросили немедленную установку исправлений, а для систем с низким уровнем воздействия срок устранения проблемы назначили на конец прошлой недели.

Обнаружила ли Cloudflare эксплуатацию уязвимости в своей сети?

Чтобы отслеживать случаи, когда сервер клиента (или злоумышленник) предъявляет сертификат, подписанный слабыми ключами eMudhra, мы добавили журналирование в Pingora. Поскольку на этот исходящий сервис приходится подавляющее большинство исходящих TLS-подключений с машин Cloudflare, любая попытка злоумышленника вести слежку с помощью ключей eMudhra попала бы в журнал. Развёртывание журналирования завершилось 21 октября.

На момент публикации, неделю спустя, мы зафиксировали около 22 000 попыток установить соединение с использованием слабых ключей eMudhra. Две трети попыток приходились на запросы к тестовым сайтам, таким как emudhra.we-have-a-problem.com (о нём мы упоминали в рекомендациях разработчикам в предыдущей публикации). Почти все остальные попытки были направлены на исходные серверы, которые, судя по всему, настроили для себя сертификат с помощью уязвимого промежуточного центра. Все попытки установить соединение, в которых выполнялась проверка сертификата, были отклонены, поскольку мы уже установили исправления.

Около 160 попыток соединения привлекли наше внимание: в альтернативных именах субъекта (SAN) сертификатов были указаны домены других организаций, не связанные с запрошенным при установлении соединения индикатором имени сервера (SNI). Некоторые из этих доменов относились к потребительским IoT-устройствам. Мы также заметили, что поддельные сертификаты были созданы уже после утечки ключей, а срок действия некоторых превышал два года — дольше, чем может выдать любой публичный центр сертификации. Однако эти сертификаты больше походили на стандартные сертификаты самих серверов, а не на часть попытки перехватить наши соединения. В них были указаны домены, отличные от тех, к которым выполнялось подключение, поэтому проверку имени хоста они всё равно бы не прошли. Кроме того, в нескольких случаях сервер предъявлял один и тот же сертификат при подключении из разных наших точек присутствия, а значит, сертификат исходил от самого сервера, а не от какого-либо узла на отдельном участке сетевого маршрута.

Итак, хотя пока у нас нет свидетельств использования слабых ключей для перехвата соединений Cloudflare, похоже, что их использовали для подделки сертификатов уже через несколько часов после публичного раскрытия уязвимости: один из обнаруженных нами поддельных сертификатов был датирован 20 октября, 18:19 UTC — менее чем через час после публикации отчёта об ошибке Mozilla. Это не исключает тщательно подготовленного целевого перехвата. В таком случае нам приходится полагаться на косвенные признаки компрометации системы — пока мы не обнаружили ни одного такого признака.

Сколько посетителей всё ещё уязвимы?

Мы рассказали об установке исправлений в Cloudflare, но что насчёт наших посетителей? Мы не можем напрямую проверить, доверяет ли посетитель слабым ключам, не нарушив соединение, поэтому приходится использовать косвенный метод. Для этого мы задействовали наши страницы проверки:

Пример страницы проверки Cloudflare

Мы развернули обновление, которое на части страниц проверки инициирует два пробных подключения: одно к ca1.cloudflarecaptcha.com, а другое — к ca2.cloudflarecaptcha.com. Сначала мы установили на ca1.cloudflarecaptcha.com сертификат, подписанный eMudhra, а на ca2.cloudflarecaptcha.com — обычный сертификат для контрольного сравнения. Затем мы фиксируем, успешны ли эти пробные подключения. Это позволяет определить, доверяют ли посетители, которым показывается страница проверки, слабым ключам eMudhra.

Что мы обнаружили? За последнюю неделю мы выполнили 50 миллионов пробных подключений и получили такие результаты:

Сразу оговоримся: трафик на эти страницы проверки по своей природе сильно смещён. Среди него много ботов, хотя это не подтверждено. Кроме того, пробные подключения выполняют только клиенты, запускающие JavaScript, например браузеры.

Изменения на графике объясняются следующими событиями (время указано по UTC):

• 23 октября, 15:30 — мы изменили контрольную конечную точку: теперь она также передавала сертификат eMudhra, но без подписанных временных меток сертификата (SCT). Различия в результатах проверки были, но небольшие. Мы могли бы добавить новую конечную точку, однако это потребовало бы медленного развёртывания обновления платформы проверки. Изменить конечную точку было проще.
• 23 октября, 16:30 — из-за проблемы, не связанной с этим инцидентом, наша платформа проверки откатилась к предыдущей версии. Пробные подключения возобновились 27 октября в 10:00.
• 27 октября, 16:37 — мы заметили, что не отправляли перекрёстную подпись G3, о которой знали не все клиенты, и добавили её на обе конечные точки. Мы удалили SCT с обеих.
• 27 октября, 16:49 — мы переключили ca2 на цепочку сертификатов, ведущую к корневому сертификату AAA Certificate Services.
• 27 октября, 18:18 — мы увеличили долю страниц проверки, на которых выполнялись пробные подключения, с 1% до 10% для зон клиентов, не использующих платные тарифы.

С учётом этих оговорок, что мы видим? В современных браузерах с актуальными обновлениями исправления установлены в основном, а в ботах и старых браузерах — нет. Отстают и встроенные браузеры, например Android WebView: от 30 до 40% из них всё ещё принимают эти сертификаты. В первые выходные (когда мониторинг не работал) мы видим явные свидетельства установки исправлений, но после этого изменений почти нет.

29 октября примерно в 18:00 UTC мы выпустили средство обнаружения, которое выявило резкий рост бот-трафика, маскирующегося под Chrome 150–154 на macOS. На верхнем графике это может выглядеть как установка исправлений, но на самом деле изменился состав классифицируемого трафика: у тех же пользовательских агентов наблюдается соответствующий рост доли принятых сертификатов среди трафика с обнаруженными признаками ботов на нижнем графике.

Chrome 150–154 на Linux — заметное исключение: доля принятых сертификатов продолжает снижаться, что соответствует дальнейшей установке исправлений в этой группе. С учётом большого количества ботов и изменчивого состава трафика эти данные скорее указывают на тенденцию, чем дают окончательный вывод. В остальном изменений по-прежнему почти не видно.

Если разбить данные по сетям (ASN), получим следующую картину:

В крупных сетях более половины пробных подключений по-прежнему принимают скомпрометированную цепочку сертификатов — как среди трафика без обнаруженных признаков ботов (верхний график), так и среди трафика с такими признаками (нижний график). В выходные мы наблюдали установку некоторых исправлений, но затем тенденция не менялась.

Главная оговорка остаётся в силе: на трафик влияют боты, принадлежность которых к ботам не подтверждена. Но боты — это тоже программное обеспечение, которому нужны обновления безопасности. Если они хоть сколько-нибудь отражают общую ситуацию с обновлением ПО, картина и правда весьма тревожная.

Что можно сделать?

Установите исправления! Деннис Джексон подготовил отличный сайт с инструкциями, созданными сообществом. Особенно важно следовать этим инструкциям, если вы разработчик и пользуетесь macOS. Если вы клиент Cloudflare, ознакомьтесь с прошлой публикацией в блоге: там рассказано, что нужно сделать со своей стороны при использовании таких продуктов, как WARP или Tunnel.

Что дальше

В некоторых продуктах Cloudflare уже действует механизм быстрого отзыва сертификатов. Чтобы внедрить его в большем числе систем Cloudflare и в отрасли в целом, мы с интересом следим за такими проектами, как upki: они учитывают, что хранилище доверенных сертификатов не может быть статичным списком корневых центров сертификации и должно позволять быстро обновлять такие сведения, как данные об отзыве сертификатов и ключи прозрачности сертификатов. Уязвимости обнаруживают быстрее, чем когда-либо, поэтому крайне важно устранять их быстро и эффективно.

© Cloudflare Blog