Информационная безопасность

ЕЦБ экстренно собирает банки из-за ИИ, ломающего защиту за минуты

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

По информации Financial Times, регулятор обеспокоен новым поколением моделей вроде Claude Mythos, которые демонстрируют качественно иной уровень работы с кодом и системной архитектурой. Если раньше поиск 0-day уязвимостей требовал недель ручного аудита, то теперь ИИ справляется за минуты.

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

Для банковского сектора это критично. Финансовые системы строились десятилетиями, технический долг огромен, а миграция на новые стеки занимает годы. Многие core-системы всё ещё на COBOL и Java 8, где каждое изменение требует согласований и регрессионного тестирования. Скорость реакции физически не поспевает за скоростью обнаружения.

ЕЦБ, судя по всему, хочет понять масштаб угрозы и выработать общие меры. Возможные направления: ужесточение требований к мониторингу, обязательное использование runtime-защиты, пересмотр SLA на патчинг критических уязвимостей. Но главный вопрос остаётся открытым — можно ли вообще защищаться традиционными методами, когда противник на порядок быстрее.

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

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

Прятать данные в TLS-трафике: как выглядит настоящий стелс

Больше 70% интернет-трафика — зашифрованный TLS. Это не баг, это фича: тонны HTTPS-соединений, WebSocket-потоков, мобильных приложений и игровых клиентов создают идеальный фон для передачи данных без привлечения внимания.

Идея простая: если нужно спрятать дерево, прячь его в лесу. В случае интернета этот лес состоит из миллионов TCP/443-соединений, которые выглядят настолько обычно, что именно это делает их интересной средой для экспериментов.

Почему TLS-трафик — удобная маскировка

TLS скрывает содержимое пакетов. DPI может видеть метаданные — размер, timing, SNI в Client Hello, но не payload. Если ваше соединение выглядит как обычный HTTPS-запрос или долгоживущий WebSocket, оно сливается с фоном.

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

Где это может быть полезно

• Обход блокировок в странах с жёстким DPI — если трафик неотличим от обычного HTTPS, его сложнее фильтровать

• Распределённое хранилище данных в трафике — архивные данные можно держать не на диске, а в виде пакетов, циркулирующих между нодами

• Covert channels для исследований в области безопасности — тестирование систем мониторинга и обнаружения аномалий

Технические ограничения и риски

Главное ограничение — timing и packet size analysis. Если трафик выглядит нетипично по объёму или интервалам, статистические методы могут его вычислить. Traffic shaping помогает, но не решает проблему полностью.

Второе — легитимность. Если используешь чужую инфраструктуру или протоколы без согласия провайдера, это может нарушать ToS. В корпоративной среде такие эксперименты быстро привлекут внимание security-команды.

Третье — надёжность. Пакеты теряются, соединения рвутся, данные нужно восстанавливать. Без механизмов коррекции ошибок и redundancy хранилище в трафике превращается в лотерею.

В итоге: технически возможно, но требует продуманной архитектуры, понимания сетевых протоколов и готовности к тому, что решение будет хрупким. Как proof-of-concept — интересно. Как production-инструмент — сомнительно.

Представлен открытый ИБ-проект bumblebee от команды Perplexity для защиты ПК на Linux и macOS:

• проверяет файлы, установочные сборки, библиотеки, фреймворки

• сканирует пакетные менеджеры, плагины для IDE, браузерные расширения, конфиги Claude, Cursor, Coder и других ИИ‑инструментов.

• сканирует метаданные.

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

Толерантность - это допустимый уровень угроз и потенциального ущерба, который организация готова принять или, другими словами, насколько опасные сценарии для бизнеса считаются приемлемыми. Обычно Толерантность делят на 3 типа: высокая, средняя и, соответственно, низкая.

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

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

Ну а средняя толерантность говорит сама за себя - это уровень принятия ИБ где-то между: допускается принятие части рисков ради удобства, скорости работы или экономии ресурсов.

Риск-менеджмент - это процесс управления рисками информационной безопасности. После оценки угроз организация выбирает один из вариантов обработки риска:

• Принятие риска (Risk Acceptance)

• Отказ от риска (Risk Avoidance)

• Митигация риска (Risk Mitigation)

• Передача риска (Risk Transfer)

Принятие риска - это когда компания осознанно принимает риск и ничего не меняет. Например уязвимость имеет низкую вероятность эксплуатации (likelihood), устранение слишком дорого (cost-benefits analysis) или ущерб считается приемлемым. Отказ от риска - когда организация полностью убирает/устраняет источник риска. Например, отключение небезопасного сервиса, отказ от хранения персональных данных или закрытие внешнего доступа (часто OWA). Митигация риска (Risk Mitigation) - наиболее распространенный подход, когда компания снижает вероятность атаки или уменьшает последствия компрометации. Передача риска (Risk Transfer) - когда риск частично передается третьей стороне, например в применяется страхование, использование облачных провайдеров; аутсорсинг SOC или передача ответственности подрядчику.

Кроме локальной нормативной базы, которые регулируют некоторые критические сегменты, например ПДн или КИИ, компании вправе самостоятельно выбирать допустимость угроз и управление рисками. Однако, говоря про международные стандарты, нельзя не затронуть ISO/IEC 27005:2022 - Руководство по управлению информационной безопасностью, которое описывает идентификацию угроз, анализ рисков, оценку последствий, методы обработки рисков, подходы к принятию решений и другие вопросы риск-менеджмента. А Российский ГОСТ на базе ИСО 27005:2010 можно почитать в Электронном фонде правовых и нормативно-технический документов.

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Утечки данных в ритейле: онлайн-торговля вышла на первый план

Экспертно-аналитический центр InfoWatch опубликовал исследование «Утечки информации в сфере торговли, 2021-2025 гг.». В отчете специалисты ЭАЦ InfoWatch приводят статистику по инцидентам в мировом и российском ритейле за пять лет.

По итогам исследования:

• в мировой торговле зарегистрировано почти 5000 утечек данных, в России — 711 инцидентов;

• чаще всего утекают ПДн покупателей — более 11 млрд записей в мире и 610 млн в России;

• более половины инцидентов в России — это маркетплейсы и интернет-магазины.

Подробности на сайте InfoWatch.

РБПО по ГОСТ Р 56939—2024: вебинар №16 из 30 – Использование инструментов композиционного анализа

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.16. – "Использование инструментов композиционного анализа". На YouTube. Слайды.

Цели 16-го процесса по ГОСТ Р 56939—2024:

Создание условий для снижения рисков наследования уязвимостей и недекларированных возможностей при использовании заимствованного кода в коде ПО разработчика.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

ИИ не должен управлять исполнением. Заметки о детерминированном FSM-рантайме для агентов

Большинство рантаймов для ИИ-агентов сейчас работают по одному простому паттерну: LLM -> вызов инструмента -> рантайм выполняет сайд-эффект.

Для read-only задач это работает вполне сносно. Но как только агенты начинают мутировать внешнее состояние (платежи, базы данных, инфраструктуру, персональные данные), такая модель исполнения становится слишком сложной для операционного контроля и прогнозирования.

В процессе подготовки части наших внутренних агентов к деплою, мы пришли к необходимости полностью разделить процессы «рассуждения» (reasoning) и право на исполнение (execution authority).

Мы написали nano-vm — детерминированный FSM-рантайм (конечный автомат), в котором:

• модель лишь предлагает действия;

• рантайм жестко контролирует переходы состояний и сайд-эффекты.

Рантайм принудительно обеспечивает:

• конечные графы исполнения;

• строгий порядок шагов, зафиксированный при компиляции (compile-time ordering);

• capability-gating для инструментов (жестко изолированные доступы);

• границы идемпотентности и защиту от replay-атак;

• append-only историю аудита.

Одно из архитектурных решений, которое оказалось критически важным: слой политик намеренно сделан менее выразительным, чем Python.

Мы полностью отказались от eval-подобного исполнения и ограничили политики небольшим детерминированным подмножеством AST:

• только простые операторы;

• никаких циклов;

• никаких системных вызовов.

Это ограничение радикально упростило аудит и исключило целые классы рантайм-поведения, которые мы не хотели видеть в финансовых воркфлоу.

Sabotage Mode и семантика отказов

Чтобы протестировать семантику отказов, мы добавили в демо-стенд «Sabotage Mode» с несколькими векторами атак:

• неавторизованная инъекция инструментов (tool injection);

• попытки повторного выполнения (replay-атаки);

• подделка хешей (hash corruption);

• пропуск шагов пайплайна (skipped transitions).

С точки зрения эксплуатации самым полезным свойством пока оказались именно детерминированные границы повторного воспроизведения вокруг сайд-эффектов.

Нам также пришлось решать крайне неудобную compliance-проблему: как сохранить неизменяемые цепочки аудита (immutable audit chains) и при этом выполнить требования 152-ФЗ / GDPR об уничтожении данных. Наш текущий подход заменяет ссылки в хранилище на маркеры-надгробия (tombstones), полностью сохраняя криптографическую непрерывность хешей и ссылочную целостность графа.

В основном мне интересно, как другие инженеры решают проблему права на исполнение в stateful-агентах. Вы позволяете модели напрямую управлять сайд-эффектами или встраиваете детерминированный слой контроля между ними?

• Core runtime: github.com/Ale007XD/nano_vm

• MCP layer: github.com/Ale007XD/nano-vm-mcp

• Live Sabotage Demo: demo.bannerbot.ru:8843

Почему важно разбирать технический долг вовремя

Технический долг – это накопленные упрощения, устаревшие решения и несвоевременно устраненные проблемы в ИТ-системах. Это могут быть старые библиотеки, забытые сервисы и другие элементы, которые когда то были временными, но остались в продакшене.

В контексте SAST/DAST/SCA техдолг – это разница между тем, что инструмент нашел, и тем, что AppSec-инженер разобрал, а разработчик исправил. Из-за большого количества срабатываний аппсеки могут потерять реальные уязвимости.

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

Как рассчитывается

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

Почему нужно разбирать технический долг вовремя?

Спросили у инженера по информационной безопасности Swordfish Security Дениса Данилова, который помогает заказчикам разбирать технический долг в реальных проектах:

Очень часто после внедрения инструмента и первого сканирования проекта находится очень много срабатываний, на которые команда не может выделить время. Даже если аппсек разобрал все уязвимости и принёс только актуальные, разработчики сопротивляются и не хотят тратить на это время. В итоге уязвимости накапливаются и одна из них обязательно выливается в инцидент, который разработчики вынуждены чинить уже не планово, а с горящими сроками. Если же каждый спринт разбирать и исправлять хотя бы по одну уязвимость, внедрив это в процесс, разработчики не только сократят существующий техдолг, но и со временем придут к тому, что его появление значительно уменьшится. А появление нового техдолга будет ограничено механизмом Quality Gate.

💡 Советы эксперта:

• Регулярно обновляйте зависимости и убирайте устаревшие компоненты.

• Контролируйте и закрывайте временные доступы после использования.

• Проводите инвентаризацию сервисов и API.

• Рассматривайте технический долг как часть модели угроз.
  

Пароли Агентства по кибербезопасности США утекли в открытый доступ из-за подрядчика

 — Подрядчик Агентства по кибербезопасности и безопасности инфраструктуры США (CISA) до недавнего времени хранил в публичном репозитории GitHub учетные данные для доступа к внутренним системам ведомства, включая облачные ключи, токены и пароли в открытом виде

 ❗️ Исследователи в области кибербезопасности назвали инцидент одной из самых серьезных утечек данных в истории государственных структур США

В репозитории с названием Private-CISA находились административные данные для нескольких аккаунтов AWS GovCloud, а также файлы с именами пользователей и паролями от внутренних систем агентства

Эксперты также обнаружили, что владелец аккаунта отключил встроенную функцию GitHub, которая предотвращает публикацию секретных ключей и учетных данных

Этичный хакер

РБПО по ГОСТ Р 56939—2024: вебинар №15 из 30 – Обеспечение безопасности используемых секретов

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.15. – "Обеспечение безопасности используемых секретов". На YouTube. Слайды.

Цели 15-го процесса по ГОСТ Р 56939—2024:

Обеспечение безопасного использования секретов.

Примечание — В данном подразделе под секретами понимаются данные в любом виде, которые могут использоваться для обеспечения аутентификации и/или целостности и/или конфиденциальности информации (пароли, цифровые сертификаты и т. п.), в том числе путём применения в соответствии с законодательством Российской Федерации средств криптографической защиты информации или иными методами.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Приходите на вебинар — покажем, как выстроить резервное копирование, которому можно доверять

Бэкап есть почти у всех. Но одно дело — хранить копии, другое — быть уверенным, что при сбое инфраструктура поднимется в нужные сроки и без потерь. Как перейти от «копии существуют» к «восстановление работает»?

Разберем это на совместном вебинаре с экспертами Cloud.ru и оператором ИТ-решений ОБИТ. Будет полезно ИТ-директорам, директорам по ИБ, системным архитекторам, инженерам и администраторам — всем, кто отвечает за сохранность данных в облаке.

Что расскажем и покажем:

• какие практики резервного копирования актуальны сейчас и в чем их различия;

• почему классическая стратегия 3-2-1 на практике может не выполнять свою функцию;

• почему сторонний бэкап становится стандартом, а не опцией;

• как опыт интегратора влияет на результат — и что меняется, когда интегратор и вендор работают в связке;

• реальные кейсы: что именно это дает бизнесу.

В практической части пройдемся по интерфейсу SaaS-решения Cloud.ru. В прямом эфире покажем процесс восстановления машины из резервной копии через агента и разберем, как встроить решение в существующую инфраструктуру без глобальных переделок.

📅 Когда? 26 мая в 11:00 мск.

📍 Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам в прямом эфире.

Эхо из прошлого: ошибки архитектуры могут "выстрелить" спустя годы (благодаря WebArchive)

Представьте: 8 лет назад была небезопасная архитектура с IDOR. Т.е. можно было получить доступ к документу просто зная его ссылку. А ссылки чудным образом попали в WebArchive (он же - Wayback Machine). Спустя время архитектуру поменяли и проблема ушла. Но, WebArchive всё помнит: ссылки уже успели сохраниться. И кто-то, спустя многие годы, публикует статью с указанием ссылок на WebArchive, где указаны персональные данные и платёжки клиентов. Внимание, вопрос: успокоит ли общественность реакция в стиле: "да это давно было, сервиса уж нет"?

Вот один из сохранённых по ссылке документа: он сохранился в Wayback Machine в 2018 и до сих пор доступен.

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

Пару месяцев назад мне довелось поучаствовать в “контрольной закупке” одного из ювелирных магазинов. Обстоятельства были предельно ясные: в комментариях группы магазина в мессенджере Телеграмм стали писать боты и предлагать помощь с выбором украшения. При этом переписку старались перевести в личные сообщения, где уже и началось НЛП. Моя задача была определить, кто этим занимается и есть ли причастность сотрудников компании к данной схеме.

Ну что же, примеряем на себе образ “потенциального потерпевшего” и вступаем в переписку с ботом. Сначала меня игнорируют и недели 2-3 не выходят на связь, а потом долгожданное сообщение в … 4 часа утра! В каком часовом поясе живут лица по ту сторону экрана, я могу только догадываться.
Что было дальше, лучше почитать в прикрепленных скриншотах: как говорится, комментировать - только портить.

С учетом ограничений платформы на загрузку только 1 картинки, всю переписку можно прочитать у меня в группе Телеграм или Макс.

Однако при прочтении прошу обратить внимание на следующие аспе:

1. переписка велась с моего основного аккаунта, а “Виктория” даже не предприняла попытку установить, кто с ней общается и чем занимается;

2. адрес доставки и адрес склада совпадают, но у “Виктории” опять ничего не триггернуло;

3. описание банка, направленное “Викторией”, было сгенерировано ИИ не в ее пользу, так как “она” сама пишет: банк контролируется через иностранные компании и просьба не путать по написанию с другими банками. Но для “Виктории” главное, что офис находится в Москве :)

Естественно, что вся переписка велась при непосредственном контроле со стороны службы СБ заказчика. В качестве дополнительного “прогрева” были даже мысли “нарисовать” платежку с оплатой, но мысли о 327-й УК РФ не давали покоя, поэтому решили не рисковать. Ну и конечно, после окончания взаимодействия были уведомлены СБ Российских банков, где присутствовали счета указанных в переписке дропов.

В общем, как пели кот Базилио и лиса Алиса из кинофильма “Буратино”:

На дурака не нужен нож,
Ему с три короба наврёшь -
И делай с ним, что хошь!

Будьте аккуратны, берегите себя и своих близких.

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

Дела становятся еще детектнее, а запуск новой версии PT NAD 13.0 — еще ближе ☄️

Уже 4 июня, ровно в 14:00, команда системы поведенческого анализа сетевого трафика от Positive Technologies — PT NAD — прольет свет на каждый темный уголок вашей инфраструктуры в новом сезоне «Очень детектных дел» (отсылка не случайна).

В этот день вы сможете вместе с нами узнать, как поменяют правила игры:

• автоматизированное реагирование;

• облачное детектирование;

• архивное хранение метаданных.

Чтобы точно все это успеть, вот чек-лист ваших действий прямо сейчас:

1) Отменить все свои планы на 4 июня в 14:00

2) Зарегистрироваться на онлайн-запуск по ссылке

3) С нетерпением ждать встречи вместе с нами.

Увидимся уже скоро! Такие дела.

Сегодня n8n и Dify стали популярными инструментами для создания ИИ‑агентов, автоматизации процессов и интеграции с LLM. Однако при внедрении в крупном бизнесе компании сталкиваются с рядом вопросов: ИБ, отсутствие SLA, юридические ограничения, интеграция с корпоративной средой.

На вебинаре покажем, как использовать возможности n8n и Dify в Enterprise‑контуре с помощью платформы ROBIN — безопасно, легально и с полноценной технической поддержкой.

Обсудим:

• какие риски возникают при самостоятельном внедрении Open Source решений;

• как обеспечить соответствие требованиям ИБ и импортозамещения;

• как связать ИИ‑агентов с корпоративными системами и RPA;

• как использовать готовые коннекторы и автоматизировать процессы даже в системах без API;

• реальные кейсы: выставление счетов в 1С через Telegram‑бота (связка n8n + ROBIN) и интеллектуальный подбор оборудования с оформлением заказа в ERP (связка Dify + ROBIN).

Также расскажем о подходе ROBIN к поддержке и сопровождению внешних ИИ‑агентов в корпоративной среде.

20 мая, 11:00, онлайн, бесплатно, требуется регистрация.

Согласно проекту Zero Day ClockLive, с 2018 года значительно сократилось время от выявления уязвимостей в ПО до начала их активной эксплуатации в продуктивных системах (дельта между публичным раскрытием CVE и первым подтверждённым случаем эксплуатации в реальных условиях).

РБПО по ГОСТ Р 56939—2024: вебинар №14 из 30 – Управление доступом и контроль целостности кода при разработке программного обеспечения

Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.

Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.14. – "Управление доступом и контроль целостности кода при разработке программного обеспечения". На YouTube. Слайды.

Примечание. Во время демонстрации работы GitFlic с PVS-Studio часть срабатываний не попала в SARIF-отчёт, потому что при запуске утилиты plog-converter не был указан флаг -a. Без него утилита включает в отчёт только срабатывания диагностических правил общего назначения уровней 1 и 2. Чтобы сохранить все срабатывания из исходного отчёта, нужно передать флагу -a значение ALL. Подробнее о флагах утилиты plog-converter можно прочитать в нашей документации.

Цели 14-го процесса по ГОСТ Р 56939—2024:

Обеспечение управления доступом к исходному коду и его целостности.

Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.

Dirty Frag (CVE-2026-43284, CVE-2026-43500): Логи, артефакты и правило корреляции

Dirty Frag — это случай, расширяющий класс ошибок, к которому относятся Dirty Pipe и Copy Fail. Поскольку это детерминированная логическая ошибка, не зависящая от временного окна, она не требует состояния гонки, ядро не аварийно завершает работу в случае неудачного эксплойта, а вероятность успеха очень высока

Подробнее можно ознакомиться тут и тут

Пример логов:

<14>2026-05-13T07:46:45.247707+03:00 test_serv auditdrecord: type=MAC_IPSEC_EVENT msg=audit(1778647605.244:144825): op=SAD-delete auid=4294967295 ses=4294967295 src=127.0.0.1 dst=127.0.0.1 spi=3735928356(0xdeadbe24) res=1 AUID="unset"

<14>2026-05-13T07:46:41.600544+03:00 test_serv auditdrecord: type=MAC_IPSEC_EVENT msg=audit(1778647601.596:144762): op=SA-icv-failure src=127.0.0.1 dst=127.0.0.1 spi=3735928360(0xdeadbe28) seqno=200

Итак, с точки зрения защиты нам нужно выявить основные паттерны эксплуатации данного LPE:

1. События IPsec/XFRM в auditd:
Ключевой auditd-артефакт для Dirty Frag - событие c type=MAC_IPSEC_EVENT

Это событие появляется при операциях с IPsec Security Association Database, то есть при создании, удалении или ошибках обработки Security Association. Наиболее интересные значения op:
SAD-add - добавление Security Association;
SAD-delete - удаление Security Association;
SA-icv-failure - ошибка проверки целостности IPsec-пакета.

2. Подозрительный SPI
В публичном PoC для Dirty Frag используется характерный диапазон SPI:
0xdeadbe10, 0xdeadbe11, 0xdeadbe12 ... 0xdeadbeXX

3. Loopback-трафик src=127.0.0.1, dst=127.0.0.1
Это связано с тем, что эксплуатация происходит локально: атакующему не нужен внешний сетевой трафик, он прогоняет специально подготовленные ESP/UDP-пакеты через loopback.

4. Пачка однотипных событий за короткий промежуток времени
Dirty Frag - не одиночное событие. В публичном PoC создаётся серия XFRM SA, по одной на каждый 4-байтный фрагмент записи в page cache. Поэтому вместо одного события обычно будет наблюдаться серия:
SAD-add
SAD-delete
SA-icv-failure
в течение короткого промежутка времени.

Правило корреляции для KUMA:
Время жизни контейнера: 300 сек
Порог срабатывания: 10+ событий

DeviceProduct = 'auditd' AND DeviceEventClassID = 'MAC_IPSEC_EVENT' AND (FlexString2 = ['SAD-add', 'SA-icv-failure', 'SAD-delete'] OR Extra.spi contains '0xdeadbe') AND SourceAddress = '127.0.0.1' AND DestinationAddress = '127.0.0.1'

Среди специалистов по информационной безопасности ходит довольно смешной и жизненный мем:

Я инфобезник, поэтому:
• у меня нет социальных сетей
• у меня нет умных устройств
• я не сохраняю пароли в браузере
• я не использую автозаполнение
• все замки исключительно механические
• я заклеиваю веб-камеры на всех используемых устройствах
• не подключаюсь к публичным Wi-Fi
• не кликаю на ссылки • …

Этот список можно продолжать бесконечно, но в каждой шутке, как известно, есть только доля шутки. И ведь действительно, если посмотреть со стороны на свою цифровую жизнь, то можно увидеть, что:
• у меня дома нет умных колонок (только трофейная Маруся, выжившая после проведенных тестирований)
• никаких умных дверных ручек (спасибо, уже пентестили)
• я не знаю свои пароли (потому что они все разные, длиной в 30-40 символов, сгенерированные случайным образом, содержащие все 4 составляющие и хранящиеся специальным образом)
• по возможности использую 2FA (нет, я не параноик, просто соблюдаю минимальную цифровую гигиену)
• не подключаюсь к сторонним Wi-Fi (у меня безлимитный мобильный интернет, поэтому даже и смысла нет в лишних телодвижениях)
• по ссылкам хожу только через режим инкогнито (да и в принципе, почти все вирусы только на Windows, так что тут не страшно)
• а “набитая рука” на фишингах помогает определить зловредное письмо по первым словам заголовка (да, пранки с РикРоллами научили нас не кликать по подозрительным ссылкам лучше, чем повышение осведомленности со стороны ИБ ;)

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

А какие привычки цифровой гигиены используете вы и почему? Делитесь своими советами - давайте проведем внеплановое повышение осведомленности aka awareness!

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

п.с. прошу прощения, если видео было просмотрено на максимальной громкости, не в наушниках и рядом с колонкой Алисы ;)

В России меньше трети компаний страхуют киберриски

Экспертно-аналитический центр ГК InfoWatch выпустил исследование в «Ущерб от утечек информации и страхование». В нем говорится, что риски киберинцидентов застрахованы менее чем у трети российских компаний (28%), при связанные с подобными происшествиями риски страхуют лишь 15,7% компаний.

Кроме того:

• штрафы за утечки данных и возможные убытки от выплат вымогателям в России законодательно страховать запрещено;

• умышленные действия сотрудников не входят в большинство полисов киберстрахования;

• проблема рынка киберстрахования — сложности с оценкой ущерба от утечек, единой методики не существует.

Подробности на сайте InfoWatch.