Экстраординарные события последних недель не отменяют необходимость работать над безопасностью продуктов и быстро адаптироваться к новым угрозам.

Одной из таких новых угроз стала компрометация сертификатов eMudhra — удостоверяющего центра с почти двадцатилетней историей, которому доверяли Apple, Google, Microsoft и Mozilla, а вместе с ними — браузеры, приложения и устройства по всему миру.

Сегодня расскажем, что известно о компрометации eMudhra, чем она грозила пользователям и как мы реагировали на угрозу, чтобы защитить их, — в том числе на Яндекс Станциях.

Большой переполох со слабыми ключами

17 октября исследователь под псевдонимом Wayne сообщил разработчикам браузеров, что смог вычислить (!) закрытые ключи восьми промежуточных удостоверяющих центров eMudhra. Для этого ему хватило открытых сертификатов. В доказательство Wayne подписал каждым из восьми ключей сообщение «We have a problem here - Wayne».

Вообще-то вычислить закрытый ключ по открытому должно быть практически невозможно: при правильно созданном ключе на это потребовался бы непосильный объём вычислений. Но здесь закрытые ключи оказались числами от 1 до 255. Можно просто перебрать все варианты, вычислить для каждого открытый ключ и сравнить с тем, который опубликован в сертификате. Всего 255 проверок.

Чем это опасно? Если злоумышленник получает возможность подписывать поддельные сертификаты ключом авторитетного удостоверяющего центра, то он может использовать их в атаке «человек посередине» (MITM), чтобы читать и изменять данные HTTPS-соединения.

По первоначальному объяснению eMudhra, сначала ключи создали штатным способом в аппаратных модулях безопасности — HSM. Их планировали перенести на площадки в США и Европе. Для такого переноса ключи нужно выгрузить из одного модуля в защищённом, зашифрованном виде, а затем загрузить в другой. В процедуру создания ключей добавили проверку этих операций — упаковки и распаковки. Компания связывает появление второго, слабого набора с ошибкой в этом скрипте. Из-за похожих меток два набора перепутали, и в запросы на выпуск сертификатов попали открытые ключи из слабого набора. Сертификаты для них выпустила сама eMudhra, а затем и Sectigo — другой удостоверяющий центр. Так у клиентов появилось два пути доверия к одним и тем же слабым ключам: через eMudhra и через Sectigo.

В июне 2025 года Sectigo заметила ошибки при проверке подписей eMudhra. Как компания объяснила позднее, документы подписывали исходными ключами, хотя сертификаты центров уже были выпущены для второго, слабого набора. В eMudhra переключились на этот второй набор, и подписи стали проходить проверку. Так несовпадение устранили, но слабые ключи остались в использовании. При этом в июньском отчёте о слабости ключей не говорилось. Почему обнаруженное несовпадение не привело к выявлению слабости ключей ещё тогда — один из открытых вопросов сообщества. Но главный вопрос остаётся: как ошибка в скрипте привела к появлению закрытых ключей со значениями от 1 до 255? В eMudhra пообещали опубликовать подробный отчёт, так что будем ждать.

Нельзя просто так взять и отозвать сертификаты

Вернёмся к хронологии событий. 18 октября eMudhra отозвала восемь сертификатов скомпрометированных промежуточных центров. 19 октября Sectigo сообщила о завершении отзыва выданных ею перекрёстных сертификатов этих же центров. Параллельно распространялись блокировки в браузерах: с 17 по 20 октября обновлённые списки уязвимых сертификатов долетели до Chrome, Firefox, Safari, Яндекс Браузера и Edge.

Обновления потребовались и операционным системам. В ночь с 19 на 20 октября Google начала блокировать опасные сертификаты на Android через обновление Google Play Services. 20 октября вышли новые версии пакетов доверенных сертификатов для Ubuntu и Debian (если на сервере было включено автообновление, исправления установились без участия пользователя).

С 21 по 23 октября мы обновили все активные Яндекс Станции и абсолютное большинство партнёрских устройств. Подробнее о том, как мы это сделали, расскажем в следующей главе.

24 октября Valve выпустила исправление в обновлении SteamOS для Steam Deck.

Волна обновлений затронула и инструменты разработчиков. 20 октября обновился Go, 21-го — Node.js, 24-го — Oracle Java 8. 25 октября вышли экстренные обновления интерпретатора Python — блокировку встроили в его стандартный модуль ssl. 26 октября в Julia обновили встроенный набор доверенных сертификатов.

Сертификаты eMudhra обнаружили и в других устройствах — например, в прошивках колонок Sonos и телевизора Samsung. А владелец камеры Sony сообщил, что использовал уязвимость для подмены магазина приложений Sony и получил root-доступ к камере.

Что произошло со Станциями

Скомпрометированные сертификаты позволяли провести MITM-атаку и подменить конфигурацию, которую Станция получала с нашего сервера. Именно так энтузиасты включили на колонке ADB — служебный интерфейс для диагностики и отладки устройства. Мы используем его как в разработке, так и в сервисных целях для диагностики редких неисправностей. Через него энтузиасты смогли подключиться к личным колонкам с правами root.

Энтузиасты организовали MITM для своей Станции и получили желаемый результат. Но ту же уязвимость можно было использовать против воли пользователя — например, для перехвата данных или атак на другие устройства в локальной сети. Для этого злоумышленнику понадобилось бы сначала получить контроль над трафиком Станции, например предварительно взломав роутер пользователя.

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

У нас миллионы активных Яндекс Станций — то есть тех, которыми регулярно пользуются. С 21 по 23 октября мы обновили все эти устройства и абсолютное большинство партнёрских устройств.

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

Как проверить свои приложения и сервисы

Уязвимость может затрагивать и другие ваши приложения, сервисы и устройства. Ниже — несколько советов, с чего начать проверку.

Браузеры

Откройте страницу проверки и запустите тест. Он попробует подключиться к серверам с сертификатами, подписанными скомпрометированными ключами. Если появилась строка Insecure, браузер принял опасный сертификат. Обновите браузер и повторите проверку.

Виртуалки

Проверить соединения с компьютера или сервера можно с помощью curl — инструмента для отправки сетевых запросов из терминала. Результат относится только к самому curl, а не ко всем установленным программам. Для проверки виртуалки или контейнера запустите команды внутри них.

Ниже все 14 адресов теста. Этот блок можно целиком скопировать в терминал:

for url in \
  https://dv-g3b-emudhra.we-have-a-problem.com/ \
  https://dv-g3c-emudhra.we-have-a-problem.com/ \
  https://ov-g3b-emudhra.we-have-a-problem.com/ \
  https://ov-g3c-emudhra.we-have-a-problem.com/ \
  https://ev-g3b-emudhra.we-have-a-problem.com/ \
  https://ev-g3c-emudhra.we-have-a-problem.com/ \
  https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ \
  https://dv-g3c-aaa-emudhra.we-have-a-problem.com/ \
  https://ov-g3b-aaa-emudhra.we-have-a-problem.com/ \
  https://ov-g3c-aaa-emudhra.we-have-a-problem.com/ \
  https://ev-g3b-aaa-emudhra.we-have-a-problem.com/ \
  https://ev-g3c-aaa-emudhra.we-have-a-problem.com/ \
  https://dv-g3b-noct-emudhra.we-have-a-problem.com/ \
  https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/
do
  printf '\n%s\n' "$url"
  curl --connect-timeout 10 --max-time 20 "$url"
done

Если в ответе появилось Your client successfully connected to the site, curl принял опасный сертификат. Ожидаемый результат — отказ из-за недоверенного сертификата.

Для обновления доверенных сертификатов и связанных библиотек в Ubuntu выполните:

sudo apt-get update
sudo apt-get install --only-upgrade ca-certificates 'libnss3*'

Исправленная версия ca-certificates для Ubuntu 22.04 — 20260816ubuntu0.22.04.1, для 24.04 — 20260816ubuntu0.24.04.1, для 26.04 — 20260816ubuntu0.26.04.1, для 26.10 — 20260816ubuntu0.26.10.1 — или новее.

Если приложение работает в Docker, обновите пакет ca-certificates внутри его образа, пересоберите образ и запустите из него новые контейнеры. Обновление самого сервера эту проблему внутри контейнеров не исправит.

Приложения и сервисы

У приложений могут быть собственные хранилища сертификатов. Например, Python-приложение может использовать пакет certifi, а Java-сервис — отдельное хранилище. Поэтому обновления системных пакетов бывает недостаточно. Дополнительные действия для Java в Ubuntu описаны в инструкции Ubuntu.

Чтобы проверить приложение, отправьте запросы к тестовым адресам из его рабочего окружения, используя ту же библиотеку и настройки, что и при обычной работе. Например, если приложение отправляет запросы через requests, используйте её и для проверки. 

Если всё это звучит сложно, попробуйте хотя бы обновить все доступные компоненты до актуальных версий.

Сертификат вашего сайта

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

Умные устройства

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

Удостоверяющий центр eMudhra работал с 2008 года (после инцидента компания решила прекратить выпуск сертификатов для сайтов). Его сертификатам доверяли все крупнейшие IT-компании в мире. Но это не защитило от простой ошибки, которая оставалась незамеченной полтора года. К счастью, о компрометации публично доверенных удостоверяющих центров мы слышим нечасто. Один из самых известных прецедентов — взлом DigiNotar в 2011 году, около 15 лет назад. А около девяти лет назад, в 2017 году, Google объявил об отказе от доверия к прежней инфраструктуре Symantec из-за систематических нарушений правил выпуска сертификатов.

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