Архив рубрики: Темы

Что делать VM-щику, чтобы быть эффективным?

Что делать VM-щику, чтобы быть эффективным?

Что делать VM-щику, чтобы быть эффективным? Исходя из того, что он должен выполнять в организации роль инспектора без каких-либо реальных полномочий, а коллеги из IT в основном считают, что он творит дичь. 🤔

🔻 1. Досконально знать требования и рекомендации регуляторов в части управления уязвимостями. Парадоксально, но именно это самый надёжный инструмент VM-щика и самый недооцененный. 😏 Вряд ли в организации кто-то будет разбираться в этом лучше. Кроме, возможно, методологов ИБ, но они естественные союзники и с ними проблем обычно не бывает. Конечно, не стоит постоянно потрясать выписками из регуляторики и грозить неизбежными карами. Это глупо, а главное вызывает привыкание и уменьшает эффект. Ну либо наоборот приводит к тому, что коллеги из IT начинают осознавать степень своей реальной ответственности в случае инцидента и бегут массово увольняться, чего тоже хотелось бы избежать. 😉 Поэтому лучше приберегать такие аргументы на случай серьезного конфликта. Чтобы, когда договориться по-хорошему не получается, эффектно и адресно бахнуть из всех стволов. Понимание, что такие железобетонные аргументы есть и они заранее заготовлены, даёт опору и уверенность. Это даже в качестве аутотренинга неплохо работает. "- Кто ты? - Vulnerability Management специалист. - Что ты здесь делаешь? - Внедряю в организации Vulnerability Management процесс согласно лучшим практикам, рекомендациям и требованиям регуляторов в целях повышения уровня защищенности организации."

🔻 2. Разбираться в уязвимостях, инструментах детектирования и эксплуатации. Этот пункт как раз ожидаем. 🙃 Раз VM-щик, то значит должен разбираться в "vulnerability", очевидно. Но тут важно делать акценты: а для чего? Для того чтобы самому находить цепочки атак и демонстрировать реальную эксплуатабельность уязвимостей инфраструктуры? Так это задача внутреннего пентеста/redteam-а. Для того чтобы эффективней убеждать админов? Возможно иногда и имеет смысл, но главное не скатиться в "докажи-покажи" и исправление только тех уязвимостей, которые получается эффектно продемонстрировать. Для того чтобы детектировать все уязвимости, лучше их приоритизировать и выделять те, которые представляют наибольшую опасность для организации? Вот это пожалуй самое главное. Не теряем фокус на том, что мы здесь для того, чтобы внедрять работающий процесс детектирования и исправления уязвимостей, а остальное вторично (ещё раз см. п.1).

🔻 3. Стараться творить поменьше дичи. 🙂 Это значит, что для того, чтобы эффективно коммуницировать с админами, девопсами, разработчиками нужно и самому иметь сопоставимую квалификацию. Иначе требования сделать харденинг или установить обновления будут парироваться простым раздражённым "это невозможно сделать, у нас всё сломается". 😱 Возможно с добавлением какой-то тарабарщины из незнакомых терминов. Задача VM-щика понимать предметную область настолько, чтобы отличать, когда тебе вешают лапшу на уши, а когда за этим реально что-то есть. То есть самому быть в какой-то степени админом/девопсом/разрабом, но с расширенными знаниями в области уязвимостей систем и ИБ вообще. 😉

Презентую расширенную поддержку БДУ ФСТЭК в моей утилите для приоритизации уязвимостей Vulristics

Презентую расширенную поддержку БДУ ФСТЭК в моей утилите для приоритизации уязвимостей Vulristics
Презентую расширенную поддержку БДУ ФСТЭК в моей утилите для приоритизации уязвимостей VulristicsПрезентую расширенную поддержку БДУ ФСТЭК в моей утилите для приоритизации уязвимостей Vulristics

Презентую расширенную поддержку БДУ ФСТЭК в моей утилите для приоритизации уязвимостей Vulristics. 🎉

🔻 Данные из БДУ выгружаются массово, а не по одному идентификатору. Если в data source указан "bdu" и значение rewrite-flag "True", то скачается и обработается вся выгрузка из БДУ (55879 идентификаторов). Кроме того, создадутся сущности по связанным CVE (47261), чтобы можно было использовать данные БДУ при приоритизации CVE-шек (см. скриншот). Вся процедура занимает несколько секунд. ⚡️ Затем можно приоритизировать любые наборы БДУшек в оффлайне (rewrite-flag "False").
🔻 Я использую эти данные БДУ для приоритизации: имя продукта, описание, cvss, cwe, признак активной эксплуатации (vul_incident, аналог CISA KEV❗️) и признак наличия публичного/приватного эксплоита (exploit_status).
🔻 Идентификаторы БДУ подаются на вход также как CVE (например через --cve-list-path), их можно миксовать.

Особенно полезно для приоритизации уникальных БДУ уязвимостей без ссылок на CVE. 😉

В четверг собираюсь выступать на конференции Территория Безопасности с докладом "За пределами NVD: уникальные уязвимости в БДУ ФСТЭК"

В четверг собираюсь выступать на конференции Территория Безопасности с докладом За пределами NVD: уникальные уязвимости в БДУ ФСТЭКВ четверг собираюсь выступать на конференции Территория Безопасности с докладом За пределами NVD: уникальные уязвимости в БДУ ФСТЭК

В четверг собираюсь выступать на конференции Территория Безопасности с докладом "За пределами NVD: уникальные уязвимости в БДУ ФСТЭК". В нём рассмотрю уязвимости БДУ без ссылок на CVE. Выступление будет коротким, минут на 15 вместе с вопросами. Пока буду выкладывать сюда некоторые моменты.

🔸 Сколько уязвимостей в БДУ без ссылок на CVE? Не очень много 1364 из 55805, т.е. где-то 2.4%.
🔸 Если количество новых БДУ идентификаторов с каждым годом увеличивается (как и количество CVE), то про количество новых БДУ идентификаторов без ссылок на CVE сказать что-то определенное сложно.

Дальше рассмотрим что же это за уязвимости.
Спойлер: .

Принципиальная уязвимость Open Source, которую демонстрирует кейс с бэкдором в XZ Utils, вовсе не техническая

Принципиальная уязвимость Open Source, которую демонстрирует кейс с бэкдором в XZ Utils, вовсе не техническая

Принципиальная уязвимость Open Source, которую демонстрирует кейс с бэкдором в XZ Utils, вовсе не техническая. Она в том, что работа сообществ, отвечающих за написание повсеместно используемого кода, строится на более инфантильных принципах, чем у детишек, которые строят замок в песочнице на детской площадке. За детишками в песочнице хотя бы приглядывают взрослые.

А здесь какие-то гики-бессребреники в каком-то листе рассылки как-то самоорганизауются и решают чудовищно замороченные технические вопросы, которые аффектят сотни миллионов людей. 🤷‍♂️ Кто эти гики, какая у них мотивация, насколько адекватны выбранные ими руководители сообществ? 🤔

Как пишут на OpenNetRu, бэкдор в XZ Utils предположительно внедрил разработчик, который за 2 года постепенно влился в проект, стал его мейнтейнером и основным контрибьютором. 😎 А предыдущего мейнтейнера загазлайтили с помощью троллей-виртуалов и он слился. 🤷‍♂️ В итоге бэкдор случайно нашёл сотрудник Microsoft и забил тревогу.

Для январской Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086) 26 марта вышел write-up и PoC

Для январской Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086) 26 марта вышел write-up и PoC
Для январской Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086) 26 марта вышел write-up и PoC

Для январской Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086) 26 марта вышел write-up и PoC. Видео демка работы скрипта выглядит эффектно: запускают скрипт от обычного пользователя и через пару секунд получают рутовый шелл. ⚡️ По заявлениям автора эксплоит работает с большинством ядер Linux между версиями 5.14 и 6.6, включая Debian, Ubuntu и KernelCTF.

🔻 Эксплойт требует kconfig CONFIG_USER_NS=y; sh command sysctl kernel.unprivileged_userns_clone = 1; kconfig CONFIG_NF_TABLES=y. Автор пишет, что это по дефолту выполняется для Debian, Ubuntu, and KernelCTF, а для других дистрибов нужно тестить.
🔹 Эксплойт не работает на ядрах v6.4> с kconfig CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y (включая Ubuntu v6.5)

NSFOCUS пишет, что Redhat тоже подвержен уязвимости. 🤷‍♂️

Обновление по бэкдору в XZ Utils (CVE-2024-3094)

Обновление по бэкдору в XZ Utils (CVE-2024-3094)

Обновление по бэкдору в XZ Utils (CVE-2024-3094).

В постах Tenable и Qualys обновился список уязвимых дистрибов:

🔻 Fedora Rawhide
🔻 Fedora 40 Beta
🔻 Fedora 41
🔻 Debian testing, unstable and experimental distributions versions 5.5.1alpha-0.1 to 5.6.1-1.
🔻 openSUSE Tumbleweed and openSUSE MicroOS (забэкдоренный пакет был включен между 7 и 28 марта)
🔻 Kali Linux (xz-utils 5.6.0-0.2 между 26 и 28 марта)
🔻 Alpine (5.6.0 5.6.0-r0 5.6.0-r1 5.6.1 5.6.1-r0 5.6.1-r1)
🔻 Arch Linux (details)

И список неуязвимых дистрибов:

🔹 Fedora Linux 40
🔹 Red Hat Enterprise Linux (RHEL)
🔹 Debian Stable
🔹 Amazon Linux
🔹 SUSE Linux Enterprise and Leap
🔹 Gentoo Linux
🔹 Ubuntu

Есть YARA правило для детекта.

upd. 0704

Прочитал прикольный FAQ от Tenable про бэкдор в XZ Utils (CVE-2024-3094)

Прочитал прикольный FAQ от Tenable про бэкдор в XZ Utils (CVE-2024-3094)

Прочитал прикольный FAQ от Tenable про бэкдор в XZ Utils (CVE-2024-3094).

"По мнению Red Hat, вредоносный код изменяет функции кода liblzma, который является частью пакета XZ Utils. Этот модифицированный код затем может использоваться любым программным обеспечением, связанным с библиотекой XZ, и позволяет перехватывать и изменять данные, используемые с библиотекой. В примере, рассмотренном Фройндом [исследователь, который нашёл бэкдор], при определенных условиях этот бэкдор может позволить злоумышленнику «нарушить аутентификацию sshd», позволяя злоумышленнику получить доступ к уязвимой системе." 😱

Пока известно, что эти дистрибы точно уязвимы:

🔻 Fedora Rawhide
🔻 Fedora 41
🔻 Debian testing, unstable and experimental distributions versions 5.5.1alpha-0.1 to 5.6.1-1.

А эти точно неуязвимы:

🔹 Fedora Linux 40
🔹 Red Hat Enterprise Linux (RHEL)
🔹 Debian Stable

Ссылка на исходное сообщение исследователя.