сертификаты
Подделка сертификатов, которые используются для защиты TLS-соединений и цифровой подписи приложений, периодически встречается в реальных атаках. Мы видели, как поддельными или украденными сертификатами злоупотребляли APT DarkHotel и вредоносное ПО Flame, а также в 2011 году наблюдали попытки атак после компрометации удостоверяющего центра Comodo. Как правило, для такого трюка злоумышленникам нужно обладать серьезным опытом. Но для атаки на сертификаты eMudhra в 2026 году злоумышленнику не нужно прикладывать особых усилий. Достаточно угадать число от 1 до 255. Восемь закрытых ключей промежуточных центров сертификации, которые в норме являются гигантскими числами, имели значения 4, 56, 66, 115, 155, 156, 230 и 237. Восстановить их по открытым ключам (публичным сертификатам) можно было меньше чем за секунду. В результате гипотетический злоумышленник мог бы выпускать сертификаты для чего угодно, подписывая их одним из скомпрометированных закрытых ключей.
Шесть из вышеупомянутых ключей предназначались для выпуска TLS-сертификатов, еще два — для подписи кода. Все восемь промежуточных центров (Intermediate Certificate Authorities) получили также перекрестные подписи удостоверяющего центра Sectigo. В результате поддельному сертификату могли доверять клиенты с разными цепочками доверия.
Хотя основные браузеры уже заблокировали опасные цепочки сертификатов, ИТ- и ИБ-командам нужно оценить и устранить риск во многих других системах организации. Серверы мониторинга, скрипты регулярной обработки данных, корпоративные NGFW, приложения со встроенными хранилищами сертификатов и устройства без регулярных обновлений могут принимать поддельные сертификаты и быть уязвимы к атакам MITM. А необходимые ключи уже встроены в общедоступные инструменты перехвата.
Хронология инцидента с удостоверяющим центром eMudhra
Проблемные ключи вошли в блок из 24 промежуточных центров, созданных eMudhra 30 апреля 2025 года. Вместо криптографически случайных значений для 384-битной эллиптической кривой восемь ключей оказались маленькими числами. Согласно описанию, данному eMudhra, во время генерации ключей операция «упаковки и распаковки ключевого материала» создала второй, слабый комплект. Поскольку ключи создаются и хранятся в специальном устройстве (Hardware Security Module, HSM), сама по себе слабость ключа не является ни легко заметной, ни очевидной. Но какая ошибка привела к двойной генерации и использованию именно слабого комплекта, пока непонятно, и расследование продолжается.
В мае 2025 года УЦ Sectigo подписал все восемь промежуточных сертификатов. А 17 октября 2026 года независимый исследователь уведомил ИБ-команды в Mozilla, Google и Apple, а также сам удостоверяющий центр о возможности восстановления ключей. 20 октября Mozilla публично раскрыла инцидент. Таким образом, подбор ключей и фальсификация сертификатов были возможны почти полтора года.
22 октября компания eMudhra объявила, что прекращает вести глобальный бизнес в сфере сертификатов SSL/TLS.
Что может сделать злоумышленник
Пользуясь уязвимыми промежуточными удостоверяющими центрами, атакующий может подписать поддельный сертификат для чужого домена. Если клиент по-прежнему доверяет цепочке и не применяет другие защитные решения, он примет подделку за настоящий сервер.
Для перехвата трафика HTTPS одного лишь сертификата недостаточно. Нужно иметь возможность вмешиваться в трафик жертвы или перенаправлять соединение. Это возможно, например, в скомпрометированной офисной сети, на подконтрольной точке доступа Wi-Fi или при вмешательстве в маршрутизацию и DNS. Но все перечисленное случается на практике, как показали, например, атаки DarkHotel.
И еще одна опасность — два ключа могут применяться для подписи кода, что теоретически позволяет подсовывать жертве вредоносное ПО, якобы исходящее от доверенного производителя и не вызывающее грозных предупреждений ОС при попытке инсталляции.
Была ли эксплуатация?
Эксперты различных компаний, анализировавшие последствия инцидента, не обнаружили вредоносных атак с использованием этих сертификатов. eMudhra и CERT-In также сообщали, что не обнаружили злоупотреблений. Команда Chrome не нашла сертификатов от шести CA в публичных журналах Certificate Transparency.
Это означает, что на системы, в которых браузеры проверяют сертификаты с помощью механизма Certificate Transparency, атак, скорее всего, не проводилось. Но многочисленные устройства и приложения, особенно серверы и устройства IoT, вообще не проверяют СТ, поэтому про них сказать ничего нельзя. Для проведения подобной атаки сегодня уже не нужно самостоятельно писать инструменты взлома. В популярном инструменте для ИБ-исследователей mitmproxy 12.3 уже встроена поддержка скомпрометированных ключей.
Где риск устранен и где это не гарантировано
Крупные онлайн-экосистемы оперативно отозвали ненадежные сертификаты. Уже 17 октября это сделали Chrome через CRLSets и Firefox через OneCRL. 18 октября сама компания eMudhra отозвала сертификаты с причиной CA Compromise. 19 октября приняла меры Apple, а УЦ Sectigo также отозвал перекрестно подписанные экземпляры. Microsoft провела отзыв 20 октября. В зависимости от настроек конкретного приложения и ОС, отзыв мог произойти даже без обновления приложения, списки блокировок часто обновляются отдельно.
Параллельно принимается более радикальная мера — отзыв доверия к корневому CA. Chrome предупреждает о запланированном удалении «emSign ECC Root CA — G3» из Chrome. При этом сертификаты и корень «emSign Root CA — G1» не затронуты. По оценке eMudhra, миграции требуют около 30 тысяч сертификатов.
Но процедуры отзыва сертификата работают только там, где клиент способен узнать об отзыве и действительно его учитывает. Многие программы проверяют подпись, имя сервера и срок действия сертификата, но не получают и не обновляют списки блокировок. Вот типовые случаи:
Устаревшие и LTS-системы. Все зависит от обновлений ca-certificates, библиотек TLS и настроек конкретного приложения. Сам статус LTS (Long-Term Support) не означает, что система уязвима, она по определению получает поддержку. Но старые контейнеры, замороженные образы ОС и системы, где уже не устанавливают обновления, способны доверять отозванным CA еще долго.
Автоматизированные системы и серверы. На созданном энтузиастами сайте «eMudhra, we have a problem», где любое клиентское ПО можно проверить на «опасную доверчивость», среди наиболее уязвимых систем доминируют curl и Zabbix. Zabbix при HTTP-проверках обычно использует libcurl и настроенное для него хранилище сертификатов. Документировано похожее поведение и во встроенном curl в macOS. На уровне ОС и Safari сертификат отозван, но приложение читает обычный файл etc/ssl/cert.pem и требует исправления именно там. Это хороший пример — даже при работающих системных механизмах доверия и отзыва конкретные приложения, в том числе входящие в стандартный комплект поставки, могут оставаться уязвимыми.
Python, Ruby, Go, Java и контейнеры. Приложение может использовать собственный набор корневых СА, который не обновляется вместе с ОС. Endor Labs обнаружила более 25 популярных пакетов, содержащих затронутый корень.
Slack, GitHub Desktop и другие приложения на фреймворке Electron. Они поставляются со своим Electron/Chromium: обновление отдельно установленного Chrome не обновляет Slack. Отзывы сертификатов уже вошли в новую версию Electron, но каждый разработчик теперь должен пересобрать и распространить приложение, а пользователь — установить обновление. При этом нельзя назвать точно уязвимыми все Electron-приложения. Результат зависит от версии, механизмов обновления списков блокировок и используемого сетевого стека.
Мобильные браузеры и IoT-устройства. Хотя мобильные Chrome, Firefox и Safari получают данные об отзыве сертификатов так же быстро, как и настольные, «фирменные браузеры» от производителей смартфонов не могут похвастаться такой же расторопностью. В опубликованном тесте Samsung Browser 31.0.0.64 принял все шесть тестовых цепочек через emSign, хотя отверг варианты через Sectigo. Для HarmonyOS 6 и 7 исследователи нашли затронутые центры в опубликованном списке корневых CA Huawei, причем отозвать их вручную невозможно.
Для неподдерживаемых устройств, бытовой техники и старых прошивок обновление хранилища может вообще не выйти. Здесь проблема может прожить годы.
Влияние на инспекцию TLS в сети организации
При инспекции зашифрованного трафика NGFW или веб-шлюз поддерживает два соединения: одно с клиентом, а другое — с внешним сервером. Клиент получает сертификат, подписанный корпоративным центром, а подлинность внешнего сервера проверяет сам шлюз.
Если шлюз принимает подделку eMudhra, даже обновленный браузер на компьютере сотрудника уже не увидит опасную цепочку, вместо нее он получит привычный корпоративный сертификат. В этом сценарии само средство защиты скрывает проблему от клиента. Для реализации атаки, впрочем, потребуется еще и перехват трафика.
Чтобы исправить политику проверки и списки сертификатов на самом устройстве инспекции, нужно следовать инструкциям производителя (если, конечно, производитель их опубликовал).
В Cisco подробно документируют статус проблемы по всем продуктам. Большинство из них пока в статусе «оценивается», но для уязвимых устройств рекомендованы смягчающие меры.
В Sophos и Check Point обещают обновления ПО устройств, а пока советуют удалять сертификаты вручную. И там и там бюллетень не выпущен, но рекомендации даны сотрудниками компании на форуме техподдержки.
Для устройств Fortinet инструкция по проверке и удалению сертификатов emSign опубликована здесь. В Palo Alto ограничились общими советами вместо конкретики по своим продуктам.
Конечно, верно и обратное. Правильно настроенный шлюз способен временно защитить устаревшие клиентские устройства, доверяющие опасным сертификатам.
Для проверки конкретных устройств, сервисов, контейнеров и виртуальных машин можно использовать специальный сайт, а возможный сценарий проактивного поиска угроз, эксплуатирующих или ранее эксплуатировавших слабые ключи, описан здесь.
Советы