Серьезно? Отслеживание эксплуатации и исправление уязвимых ключей eMudhra

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

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

Начнем с масштаба проблемы. Центр сертификации (ЦС) со столь серьезными уязвимыми ключами — это беспрецедентный случай, и потенциальные последствия весьма значительны. Хотя в прошлом было немало взломанных центров сертификации (таких как DigiNotar, TÜRKTRUST и TrustWave), доступ к их ключам всегда был в определенной степени ограничен; эти инциденты давали лишь ограниченному кругу злоумышленников или организаций возможность выпускать мошеннические сертификаты. Инцидент с eMudhra принципиально отличается: затронутые промежуточные закрытые ключи могли быть практически мгновенно восстановлены кем угодно из самих публичных сертификатов. Любой человек может самостоятельно восстановить эти же ключи подписи и создать сертификаты для любого домена, который принял бы неисправленный клиент, не применяющий «Прозрачность сертификатов» (Certificate Transparency).

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

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

Исправление Cloudflare

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

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

Зафиксировала ли Cloudflare попытки эксплуатации в своей сети?

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

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

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

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

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

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

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

Что мы обнаружили? Обработав 50 миллионов проб за последнюю неделю, мы видим следующее:

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

Скачок в данных обусловлен следующими изменениями — все время указано в формате UTC:

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

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

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

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

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

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

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

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

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

Взгляд в будущее

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