Безопасно говоря

Остановили кибератаки и снизили финансовые риски для «Энджой Рисёч».

Компания «Энджой Рисёч» разрабатывает ПО и проводит маркетинговые исследования в России и странах СНГ.

Ситуация. Oдин из сервисов «Энджой Рисёч» несколько дней атаковал злоумышленник.

Он пытался войти с разных IP-адресов, используя купленные базы логинов и паролей, и предпринимал более чем 100 тыс. попыток взлома в час.

Атака продолжалась несколько дней. Из-за неё нагрузка на сервис выросла в 200 раз. Требовалось срочно найти инструмент для защиты от кибератак и фильтрации трафика.

Было важно:

🔵 комплексное решение, а не набор отдельных инструментов

🔵 отсутствие затрат на инфраструктуру и обслуживание

🔵 быстрое реагирование на критические инциденты

Мы за несколько часов подключили Yandex Smart Web Security — сервис для защиты сайтов и приложений от DDoS-, веб-атак и ботов.

Подробности — в карточках ⬆️⬆️⬆️

⏩ Как защитить кластеры Kubernetes® от уязвимостей Linux Copy Fail и Dirty Frag с помощью фиксов и модуля Контроль Kubernetes® (KSPM) в Yandex Security Deck.

Об этих уязвимостях Linux.

Copy Fail CVE-2026-31431 — уязвимость ядра Linux. Позволяет неавторизованному пользователю получить root-права на всех основных дистрибутивах Linux, выпущенных с 2017 года.

Dirty Frag позволяет получить права root в основных дистрибутивах Linux — она объединяет уязвимости записи в страничный кэш xfrm-ESP (CVE-2026-43284) и RxRPC записи в страничный кэш (CVE-2026-43500).

Статус уязвимостей — мы оперативно обновили все инфраструктурные конфигурации Yandex Cloud.

Используйте runtime-политики, которые мы добавили в модуль KSPM Yandex Security Deck.

Кратко, что сделать:
🔺 Установить на все кластеры K8s фикс из поста.

🔺 Включить для критичных кластеров K8s модуль KSPM.
➡️ Подробнее о включении SD
➡️ Как активировать KSPM

🔺 Включить набор требований Microsoft Threat Matrix for Kubernetes.

Он включает в себя runtime-политики по обнаружению попыток эксплуатации Copy Fail и Dirty Frag.

Попробовать ⏩

Не принимаем новые OAuth‑токены, полученные через Яндекс ID — с 1 июня 2026 года.

Рассказываем, каких именно OAuth‑токенов коснется решение, почему мы его приняли и как перейти на безопасные альтернативы.

*️⃣ Старые OAuth‑токены, выданные до 1 июня 2026 года действуют до окончания своего срока.

Изменения касаются только OAuth‑токенов, выданных для доступа к Yandex Cloud по процедуре, описанной в инструкции по получению OAuth-токена.

Токены для других сервисов Яндекса, включая Яндекс 360, это не затрагивает.

Причина — использование персонального OAuth‑токена в инфраструктурных и автоматизированных сценариях несёт дополнительные риски безопасности.

📍 Почему мы считаем OAuth‑токены менее предпочтительными:

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

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

Сложности контроля. Владельцы организаций не могут прозрачно отследить использование таких токенов с помощью Audit Trails.

Риск скрытого создания. При компрометации учётной записи Яндекс ID злоумышленник может незаметно создать OAuth‑токен и использовать его для закрепления в облачной инфраструктуре.

Чем заменить OAuth‑токены и как перейти на альтернативы подробно рассказываем в блоге⏩

Всё самое главное о продуктах и инструментах ИБ Yandex Cloud за апрель собрали в карточках⬆️⬆️⬆️

Что ещё было классного? Конечно, Cloud Security Day!

⏩
Здесь можно посмотреть записи докладов.
А в этом посте — фото.

Также в апреле рассказали, как сделать из ИИ-агента доверенного члена команды ИБ.

Об этом написал Сергей Нестерук — он отвечает за безопасность применения искусственного интеллекта в Yandex Cloud.

👍 — если собирать для вас такой дайджест новостей каждый месяц

⚡️ Закрываем свежую уязвимость в ядре Linux

Copy Fail (CVE-2026-31431) — это логическая уязвимость в подсистеме криптографического API ядра Linux, позволяющая обычному пользователю системы получить права суперпользователя (root). PoC работает на всех основных дистрибутивах Linux, выпущенных с 2017 года и до момента выхода патча, без модификаций под конкретное ядро или дистрибутив.

Атака:

🔺 не требует удалённого доступа — только непривилегированный локальный аккаунт;

🔺не требует ни race window, ни kernel-specific смещений;

🔺 использует крипто-API ядра (AF_ALG), который включён в дефолтных конфигурациях практически всех мейнстрим-дистрибутивов;

🔺 может быть использована как примитив побега из контейнера на хост, поскольку page cache общий для всего узла.

Вектор атаки и уровень опасности согласно CVSS v.3.1

Базовая оценка: 7,8 HIGH

Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Подробное описание атаки в блоге →

Затронутые технологии:

▶️ ядро Linux, подсистема crypto/ (модуль algif_aead);

▶️ интерфейс пользовательского пространства AF_ALG;

▶️ системный вызов splice() в связке с сокетами AF_ALG.

Уязвимыми являются ядра Linux, собранные в интервале с 2017 года (момент внедрения in-place оптимизации algif_aead) до момента включения исправляющего патча мейнлайна.

Поскольку модуль algif_aead входит в дефолтную конфигурацию ядра большинства дистрибутивов, эксплуатация возможна «из коробки».

Уязвимость напрямую не затрагивает следующие пути использования крипто-API: dm-crypt / LUKS, kTLS, IPsec/XFRM, in-kernel TLS, OpenSSL/GnuTLS/NSS в дефолтных сборках, SSH, kernel keyring crypto. Все они работают с in-kernel crypto API напрямую и не проходят через AF_ALG.

🔵Сайт уязвимости
🔵Технический разбор Xint Code (Theori)
🔵PoC и issue tracker

Рекомендации по обнаружению уязвимости:

⏩ Отключить модуль algif_aead до установки патча ядра.

Команда выполняется от имени root и применяется немедленно. Новые сокеты AF_ALG создаваться не смогут, ранее открытые — продолжат работать до закрытия.

 # echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
   # rmmod algif_aead 2>/dev/null || true

⏩ Обновить ядро до версии, содержащей патч.

Уязвимость:

🔵присутствует в ядрах с 4.14 (commit 72548b093ee3, 2017 год)

🔵 устранена в следующих релизах:

✓6.18.22 (стабильная ветка) — commit fafe0fa2995a

✓6.19.12 (стабильная ветка) — commit ce42ee423e58

✓7.0-rc7 (мейнлайн) — commit a664bf3d603d

Для контейнерных и sandbox-нагрузок целесообразно блокировать создание сокетов AF_ALG через seccomp независимо от состояния патчей.

Влияние на сервисы Yandex Cloud

Обновили конфигурации инфраструктуры Yandex Cloud для применения митигирующих мер.

🔔Пользователям сервиса Yandex Managed Service for Kubernetes® нужно самостоятельно применить митигирующую меру на узлах своих кластеров. Для этого опубликован DaemonSet, который отключает модуль algif_aead.

Применение выполняется штатной командой:

$ kubectl apply -f copy-fail-mitigation-daemonset.yaml

Актуальные версии образов в Yandex Cloud Marketplace, содержащие митигирующие меры, готовим к публикации.

📍 Если вам нужна дополнительная информация, пожалуйста, напишите на cloudtrust@yandex-team.ru.

👍 — спасибо, было полезно

💻 Разработали архитектуру безопасной и удобной мультирегиональности

Сама по себе мультирегиональность существовала в облаках и до нас. Но когда мы запускали Yandex Cloud в Казахстане, перед нами встала сложная инженерная дилемма: как сделать управление ресурсами в разных регионах удобным, сохранив их полную независимость?

⏪️ Привет! На связи Антон Дедов, архитектор функций безопасности IAM в Yandex Cloud. Традиционные провайдеры либо заставляют заводить отдельную организацию для каждого региона (безопасно, но жутко неудобно), либо делают один административное пространство на все регионы (удобно, но если произойдёт инцидент безопасности в одном регионе, то он может задеть и другие регионы).

Я и мои коллеги Аркадий Вязников, Владислав Архипов и Евгений Сидоров решили, что компромиссы не для нас, и разработали принципиально новый подход. А недавно и получили на него патент. Самое главное о технологии — в карточках, а подробности — в статье⏩️.

⚡️ — заслуженный патент всей команде!

➡️ Давайте разрабатывать такие решения вместе?