Архив рубрики: Уязвимость

Vulnerability Management и горячая картошка

Vulnerability Management и горячая картошка

Vul­ner­a­bil­i­ty Man­age­ment и горячая картошка. 🥔 Подумалось, что важнейшая задача Vul­ner­a­bil­i­ty Man­age­ment решения заключается в том, чтобы защищать самого VM-специалиста (и его руководителей вплоть до CISO). Решение должно предоставлять надёжные доказательства, что специалист добросовестно выполнял свою часть работы:

🔸 Своевременно и достаточно полно анализировал инфраструктуру.
🔸 Оперативно информировал ответственных о найденных уязвимостях и связанных рисках, ставил им задачи на исправление.
🔸 Контролировал выполнение задач ответственными и указывал, если задачи не были выполнены в срок.
🔸 Особое внимание уделял критичным уязвимостям из рассылок регуляторов.

Цель в том, чтобы в момент внешнего аудита или расследования инцидента, в руках VM-щика не было "горячей картошки" (необработанных критичных уязвимостей). 😏 Это значит, необходимо постоянно оценивать количество "картошки" в руках и автоматически минимизировать его или предлагать шаги для этого. Задача для AI? 🤔 Возможно.

В понедельник на сайте Positive Technologies вышла большая статья про SteganoAmor — операцию по обнаружению атак группировки TA558

В понедельник на сайте Positive Technologies вышла большая статья про SteganoAmor - операцию по обнаружению атак группировки TA558

В понедельник на сайте Pos­i­tive Tech­nolo­gies вышла большая статья про SteganoAmor — операцию по обнаружению атак группировки TA558. Несмотря на многообразие инструментов и методов атак, которые использовала группировка, в статье упоминается только одна CVE уязвимость. Это старая RCE в Microsoft Office (CVE-2017–11882), которая используется для запуска макросов в RTF-документах. Несмотря на возраст, уязвимость регулярно всплывает в описаниях актуальных атак.

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

Одновременно курьёзный и печальный факт. Уязвимость была обнаружена исследователем из Embe­di. К сожалению, компания не пережила американские санкции и на их сайте, где было выложено оригинальное исследование, теперь онлайн-казино. 🎰🤷‍♂️

Повысилась критичность уязвимости RCE — Windows MSHTML Platform (CVE-2023–35628)

Повысилась критичность уязвимости RCE - Windows MSHTML Platform (CVE-2023-35628)
Повысилась критичность уязвимости RCE - Windows MSHTML Platform (CVE-2023-35628)

Повысилась критичность уязвимости RCE — Win­dows MSHTML Plat­form (CVE-2023–35628). Уязвимость была исправлена в декабрьском Microsoft Patch Tues­day 2023.

"По данным Microsoft, злоумышленник может отправить специальное email-сообщение, которое будет автоматически обработано при получении Microsoft Out­look (до просмотра в Pre­view Pane). 🔥"

И вот через 4 месяца Aka­mai выложили подробный write-up и PoC эксплоита. Эксплоит это файл test.url, который крашит Win­dows File Explor­er. 🤔

А где zero-click RCE в Out­look? Такая эксплуатация возможна вместе с EoP — Microsoft Out­look (CVE-2023–23397):

"This vul­ner­a­bil­i­ty can be trig­gered through Out­look (0‑click using CVE-2023–23397)".

Впрочем, CVE-2023–23397 и без того была супер-критичной на момент выхода в марте 2023 с признаками активной эксплуатации вживую. Есть надежда, что её уже пофиксили везде. 🙏

По данным из БДУ ФСТЭК уязвимость CVE-2023–35628 эксплуатируется вживую (флаг vul_incident).

13 мая стартует онлайн-хакатон от команды MaxPatrol VM Positive Technologies: получи реальный опыт в разработке правил детектирования уязвимостей на нейтральном опенсурсном стеке и выиграй денежные призы

13 мая стартует онлайн-хакатон от команды MaxPatrol VM Positive Technologies: получи реальный опыт в разработке правил детектирования уязвимостей на нейтральном опенсурсном стеке и выиграй денежные призы

13 мая стартует онлайн-хакатон от команды Max­Pa­trol VM Pos­i­tive Tech­nolo­gies: получи реальный опыт в разработке правил детектирования уязвимостей на нейтральном опенсурсном стеке и выиграй денежные призы. Активность просто огненная. 🔥

Задания хакатона:

🔻 Стендирование. Написать плейбук для развертывания ПО с помощью Ansi­ble.
🔻 Обнаружение ПО. Написать скрипт для обнаружения ПО на хосте на языке Python. Цель скрипта сгенерировать OVAL Vari­ables с информацией по софту.
🔻 Обнаружение уязвимостей. Распарсить источник данных об уязвимостях и сформировать OVAL Def­i­n­i­tions. Затем провести детектирование уязвимостей используя OVAL Def­i­n­i­tions и артефакт работы скрипта обнаружения ПО (OVAL Vari­ables) с помощью утилиты Open­SCAP.

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

Ansi­ble + Python + OVAL/OpenSCAP

При этом использование Python для сборки OVAL Vari­ables позволит снять ограничения связанные с OVAL объектами (мороки с их сбором — атас, а Open­SCAP под Win­dows вообще dic­scon­tin­ued) и при этом получить все преимущества OVAL — формализованное описание правил детектирования уязвимостей и готовые инстурумент для расчёта статусов в виде Open­SCAP.
Б — Баланс. 👍

💳 За выполнение заданий участники будут получать баллы, которые будут конвертированы в деньги.

🚀 Результаты работы участников не пропадут, а будут использованы в Max­Pa­trol VM (после ревью и через конвертацию в пакеты Max­Pa­trol VM).

Для участников сплошной Win:

🔸 Получаем реальную практику с востребованными технологиями (Ansi­ble и Python вообще must have в IT, а OVAL/SCAP кучей VM-продуктов используется и в России, и зарубежом).
🔸 Получаем отличную строчку в резюме (рассказывать на собесе как детекты писал, которые в Max­Pa­trol VM сейчас используется — круто же 🙂).
🔸 Получаем приятный денежный бонус с этого.
🔸 Получаем фаст-трек для вкатывания в команду разработки Max­Pa­trol VM, если процесс понравится и будут хорошие результаты. 😉

➡️ Подробности и регистрация тут
🟥 Официальный пост в канале Pos­i­tive Tech­nolo­gies

По Linux Patch Wednesday можно задать справедливый вопрос: а правильно ли я отношу уязвимости к месяцам?

По Linux Patch Wednesday можно задать справедливый вопрос: а правильно ли я отношу уязвимости к месяцам?

По Lin­ux Patch Wednes­day можно задать справедливый вопрос: а правильно ли я отношу уязвимости к месяцам?

Напомню текущую логику: я беру таймстемпы бюллетеней из OVAL-контента Lin­ux вендоров. Какой таймстемп самый старый, тот и считаю временем первого исправления уязвимости.

Но вот незадача: первыми обычно выпускают исправления Debian и они же, частенько, не указывают дату бюллетеня в OVAL (и в листах рассылки тоже не всегда). 😣 Вот и получается как на картинке. Debian выпустил патч непонятно когда, а RedOS в апреле 2024. Делаем вывод, что уязвимость апрельская, ага. Хотя "2023" в CVE намекает на то, что это, мягко говоря, не совсем так и первое исправление уязвимости вышло значительно раньше.

Что с этим делать? Можно сделать радикальный шаг: если для CVE в источнике дата Unknown, то тупо выставлять текущую дату. "Если вижу исправление и не знаю когда конкретно уязвимость была исправлена, значит она была исправлена сегодня". 🙂 И проводить такую "раздачу дат" для Unkown более-менее регулярно (не реже раза в месяц).

К чему приведет введение такого правила со следующего Lin­ux Patch Wednes­day? К тому, что огромная масса уязвимостей, которые непонятно когда были исправлены, станут "исправлены" в мае 2024 года. Мы на них посмотрим, ужаснёмся разок, но зато в следующих месяцах всплывающих внезапно старых уязвимостей будет минимальное количество. Там будет в основном свежачок. Но зато я попорчу статистику внезапным пиком в мае 2024. Дилемма. 🤷‍♂️

Как считаете, проводим операцию "Введение правила по Unknown датам с Мая 2024?".

Кит 🐳, если да (ввести правило, получить пик в статистике ради будущих красивых отчётов без старья).

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

Сам я считаю, что ввести такое правило стоит.

Сгенерил отчёт Vulristics по апрельскому Linux Patch Wednesday

Сгенерил отчёт Vulristics по апрельскому Linux Patch Wednesday
Сгенерил отчёт Vulristics по апрельскому Linux Patch WednesdayСгенерил отчёт Vulristics по апрельскому Linux Patch WednesdayСгенерил отчёт Vulristics по апрельскому Linux Patch WednesdayСгенерил отчёт Vulristics по апрельскому Linux Patch WednesdayСгенерил отчёт Vulristics по апрельскому Linux Patch WednesdayСгенерил отчёт Vulristics по апрельскому Linux Patch Wednesday

Сгенерил отчёт Vul­ris­tics по апрельскому Lin­ux Patch Wednes­day. За прошедший месяц Lin­ux-вендоры начали выпускать исправления для рекордного количества уязвимостей — 348. Есть признаки эксплуатации вживую для 7 уязвимостей (данные об инцидентах из БДУ ФСТЭК). Ещё для 165 есть ссылка на эксплоит или признак наличия публичного/приватного эксплоита.

Начнём с 7 уязвимостей с признаком активной эксплуатации вживую и эксплоитами:

🔻 В ТОП‑е, внезапно, январская трендовая уязвимость Authen­ti­ca­tion Bypass — Jenk­ins (CVE-2024–23897). Насколько я понимаю, обычно Lin­ux-дистрибутивы не включают пакеты Jenk­ins в официальные репозитарии и, соответственно, не добавляют детекты уязвимостей Jenk­ins в свой OVAL-контент. В отличие от отечественного RedOS. Поэтому самый ранний таймстемп исправления этой уязвимости именно у RedOS.

🔻 2 RCE уязвимости. Самая интересная это Remote Code Exe­cu­tion — Exim (CVE-2023–42118). Когда я выпускал отчёт, я специально не учитывал описание уязвимости и продукты из БДУ (флаги –bdu-use-prod­uct-names-flag, –bdu-use-vul­ner­a­bil­i­ty-descrip­tions-flag). Иначе это привело бы к тому, что часть отчёта была бы на английском, а часть на русском. Но оказалось, что для этой уязвимости адекватное описание есть пока только в БДУ. 🤷‍♂️ К этой уязвимости нужно присмотреться, т.к. Exim является достаточно популярным почтовым сервером. Вторая RCE уязвимость браузерная, Remote Code Exe­cu­tion — Safari (CVE-2023–42950).

🔻 2 DoS уязвимости. Denial of Ser­vice — nghttp2/Apache HTTP Serv­er (CVE-2024–27316) и Denial of Ser­vice — Apache Traf­fic Serv­er (CVE-2024–31309). Последняя в отчёте классифицируется как Secu­ri­ty Fea­ture Bypass, но это из-за некорректного CWE в NVD (CWE-20 — Improp­er Input Val­i­da­tion)

🔻 2 браузерные Secu­ri­ty Fea­ture Bypass — Chromi­um (CVE-2024–2628, CVE-2024–2630)

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

🔸 Большое количество RCE уязвимостей (71). Большая часть из них в продукте gtk­wave. Это программа просмотра файлов VCD (Val­ue Change Dump, дамп изменения значения), которые обычно создаются симуляторами цифровых схем. Выглядят опасными уязвимости Remote Code Exe­cu­tion — Cac­ti (CVE-2023–49084, CVE-2023–49085), это решения для мониторинга серверов и сетевых устройств.

🔸 Secu­ri­ty Fea­ture Bypass — Send­mail (CVE-2023–51765). Позволяет внедрить сообщения электронной почты с поддельным адресом MAIL FROM.

🔸 Пачка Cross Site Script­ing в Medi­aWi­ki, Cac­ti, Grafana, Nextcloud.

В общем, в этот раз аж глаза разбегаются. 🤩

🗒 Апрельский Lin­ux Patch Wednes­day

Разобрал заметки про эфир AM Live по Vulnerability Management‑у

Разобрал заметки про эфир AM Live по Vulnerability Management-у

Разобрал заметки про эфир AM Live по Vul­ner­a­bil­i­ty Management‑у. Эфир шел чуть меньше 3 часов. Ух! Всё ещё самое концентрированное мероприятие по VM‑у в России. 🔥

Каких-то явных клинчей VM-вендоров практически не было. А ведь это самое интересненькое. 😈 Отметил:

🔻 От Александра Дорофеева по поводу стоимости решения. Эшелон активно конкурирует по цене. Павел Попов хорошо это парировал обращением к клиентам: "смотрите сами, что вам нравится и подходит по бюджетам".
🔻 Тоже от Александра Дорофеева, что детект поиском по базе лучше, чем детект скриптами или OVAL-контентом. Имхо, разницы какой-то нет, зависит от реализации и когда решение "ищет по базе" сложно понять какие уязвимости оно в принципе может детектировать 🤷‍♂️.
🔻Небольшие пикировки по поводу использования нескольких сканеров в решении: те, кто умеют такое, говорили, что это must have, а те, кто не умеют, либо молчали, либо переводили в русло "а кто будет отвечать за качество детектирования в сторонних (в том числе бесплатных) сканерах".

В остальном было всё тихо-мирно и в одном ключе. Основные тезисы:

🔹 VM про совместную работу в компании. Важность VM должен осознавать IT, ИБ, Бизнес.
🔹 VM-щик в одиночку может реализовывать только функции контроля.
🔹 Цель VM‑а в том, чтобы сделать взлом компании через известные уязвимости невозможным (имхо, правильнее говорить про увеличение стоимости атаки)
🔹 Внедрение компенсирующих мер это лучше, чем ничего, но это неполное исправление. "А если WAF упадёт, что тогда?"
🔹 Не нужно исправлять все уязвимости, нужно определять критичные и исправлять их. Тут меня резко резануло, т.к. я‑то как раз за то, что нужно стремиться к детектированию и исправлению всех уязвимостей. 🙄
🔹 Нулевой этап Vul­ner­a­bil­i­ty Management‑а это Asset Man­age­ment. Желательно, чтобы была интерактивная визуализация с подсветкой Kill Chain-ов и т.п.
🔹 Базы детектов должны обновляться очень быстро, чтобы можно было исправлять критичные уязвимости за 24 часа.
🔹 Обосновывать необходимость VM‑а за последние 2 года стало проще из-за публичных инцидентов.

Про то, что нужно договариваться о безусловных регулярных обновлениях с IT в этот раз не говорили — жаль. 😔

Ответы вендоров про отличия от конкурентов:

🔸 ГК «Солар». Вообще не VM-вендор, а сервис, который может использовать решения разных вендоров. Можно добавлять свои сканеры и детекты.
🔸 Solid­Lab VMS. Не просто вендор, а решение предоставляющее отвалидированные уязвимости с reme­di­a­tion-ами, настроенными под заказчиков. Вдохновлялись Qualys-ами.
🔸 «АЛТЭКС-СОФТ». Используют открытый стандарт SCAP/OVAL, можно импортить свой OVAL. Пока не VM-решение, а сканер, но активно работают над VM-ом (пока в аналитике). OVALdb идёт как отдельный продукт.
🔸 «Эшелон Технологии»/Сканер ВС. Цена низкая, детект быстрым поиском по базе (+ перерасчет уязвимостей без пересканирования), работает на Astra Lin­ux.
🔸 Secu­ri­ty Vision. "Настроенный SOAR в виде VM".
🔸 R‑Vision. Полноценное решение от управления активами до детекта и исправления уязвимостей. Быстрые детекты 5–20 секунд на хост. Своя тикетница.
🔸 Spacebit/X‑Config. Com­pli­ance Man­age­ment. Хорошая производительность, гибкие политики, поддержка российского ПО.
🔸 Pos­i­tive Technologies/MaxPatrol VM. Asset Man­age­ment, перерасчет уязвимостей без пересканирования, Com­pli­ance Man­age­ment. Подробности о новых фичах будут на PHDays. 😉

Направление развития у всех более-менее схожи и укладываются в общемировые тренды: автоматизация исправления уязвимостей (VMDR. autopatch­ing), использование AI для приоритизации уязвимостей и упрощения работы. Ну и общее подтягивание до уровня ТОП3 западных решений.

Понравилось, что в одном из голосований по поводу проблем VM-решений большая часть опрошенных (32%) высказалась по поводу полноты базы детектов и качества детектирования. Т.е. за хардкорную базовую функциональность. 👍 Хочется надеяться, что это будут учитывать и VM-вендоры выставляя приоритеты своей разработки. 🙂