Согласно проекту 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-addSAD-deleteSA-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.
Тысячи сайтов на cPanel скомпрометированы через одну уязвимость — и атакующие работали незаметно шесть лет до этого всплеска.
По данным SecurityLab, за недавней волной взломов стоит не случайный скрипт-кидди, а организованная группа с многолетним опытом. Шесть лет — это не оговорка. Столько времени они оставались в тени, прежде чем атаки стали заметны.
Что случилось с cPanel. cPanel — это панель управления хостингом, которую используют сотни тысяч веб-серверов по всему миру. Уязвимость в ней позволяла получить доступ к серверу без логина и пароля. Никакого брутфорса, никакой социальной инженерии — просто прямой вход через дыру в аутентификации.
Детали уязвимости в исходном материале не раскрываются — ни CVE-номера, ни версии, ни механизма. Это важная оговорка: оценить реальный масштаб риска без этих данных сложно. Но факт массовых компрометаций зафиксирован.
Почему шесть лет — это тревожнее самого взлома. Долгое присутствие в тени говорит об одном: группа умела не шуметь. Это не сканирование Shodan и немедленная эксплуатация — это терпеливая работа с избирательными целями. Когда такая группа всё же «засвечивается», обычно это означает либо смену тактики, либо намеренный переход к масштабированию.
Для владельцев хостинг-инфраструктуры и тех, кто держит сайты на shared-хостинге с cPanel, вопрос сейчас не «взломают ли», а «не взломали ли уже». Следы присутствия профессиональной группы могут быть нечитаемы стандартными средствами мониторинга.
Проверить версию cPanel и наличие последних обновлений безопасности
Поднять логи аутентификации за последние недели — аномальные входы без учётных данных
Проверить целостность файлов на сервере (особенно конфиги и веб-шеллы)
Если хостинг управляемый — запросить у провайдера подтверждение патча
Атаки через панели управления хостингом — это удар сразу по всем сайтам на сервере, а не по одному. Один уязвимый сервер cPanel — это потенциально десятки и сотни скомпрометированных проектов одновременно. Масштаб инцидента определяется не числом серверов, а числом сайтов на них.
Пока нет публичного CVE и технического разбора, сложно говорить о полной картине. Но шесть лет незаметной работы — это уже достаточный аргумент, чтобы не откладывать проверку на потом.
Microsoft майским Patch Tuesday закрыла 120 уязвимостей — 17 критических, 14 из которых позволяют удалённо выполнить код. Нулевых дней нет, но расслабляться рано.
По данным Anti-Malware от 13 мая 2026 года, в майском пакете обновлений Microsoft исправила 120 уязвимостей. Структура по типам: 61 — повышение привилегий, 31 — удалённое выполнение кода, 14 — раскрытие информации, 13 — подмена, 8 — отказ в обслуживании, 6 — обход защиты.
Отсутствие 0-day — хорошая новость. Плохая — три уязвимости из критических заслуживают отдельного внимания, и они не абстрактные.
Три CVE которые стоит закрыть первыми. CVE-2026-35421 — уязвимость в Windows GDI. Эксплуатируется через вредоносный EMF-файл, открытый в Microsoft Paint. Да, в Paint. Звучит несерьёзно, пока не вспоминаешь, сколько пользователей открывают вложения именно там.
CVE-2026-40365 — SharePoint Server. Аутентифицированный злоумышленник может удалённо выполнить код на сервере через сетевую атаку. Для корпоративной среды это прямой путь к данным и внутренним сервисам.
CVE-2026-41096 — Windows DNS Client. Контролируемый атакующим DNS-сервер отправляет специально сформированный ответ, вызывает повреждение памяти и добивается RCE. Вектор атаки — сетевой уровень, без какого-либо взаимодействия с пользователем.
Office и предпросмотр как вектор атаки. Отдельного внимания заслуживает пакет патчей для Microsoft Office, Word и Excel. Несколько закрытых уязвимостей позволяют выполнить код при открытии специально подготовленного файла. Часть атак срабатывает через панель предварительного просмотра — то есть файл даже не нужно открывать полностью.
Для организаций, где сотрудники регулярно получают вложения по почте, это не теоретический риск. Обновления Office в этом цикле лучше не откладывать на «следующую неделю».
SharePoint Server — обновить приоритетно, особенно если он смотрит наружу или используется как интранет-портал
Windows DNS Client — проверить, применились ли патчи на всех рабочих станциях и серверах в домене
Office / Word / Excel — развернуть через WSUS или Intune без ожидания следующего окна обслуживания
GDI / Paint — звучит как мелочь, но EMF-файлы гуляют в корпоративной почте чаще, чем кажется
120 уязвимостей за один цикл — это уже не исключение, а норма для Microsoft. Апрельский пакет был сопоставимым. Темп не снижается, и это означает одно: окно между выходом патча и его эксплуатацией в реальных атаках продолжает сжиматься. Кто не успел за 30 дней — играет в другую игру.
РБПО по ГОСТ Р 56939—2024: вебинар №13 из 30 – Обеспечение безопасности сборочной среды программного обеспечения
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.13. – "Обеспечение безопасности сборочной среды программного обеспечения". На YouTube. Слайды.
Цели 13-го процесса по ГОСТ Р 56939—2024:
Обеспечение безопасности при сборке ПО, недопущение привнесения в результаты сборки ПО уязвимостей и ошибок со стороны сборочной среды.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.
P.S. В вебинаре рассказывается, в том числе, про GitFlic. Отмечу, что PVS-Studio совместим с платформой GitFlic. Благодаря этому разработчики могут получать результаты сканирования PVS-Studio напрямую в интерфейсе GitFlic, что упрощает процесс разработки и тестирования.
SAST: с чем сталкиваются команды и как это решать
Сегодня поговорим про статический анализ кода (SAST) — одну из самых важных практик анализа безопасности приложений, которая помогает находить уязвимости на ранних этапах разработки.
▶️ Основные проблемы, которые беспокоят разработчиков:
долгие сканирования на крупных кодовых базах;
большое количество ложных срабатываний (False Positive);
недостаточное покрытие технического стека правилами (False Negative).
▶️ Как решать:
выбирайте инструменты, которые отвечают требованиям вашей компании и отрасли;
разработайте набор правил под конкретный проект;
редактируйте встроенные правила в продукте;
для оптимизации времени сканирования проводите быстрые проверки в каждом коммите или мердж реквесте, а долгие уже перед релизом или по расписанию.
▶️ Что лучше выбрать: коммерческий или некоммерческий SAST- сканер?
При выборе инструментов важно учитывать, что коммерческие решения, как правило, предлагают более широкое покрытие языков и технологий, регулярные обновления и глубокий анализ потоков данных. Однако они могут быть требовательны к ресурсам и ограничивать возможности кастомизации.
Некоммерческие решения, напротив, дают больше гибкости за счёт открытого кода и часто работают быстрее, но могут уступать в функциональности, полноте анализа и качестве документации, особенно в сложных сценариях.
Обычно, чтобы определиться с выбором SAST-инструмента, команды проводят пилот: сравнивают решения по функциональности и качеству детекта. Максимальный эффект от решения достигается тогда, когда выстроен процесс тестирования с настройкой правил, метриками и понятными критериями эффективности.
10 мая 2026 года OpenAI объявила Daybreak — связку GPT-5.5 и Codex, которая ищет уязвимости в репозитории, валидирует их в sandbox и предлагает патч в один клик.
GPT-5.5, вышедший 23 апреля 2026-го, стал первой моделью OpenAI, перешагнувшей порог «High» по кибервозможностям согласно собственному Preparedness Framework компании. Поверх него — Codex как агентный harness, который работает напрямую с кодовой базой. Вместе они и составляют Daybreak.
Три уровня доступа и один жёсткий порог. Базовый тир — GPT-5.5 для общих сценариев, без особых ограничений. Средний — Trusted Access for Cyber (TAC): secure code review, triage уязвимостей, анализ малвари, detection engineering, валидация патчей. К моменту анонса в TAC уже числились тысячи верифицированных одиночных защитников и сотни команд.
Верхний тир — GPT-5.5-Cyber, представленный 7 мая 2026-го. Это «cyber-permissive» вариант флагмана: не умнее, но менее склонен отказывать на запросы про крафт пейлоадов, воспроизведение эксплойтов в лабораторных условиях и реверс бинарей. Выдаётся точечно. С 1 июня 2026 года потребуется phishing-resistant аутентификация — OpenAI явно не хочет, чтобы этот SKU воспринимался как обычная подписка.
Что это даёт в реальном pipeline. Если стек уже завязан на Codex или ChatGPT Enterprise, Daybreak встраивает непрерывный security-loop прямо в CI/CD: модель строит threat-модель из репозитория, валидирует уязвимости в sandbox, генерирует патч через Codex. Для open-source мейнтейнеров OpenAI обещает pro bono сканирование — по аналогии с Aardvark в private beta осенью 2025-го, которая дала 10 CVE по итогам responsible disclosure.
Контекст запуска не случаен: IBM X-Force в 2026 году зафиксировал рост атак на публичные приложения на 44% год к году, CrowdStrike — рост активности AI-усиленных противников на 89%. Anthropic продвигает Claude Mythos с фокусом на безопасность, но без публичного доступа; Google — CodeMender; стартап XBOW занимает свою нишу. Daybreak при этом позиционируется как первый массово развёрнутый агент для defense-команд от ведущего AI-вендора.
Интереснее всего здесь не сама модель, а архитектурное решение: OpenAI разделила «умеет» и «разрешено» на уровне продуктовых тиров с верификацией личности. Это прецедент — раньше ограничения были только техническими (system prompt, фильтры). Теперь доступ к определённым возможностям привязан к идентификации пользователя. Насколько это удержит модель от злоупотреблений — покажет практика.
Представлен бесплатный сервис Filescan, который работает прямо в браузере и проверяет любой сайт или файл на вирусы:
работает со всеми типами файлов, включая картинки, видео, apk и exe;
запускает приложения в песочнице и смотрит на его поведение;
ищет в сигнатуры вредоносных объектов и подозрительный код;
при этом работает быстро — разбор задачи занимает несколько секунд;
Представлен сервис «taken.» который позволяет оценить, какую информацию о вас знают сайты в интернете. Спойлер: они знают буквально всё — от вашего местоположения до точных настроек системы, заряда батареи и даже установленных шрифтов.
Сбалансированные Claude Code Safety Hooks с минимум false positive благодаря AST-парсингу Bash
Наконец-то сделал хуки моей мечты - достаточно безопасные и практически без false-positive. Хуки вымученные, эволюционировали на граблях можно сказать.
Собственноно, любой, кто проработал с агентами какое-то время отлично знает, что иногда они чудят, удаляя лишнее - папки, докер образы или даже целые базы вместе с инфрой. И их важно вовремя ловить за руку.
Хуки - это важнейшая часть работы с AI-кодинг агентами, привносящая в них не только детерменированности, но и безопасности.
Соответственно, когда хуков нет совсем или их мало, безопасность хромает - агент может уронить базу, сделать rm rf и тд, а если хуков слишком много , то... вы привыкаете клацать Enter на Allow, уже даже не читая о чем вообще сыр-бор. Поэтому, нужен тонкий баланс и хуками важно закрывать только действительно деструктивные, необратимые или критические действия.
Ну, и сразу второй нюанс - для блоков я предпочитаю использовать ask хуки вместо блокирующих, т. к. агенты нынче слишком умные и получив блокирующий хук, наверняка найдет способ обойти ограничение (особенно если прилетел какой-нибудь prompt-injection), тк хуки обычно весьма примитивны.
Короче-говоря, с учетом всех этих нюансов я написал свои opiniated-хуки, которые сам использую, они максимально сбалансированны по allow/ask с практически нулевым false positive - благодаря парсингу AST, а не regex'ам, которые обычно в хуках. Частично в основе лежит claude-code-safety-net весьма сильно переработанный и дополненный.
Внутри:
1. rm — rm/unlink/shred вне cwd, по /etc, $HOME; через sudo, xargs, find -delete, pipe-to-shell.
2. infra — kubectl, docker, terraform, helm, gcp.
3. db — DROP/TRUNCATE/DELETE через psql/mysql; redis-cli FLUSHALL/SHUTDOWN, supabase.
4. paas — Railway, Fly, Heroku, Vercel, Netlify с destructive-глаголами (PocketOS-класс).
5. git — reset --hard, clean -fd, checkout . / restore ., branch -D, stash drop/clear, push -f, push --delete.
Ссылка на репо: https://github.com/CodeAlive-AI/ai-driven-development/tree/main/hooks/balanced-safety-hooks
Из особенностей - написаны хуки на Go, поэтому выполняются буквально за несколько мс. Ну, и каждый, может поправить их под свои нужды, перекомпилировав бинарник. Еще из интересного - большинство хуков покрыты тестами.
Кстати, для простого и корректного управления своими хуками у меня есть отдельный скилл hooks-management, который теперь поддерживает Claude Code, Codex и OpenCode.
Если вам нравится такой контент, то не премините заглянуть в мой Telegram канал, в котором я регулярно делюсь всякими полезностями про AI-Driven Development: https://t.me/+A-CrVovS0lczMDVi
Чтение книг расширяет наш кругозор, заставляя мозги работать и восполняя пробелы в “белых зонах”. Сегодня в рубрике “что почитать” мы поговорим про книгу Алексея Усанова “Реверс-инжинириг встраиваемых систем”.
Алексей позиционирует свое творение как руководство по погружению в мир встраиваемых систем - от их первоначального анализа и получения прошивки до нейтрализации механизмов защиты от реверс-инжиниринга и модификации. В книге приводится базовый набор оборудования и ПО, с помощью которого можно проводить исследования большинства систем. Издание адресовано инженерам и разработчикам встраиваемых систем, а также студентам технических ВУЗов.
Структурно книга состоит из 6 глав, охватывающие различные направления программно-аппаратного хакинга: первичный анализ, получение прошивки, статистический и динамический анализы, механизмы защиты страиваемых систем и, в качестве дополнения, обустройство рабочего места исследователя.
Если говорить про автора, то Алексей более 15 лет занимается исследованиями встраиваемых систем и системной разработкой, является руководителем направления исследований безопасности аппаратных решений в компании Positive Technologies, а также аботал преподавателем на кафедре Информационная безопасность МГТУ им. Баумана.
Книгу я дочитываю, поэтому могу смело ее рекомендовать. Приобрести экземпляр можно напрямую у Издательства ДМК за 1749 рублей, но советую поторопиться, так как тираж у книги всего 200 экземпляров.
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
РБПО по ГОСТ Р 56939—2024: вебинар №12 из 30 – Использование безопасной системы сборки программного обеспечения
Команда ООО "ПВС" совместно с Виталием Пиковым из учебного центра "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.12. – "Использование безопасной системы сборки программного обеспечения". На YouTube. Слайды.
Цели 12-го процесса по ГОСТ Р 56939—2024:
Обеспечение безопасности при сборке ПО, недопущение привнесения в код ошибок, обусловленных небезопасными преобразованиями кода.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации, подготовленная Андреем Карповым, доступна по ссылке: ГОСТ56939.РФ.
P.S. Мы регулярно проводим вебинары на различные темы, не обязательно связанные с РБПО. У нас появился подкаст «Разбаговка»! Приглашаем слушать и принять участие в качестве гостя.
Лаборатория Касперского проверила 231 миллион паролей из даркнет-утечек 2023–2026 годов: 60% взламываются менее чем за час, почти половина — меньше чем за минуту.
Одна видеокарта RTX 5090 перебирает MD5-хеши со скоростью 220 миллиардов в секунду — на 34% быстрее, чем RTX 4090. Арендовать такую мощность в облаке можно за несколько долларов в час. Это уже не академическая атака — это промышленный процесс.
Цифры, которые неприятно читать. По данным SecurityLab, исследование Лаборатории Касперского разбивает 231 миллион паролей примерно так: 45% ломаются за минуту, ещё 15% — в пределах часа, и только 23% требуют больше года непрерывного перебора. Оставшиеся — где-то посередине. Три четверти паролей, которые люди считают «нормальными», не переживут рабочего дня атакующего.
Почему умные алгоритмы выигрывают у человека. Дело не только в железе. Современные инструменты взлома обучены на тех же утечках — они знают, что пользователи заменяют «a» на «@», добавляют год рождения в конец и ставят восклицательный знак, думая, что это хитро. Алгоритм проверяет эти паттерны первыми. Радужные таблицы с миллионами заранее посчитанных хешей — это вчерашний день; сегодня работают вероятностные модели, натренированные на реальном поведении людей.
Отдельная история — повторное использование паролей. Если один и тот же пароль стоит на трёх сервисах, взламывать ничего не нужно: достаточно найти его в одной утечке и прогнать по остальным. Credential stuffing — это не атака на пароль, это атака на человеческую лень.
Что реально помогает
Менеджер паролей — единственный способ иметь уникальные длинные комбинации без боли. Хранить в браузере или заметках — примерно то же, что оставить ключ под ковриком.
Длина важнее сложности. Случайная фраза из четырёх слов длиннее и энтропийнее, чем Pa$$w0rd123.
Passkeys (ключи доступа) там, где сервис поддерживает — убирают пароль из уравнения вообще.
TOTP-аутентификатор вместо SMS. SMS перехватывается через SS7 или SIM-swap; TOTP — нет.
Для корпоративного контекста добавлю: если у вас нет политики паролей с проверкой по базам утечек (HaveIBeenPwned API или аналог) и принудительного MFA на всех внешних точках входа — вопрос не в том, взломают ли, а в том, когда именно это уже произошло и вы просто не знаете.
Скорость перебора будет только расти — следующее поколение GPU сделает ещё один шаг вперёд. Пароли как механизм аутентификации доживают последние годы, и чем раньше инфраструктура это учтёт, тем меньше будет неприятных сюрпризов.
Dirty Frag 🐧💥
Спустя неделю после нашумевшего Copy.Fail исследователь v4bel раскрыл новую технику повышения привилегий в ядре Linux — Dirty Frag.
По состоянию на утро 8 мая у Dirty Frag не было CVE-номера и, что более критично, официального патча от мейнтейнеров ядра тоже. Dirty Frag относится к тому же классу, что Dirty Pipe и Copy.Fail, но использует другой механизм: вместо pipe_buffer атакуется структура sk_buff.
Общие механизмы работы позволяют надежно блокировать эксплойт поведенческой экспертизой в PT Sandbox (Exploit.Linux.CVE-2022-0847.a, Exploit.Linux.CVE-2026-31431.a, Backdoor.Linux.Generic.a) — смотрите на скриншоте.
Как это работает? 🧐
Dirty Frag — это цепочка из двух уязвимостей, которые дополняют друг друга, чтобы охватить все основные дистрибутивы:
1️⃣ Page-Cache Write (с 2017 года): предоставляет возможность для записи 4 байт в кэш страниц, но требует права на создание пользовательских пространств имен, что в некоторых системах (например, Ubuntu) может блокироваться AppArmor.
2️⃣ RxRPC Page-Cache Write (с июня 2023 года): не требует прав на пространства имен, но модуль rxrpc.ko присутствует только в некоторых дистрибутивах, включая Ubuntu, где он загружен по умолчанию.
Объединив их, атакующий получает рабочий эксплойт на любой системе, что позволяет:
• Подменить suid-файлы (например, /usr/bin/su) на свою версию
• Изменить /etc/passwd, очистив пароль root-пользователя
Кто под угрозой? ⛳️
Практически все системы с ядром Linux, выпущенные с 2017 года. Исследователь подтвердил работу эксплойта на следующих версиях: Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44 и других.
Как защититься? 🔧
Так как официального патча от мейнтейнеров ядра пока нет, единственный способ защиты — немедленно отключить и выгрузить уязвимые модули ядра.
Команда для отключения:
sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"Некоторые дистрибутивы (например, AlmaLinux) начали выпускать собственные патчи, не дожидаясь апстрима.
Позднее сегодня уязвимость получила идентификатор CVE-2026-43284, патч добавлен в код ядра (f4c50a4034e6).
(Источник: https://t.me/ptescalator)
Dirty Frag: новый LPE в Linux из той же «грязной» серии
После Dirty Pipe и Copy Fail появился новый кейс — Dirty Frag: локальная эскалация привилегий в Linux, позволяющая получить root при успешной эксплуатации.
По данным опубликованного исследования, Dirty Frag строится на цепочке из уязвимостей в механизмах xfrm-ESP и RxRPC.
Митигация
До выхода и установки патчей от дистрибутива можно временно снизить риск, выгрузив уязвимые модули:
rmmod esp4 esp6 rxrpcДля более устойчивой митигации после перезагрузки:
printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf
rmmod esp4 esp6 rxrpc 2>/dev/null
echo 3 > /proc/sys/vm/drop_cachesПеред применением проверьте, не используются ли эти модули легитимными сервисами, например IPsec/xfrm или RxRPC-зависимыми компонентами. После появления обновлений ядра приоритетная мера — установить патчи от вашего Linux-дистрибутива.
Детектирование
F6 EDR обнаруживает попытки эксплуатации Dirty Frag, а также эксплуатацию Copy Fail, позволяя выявлять активность, связанную с локальной эскалацией привилегий, даже если патчи или временные митигации еще не развернуты на всех хостах.
Рекомендации:
1. Проверить наличие модулей esp4, esp6, rmmod, rxrpc;
2. Применить временную митигацию там, где это не ломает бизнес-сервисы;
3. Установить обновления ядра сразу после выхода патчей;
4. Контролировать попытки эксплуатации через EDR.
Пару недель назад я попросил у вас помощи в вопросе предоставления нерабочей IoT-техники, старых роутеров, видеокамер и других умных устройств для проведения программно-аппаратных исследований. Честно говоря, я не ожидал, что так много людей откликнется и окажет неоценимую помощь.
Однако особую благодарность хочу выразить Валерию, который предоставил просто бессчётное количество исторических артефактов:
роутеры D-Link, TP-Link, Ростелеком (ИскраТел), ZyXEL, Paradyne;
мобильные телефоны N95i и Toshiba Portege;
IP-видеокамеры - 2 экземпляра;
видеокарту;
коммуникаторы и ТСД на базе Windows CE;
транспондер;
а также ряд других устройств, предназначение которых для меня пока остаётся загадкой 😂
Итого всё это «добро» весит около 10 килограммов и представляет собой настоящую историческую веху, в которую я, как олдфаг, вспоминающий интернет по талонам, с ностальгией готов окунуться. Валерий, очень рад познакомиться лично и ещё раз спасибо за предоставленное оборудование!
В общем, если раньше была проблема «Что тестировать?», то теперь она переросла в проблему «Когда тестировать?», потому что, даже если брать по два устройства в месяц, у меня уйдёт не меньше года на изучение всего этого добра. Но, честно скажу, это очень приятная проблема ;)
Если у вас есть предложения, с чего именно мне начать, - с радостью выслушаю ваши пожелания.
🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
РБПО по ГОСТ Р 56939—2024: вебинар №11 из 30 – Динамический анализ кода программы
Компания ООО "ПВС" совместно с учебным центром "Маском" провела цикл вебинаров, посвящённых разработке безопасного программного обеспечения (РБПО). Совместно с приглашёнными экспертами различных компаний мы рассмотрели 25 процессов, приведённых в ГОСТ Р 56939—2024.
Предлагаем сегодня вашему вниманию вебинар цикла, посвящённый процессу, описанному в разделе 5.11. – "Динамический анализ кода программы". На YouTube. Слайды.
Цели 11-го процесса по ГОСТ Р 56939—2024:
Обнаружение недостатков и уязвимостей в коде ПО в процессе его выполнения.
Общее количество вебинаров — 30: каждому из 25 процессов ГОСТа посвящено по одному вебинару и 5 записано дополнительно на смежные темы. Запись всех вебинаров и подборка дополнительной информации доступна по ссылке: ГОСТ56939.РФ.