Ключи eMudhra от 1 до 255: миллионы устройств обновили за два дня
PrimeCoder · 2026 · формат: news
Что произошло, почему это важно и что взять в работу.
Скомпрометированный промежуточный CA ломает цепочку доверия во всём стеке — от браузеров до Docker-образов, поэтому проверка ca-certificates в CI и образах становится обязательным шагом релиза, а не «заботой вендора».
Связанные услуги: каталог, AI Boost Team, стать клиентом.
Закрытый ключ удостоверяющего центра со значением 7. Или 12. Или 200. Перебор всех вариантов занимает 255 итераций, и на каждой можно вычислить открытый ключ, а потом сравнить с тем, что опубликован в сертификате. Исследователь под псевдонимом Wayne так и сделал: нашёл восемь закрытых ключей промежуточных CA eMudhra и подписал каждым одну фразу.
В доказательство Wayne подписал каждым из восьми ключей сообщение «We have a problem here - Wayne».
17 октября он написал об этом разработчикам браузеров. Дальше события пошли по часам, и вот эта скорость важнее самого бага.
Как ключ от удостоверяющего центра стал числом
Штатно ключи создают в аппаратных модулях безопасности, HSM. eMudhra планировала перенести их на площадки в США и Европе: выгрузить в зашифрованном виде, загрузить в другой модуль. В процедуру добавили проверку упаковки и распаковки. По объяснению компании, ошибка в этом скрипте и породила второй, слабый набор ключей: из-за похожих меток два набора перепутали, и в запросы на выпуск сертификатов попали открытые ключи из слабого.
Сертификаты на них выпустила сама eMudhra, а следом Sectigo. У клиентов появилось два пути доверия к одним и тем же слабым ключам. Дальше самое неприятное. В июне 2025 года Sectigo заметила, что подписи eMudhra не проходят проверку: документы подписывали исходными ключами, а сертификаты центров уже были выданы на второй набор. В eMudhra переключились на второй набор, подписи стали проходить. Несовпадение устранили. Слабость ключей осталась, и в отчёте о ней не было ни слова.
То есть ключи со значениями от 1 до 255 спокойно жили в проде примерно полтора года. Открытый вопрос, почему июньский сигнал не привёл к разбору, всё ещё висит. Обещанный подробный отчёт eMudhra пока не закрывает его.
Почему это не история про один индийский CA
Компрометация промежуточного центра ломает цепочку доверия не в браузере, а во всём стеке сразу. Доверенные сертификаты вшиты в стандартный модуль ssl у Python, в Node.js, в Oracle Java 8, в Go, в Julia. Они лежат в Android и приезжают через Google Play Services. Они есть в SteamOS на Steam Deck, в прошивках колонок Sonos и телевизоров Samsung. Владелец камеры Sony подменил магазин приложений и получил root.
Для владельца бизнеса это значит простую вещь. Ваш Docker-образ, собранный в сентябре, об отзыве не узнает никогда. Ваш сервер с выключенным автообновлением тоже. Ваш поставщик железа с прошивкой без OTA-канала тем более. Пока вендоры разносили блокировки (17–20 октября браузеры, ночь с 19 на 20 октября Android, 20 октября пакеты Ubuntu и Debian, 24 октября SteamOS, 20–26 октября языковые рантаймы), у части компаний на руках оставались неизменённые образы и стенды.
Вердикт: проверка ca-certificates переезжает в релизный чек-лист
Проверять доверенные сертификаты в образах и CI нужно самим. Это не забота вендора дистрибутива, это шаг релиза, как прогон тестов или сканирование зависимостей.
Что делать конкретно. Обновить ca-certificates и libnss3 в базовых образах, посмотреть исправленные версии пакетов (20260816ubuntu0.22.04.1, 20260816ubuntu0.24.04.1, 20260816ubuntu0.26.04.1, 20260816ubuntu0.26.10.1 для соответствующей ветки Ubuntu), пересобрать контейнеры и перевыпустить всё, что вы собираете из pinned-образов. Отдельно пройтись по сервисам на Python, Node.js и Java: там свой trust store, обновление системы его не всегда трогает.
Дальше тест. Есть 14 тестовых адресов, которые прогоняются через curl. Логика простая:
Если в ответе появилось Your client successfully connected to the site, curl принял опасный сертификат. Ожидаемый результат — отказ из-за недоверенного сертификата.
Такой прогон ставится в пайплайн за полчаса и дальше работает на каждую сборку. Дешевле, чем разбираться с перехватом трафика постфактум.
Где подвох, чтобы не уйти в панику
Сам по себе слабый ключ не даёт злоумышленнику ничего, пока тот не получил контроль над трафиком. На Яндекс Станциях энтузиасты организовали MITM на своём устройстве и через подмену конфигурации включили ADB, служебный интерфейс отладки, а через него зашли с правами root. Вендор закрыл и то и другое: обновление перезаписывает скомпрометированные файлы и убирает доверие к сертификатам, доступ к ADB тоже закрыт.
Оговорка по срокам и остаточным рискам. Полный сброс возвращает Станцию к заводской прошивке, где уязвимость сохраняется до установки обновления, и вместе с ней возвращаются устранённые ранее дыры. Сброс требует физического доступа к устройству, поэтому риск ниже, но привычку «сбросить, если глючит» лучше придержать.
Главный вывод короче. Доверие к сертификатам это такой же артефакт сборки, как версия библиотеки. Пока он не проверяется автоматически, вы узнаёте о его состоянии от исследователя с ником, а не от своего пайплайна. В октябре 2026-го эта новость стоила нескольким миллионам устройств девяти дней экстренных обновлений. Вашим образам столько времени никто не даст.
PrimeCoder Team · Официальный ответ · PrimeCoder
Опишите, кто сейчас обрабатывает заявки и какие SLA по факту — предложим поэтапный сценарий без остановки операционки.