Отшумели летние дожди: почему история с eMudhra только начинается

Отшумели летние дожди: почему история с eMudhra только начинается

Шума вокруг скомпрометированных сертификатов eMudhra хватило на неделю. Посмеялись над версией про ошибку в скрипте, «обновили корневые сертификаты» и вернулись к автоматизациям в n8n. Ключ от инференса остался лежать в переменных окружения.

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

Что на самом деле случилось

В апреле 2025 года удостоверяющий центр eMudhra выпустил восемь промежуточных сертификатов с ключами P-384. Причиной стал баг скрипта. Значения ключей оказались меньше 256, поэтому их можно восстановить перебором пары сотен вариантов. Один ключ имел значение буквально «4».

Исследователь нашёл проблему 17 октября 2026 года, сканируя публичные данные о сертификатах. PoC-ключ опубликовали на GitHub. eMudhra отозвала все восемь сертификатов и остановила выпуск под корнем G3. В день раскрытия Mozilla, Google и Apple заблокировали цепочки (пересказ).

Следов злоупотребления не нашли. Обратите внимание на формулировку: скомпрометировали промежуточные сертификаты, а не корневые. Корень жив до сих пор.

Почему браузеры спаслись, а ваш контейнер нет

Браузеры умеют получать блок-листы удалённо. Mozilla добавила сертификаты в OneCRL, и Firefox защитился без обновления и перезапуска.

У контейнера с n8n, самописной CRM или скриптом сводок такой защиты нет. Python requests, Go-клиент и SDK инференс-API проверяют цепочку до доверенного корня. Для них цепочка от живого корня G3 через отозванный промежуточный сертификат остаётся валидной.

CRL, OCSP и OneCRL такие клиенты обычно вообще не проверяют. А CA-бандл в образе заморожен на момент сборки. Он продолжит доверять этому корню, пока образ не пересоберут.

Окно уязвимости открыто с апреля 2025 года. Сообщение в блоге удостоверяющего центра его не закроет.

Кто такая жертва: shadow AI

Жертва здесь shadow AI: так называют использование ИИ-инструментов, агентов и самописных автоматизаций без ведома и одобрения ИТ и службы безопасности.

Классический shadow IT опасен тем, что программа живёт вне учёта. shadow AI опаснее: он принимает решения, пишет код и уносит данные в промптах.

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

Ключи от Jira, почты и wiki остаются долгоживущими: «это же просто эксперимент». За живостью сертификатов, свежестью образов и ротацией секретов не следит ни один инженер. Эксперимент три года живёт в проде.

Масштаб подтверждают цифры из отчёта GitGuardian State of Secrets Sprawl 2026. За 2025 год в публичном GitHub нашли 29 миллионов новых захардкоженных секретов. На 34% больше, чем годом ранее, и рекорд за всё время наблюдений.

Утечки ключей к AI-сервисам выросли на 81%, до более чем миллиона за год. Восемь из десяти самых быстрорастущих категорий утечек связаны с AI-инфраструктурой: API поиска, оркестраторы и управляемые бэкенды. Внутренние репозитории содержат секреты в 32.2% случаев, это в шесть раз чаще, чем публичные.

А 28% утечек происходят вообще мимо кода. Ключами делятся в Slack и Jira, причём больше половины таких утечек критичны.

Сложим всё вместе: ключ от инференса лежит в переменных контейнера, контейнер собирают один раз и больше не обновляют, а промпт несёт сводку по всем корпоративным источникам. Готовый маршрут для атаки.

shadow AI: масштаб в цифрах

shadow AI уже не редкость. По опросу PagerDuty за 2026 год, 66% офисных сотрудников пользуются на работе ИИ-инструментами, которые сами считают запрещёнными. 68% руководителей служб безопасности, включая CISO, признают, что неавторизованный ИИ используют и в их рабочих процессах.

79% ИТ-руководителей говорят, что их организация уже пострадала от передачи корпоративных данных ИИ-инструментам. Gartner прогнозирует: к 2030 году более 40% организаций столкнутся с инцидентами безопасности или несоответствием из-за неавторизованных ИИ-инструментов.

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

Есть и важное отличие от классического shadow IT. Программа с протухшим сертификатом просто падает. Теневой ИИ-харнес продолжает работать, принимать решения и отдавать их наружу.

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

Эта дорога уже исхожена

Такое случалось не раз. В 2011 году голландскую компанию DigiNotar взломали целиком. В сети обнаружили больше пятисот поддельных сертификатов на крупнейшие домены. Подделкой для Google действительно пользовались, чтобы читать почту людей в Иране (разбор). Через несколько недель после раскрытия компания обанкротилась.

В 2012 году Trustwave выдала клиенту подчинённый центр, предназначенный для перехвата чужого трафика. В 2015-м китайский CNNIC выпустил несанкционированный промежуточный сертификат. С его помощью перехватывали корпоративный трафик.

В 2017-2018 годах Mozilla и Chrome постепенно отключили Symantec за тысячи неверных выпусков. Так закончилась история крупнейшего удостоверяющего центра интернета.

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

Механика вектора

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

Такую позицию может дать прокси, VPN-шлюз, вышестоящий хостинг или DNS. Всё это атакующий получает оптом, а не настраивает под конкретную компанию. И это не единственный канал, по которому корпоративные диалоги с нейросетями уходят наружу: мы уже разбирали, кто их читает и зачем (PRISM, FISA и твои промпты).

Дальше он подделывает сертификат для домена инференс-API и ставит прозрачный прокси к настоящему апстриму. Ответы остаются честными: их выдаёт настоящая модель. Канарейки по качеству молчат, а атакующему достаётся весь поток промптов со сводками по корпоративным источникам и API-ключ жертвы.

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

Отдельная деталь для наших компаний: корпоративные хранилища доверия с национальными корнями шире международного набора. Каждый дополнительный доверенный корень создаёт ещё одну ось компромисса. Её никто не аудирует.

Что делать, чеклист на вечер

• Направляйте весь внешний инференс через собственный egress-прокси. Настройте пиннинг апстримов и allowlist доменов. Это единая точка, где возможен контроль.
• Храните ключи не в переменных контейнера, а в хранилище с ротацией и коротким TTL.
• Запустите канареечную задачу по расписанию. Используйте фиксированные промпты, temperature 0 и известные эталонные ответы. Расхождение станет сигналом MITM или тихого смещения.
• Задайте SLA на свежесть образов. Сверяйте дату сборки и версию ca-certificates с датой последнего CA-инцидента.
• Мониторьте Certificate Transparency для своих доменов. Настоящий сертификат попадает в логи, поддельный нет.
• Для чувствительных решений используйте локальный инференс. Только так вопрос доверия к цепочке исчезнет вместе с самим каналом. Как это выглядит на практике, мы показывали на примере закрытого контура с локальным зрением (Локальное зрение для Hermes Agent в закрытом контуре).

Вместо вывода

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

Вопрос не в том, случится ли перехват. Вопрос в том, чей контейнер окажется за ним в этот раз.

Методология: факты инцидента сверены с отчётом Mozilla в пересказе comss.ru от 22.10.2026. История CA проверена по открытым источникам: DigiNotar, более пятисот подделок и банкротство в 2011 году. Статистика GitGuardian State of Secrets Sprawl 2026 приведена по пересказу The Hacker News от 30.03.2026. Разбор вектора это модель угроз, а не инструкция: эксплуатационных деталей здесь нет и не будет. Чувствительное в наших проектах считается локально, поэтому мы рекомендуем такой контур для чувствительных задач.