Восемь промежуточных сертификатов центра сертификации eMudhra оказались защищены приватными ключами длиной всего один байт. Такие уязвимые сертификаты eMudhra можно подобрать перебором из 256 вариантов практически мгновенно, а затем использовать для подмены сайтов и подписи вредоносного ПО. Для российских компаний это не очередной повод нажать кнопку обновления в браузере, а инвентаризация всего, что умеет проверять TLS-сертификаты: от серверов и рабочих станций до контейнеров, роутеров и старых корпоративных устройств.
Проблему обнаружили в шести промежуточных TLS-сертификатах и двух сертификатах для подписи кода, выданных индийской eMudhra. О ситуации сообщает Tom's Hardware. Промежуточный центр сертификации — это звено цепочки доверия между корневым сертификатом, который хранится особенно тщательно, и сертификатом конкретного сайта или разработчика. Получив контроль над таким звеном, злоумышленник теоретически может выпустить сертификат для чужого домена или подписать файл от имени известного поставщика ПО.
Практический сценарий выглядит неприятно, но вполне приземлённо. Атакующий должен находиться на пути сетевого трафика: например, в публичной Wi‑Fi-сети, внутри скомпрометированной корпоративной инфраструктуры, у провайдера или в иной точке, где можно перехватывать соединение. Если клиентская система всё ещё доверяет проблемному промежуточному сертификату, ей можно показать поддельный сайт банка, облачного сервиса или корпоративного портала с формально корректной цепочкой доверия. Пользователь увидит привычный замок в браузере, а приложение — валидный сертификат.
С сертификатами подписи кода риск другой: вредоносный установщик может выглядеть так, будто его выпустил легитимный разработчик. Это не означает, что любой файл автоматически обойдёт защиту Windows, антивируса или контроль запуска. Но цифровая подпись остаётся важным сигналом доверия для ОС, корпоративных политик и пользователей. Когда криптографический секрет сводится к одному байту, этот сигнал превращается в декорацию.
У уязвимости есть существенное ограничение. Актуальные Chrome, Brave, Firefox и Safari используют Certificate Transparency — публичные журналы выпуска веб-сертификатов. Браузер проверяет, что сертификат зарегистрирован в таком журнале; сертификаты, выпущенные в обход процедуры, должны блокироваться. По данным Google, в эти журналы не попали сертификаты, подписанные шестью затронутыми TLS-промежуточными центрами. Поэтому для обычного веб-сёрфинга на обновлённом браузере риск заметно ниже.
Но браузер — лишь один из десятков TLS-клиентов на типичной машине. Собственные хранилища доверенных центров и собственную логику проверки могут использовать Java-приложения, Python- и Go-сервисы, Node.js, Rust-бинарники, curl, агенты мониторинга, пакетные менеджеры и SDK. В инфраструктуре к ним добавляются виртуальные машины, Docker-контейнеры, образы для CI/CD, прокси, балансировщики и сетевое оборудование. Патч операционной системы не гарантирует, что все эти компоненты получат обновлённый список отозванных сертификатов.
Именно поэтому уязвимые сертификаты eMudhra — прежде всего задача для команд эксплуатации и безопасности. Стоит проверить, как в компании распространяются обновления корневых и промежуточных CA, какие базовые образы используются в контейнерах, не закреплены ли сертификаты в приложениях вручную и есть ли в сети устройства с неподдерживаемой прошивкой. Отдельного внимания требуют старые роутеры, IoT-устройства и изолированные сегменты: производитель может уже не выпустить исправление, а встроенный клиент TLS продолжит доверять скомпрометированной цепочке.
Для разработчиков это также хороший тест на зрелость зависимостей. В коде нередко отключают проверку сертификатов ради «быстрой диагностики», встраивают устаревший набор CA в образ или годами не обновляют библиотеку, которая отвечает за HTTPS. На фоне подобного инцидента такие временные решения становятся удобной точкой входа. Минимальная программа — обновить ОС, браузеры, среды выполнения и контейнерные образы, затем убедиться, что обновления действительно дошли до продакшена, а не только до ноутбука инженера.
Причина появления ключей длиной в один байт ещё расследуется. Однако сам инцидент уже показывает слабое место глобальной PKI: ошибка одного центра сертификации быстро превращается в работу для всего рынка. Быстрые обновления снизят риск на современных платформах, но реальный масштаб истории будет определяться не браузерами, а количеством забытых устройств и приложений, которые продолжают жить со старым списком доверия.
