По 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-вендоры выставляя приоритеты своей разработки. 🙂

Традиционный эфир на AM Live по Vulnerability Management‑у в этом году подкрался для меня неожиданно

Традиционный эфир на AM Live по Vulnerability Management-у в этом году подкрался для меня неожиданноТрадиционный эфир на AM Live по Vulnerability Management-у в этом году подкрался для меня неожиданно

Традиционный эфир на AM Live по Vul­ner­a­bil­i­ty Management‑у в этом году подкрался для меня неожиданно. Заметил за несколько минут до начала. 😅

Довольно сильно изменился состав участников.

В этом году НЕ участвуют в дискуссии представители от:
🔹 BIZONE
🔹 «Фродекс»

Появились новые представители от:
🔹 Solid­Lab VMS
🔹 ГК «Солар»
🔹 Secu­ri­ty Vision

И остались представители от:
🔹 Pos­i­tive Tech­nolo­gies
🔹 R‑Vision
🔹 «АЛТЭКС-СОФТ»
🔹 «Эшелон Технологии»
🔹 Spacebit

Блок вопросов "Рынок систем управления уязвимостями в России" превратился в "Процесс управления уязвимостями по-российски", что тоже довольно символично.

Как обычно, предвещаю интересный обмен позициями VM-вендоров. 😉 Собираюсь отслеживать на что они будут делать акценты.

Немного продолжу ещё про CVE-2024–26234: имхо, основная беда в крайне неудачном названии этой уязвимости "Spoofing — Proxy Driver"

Немного продолжу ещё про CVE-2024-26234: имхо, основная беда в крайне неудачном названии этой уязвимости Spoofing - Proxy DriverНемного продолжу ещё про CVE-2024-26234: имхо, основная беда в крайне неудачном названии этой уязвимости Spoofing - Proxy Driver

Немного продолжу ещё про CVE-2024–26234: имхо, основная беда в крайне неудачном названии этой уязвимости "Spoof­ing — Proxy Dri­ver". Складывается ощущение, что есть какой-то виндовый компонент "Proxy Dri­ver", который спуфят (т.е. по определению "один человек или программа успешно маскируется под другую путём фальсификации данных и позволяет получить незаконные преимущества"). А если читать статью Sophos, то там единственное, что можно принять за "Proxy Dri­ver" это, собственно, малварь Catalog.exe и есть. И маскировка там если и есть, то только у зловредного сервиса с описанием "Google ADB Loa­clSock­et [sic] Mul­ti-thread­ing Graph­ics API".

То есть, либо речь о какой-то другой уязвимости (ну а вдруг, с Microsoft-ом я ничему не удивляюсь 😏), либо о совсем уж криво натянутой на глобус сове. 🦉🌏

Причём, для таких кейсов уже есть отлаженная форма заведения: ADV230001 — Guid­ance on Microsoft Signed Dri­vers Being Used Mali­cious­ly. Там как раз про зловредные подписанные драйвера и Win­dows Driver.STL.

Ну или если совсем уж хочется CVE завести, то почему бы не обозначить её как Secu­ri­ty Fea­ture Bypass — Win­dows Driver.STL?

Если же абстрагироваться от неудачного названия (которое всеми воспринимается с покерфейсом 😐, типа так и надо), необновленный Win­dows Driver.STL revo­ca­tion list, из-за которого злоумышленник может запускать зловреды, подписанные сомнительным (утекшим? мошеннически выпущенным?) сертом это вполне себе уязвимость, а в случае зафиксированной эксплуатации вживую, вполне себе уязвимость трендовая.

Единственная уязвимость из апрельского Microsoft Patch Tuesday, для которой Microsoft подтверждает наличие признаков активной эксплуатации вживую, является Spoofing — Proxy Driver (CVE-2024–26234): что это за зверь такой?

Единственная уязвимость из апрельского Microsoft Patch Tuesday, для которой Microsoft подтверждает наличие признаков активной эксплуатации вживую, является Spoofing - Proxy Driver (CVE-2024-26234): что это за зверь такой?
Единственная уязвимость из апрельского Microsoft Patch Tuesday, для которой Microsoft подтверждает наличие признаков активной эксплуатации вживую, является Spoofing - Proxy Driver (CVE-2024-26234): что это за зверь такой?

Единственная уязвимость из апрельского Microsoft Patch Tues­day, для которой Microsoft подтверждает наличие признаков активной эксплуатации вживую, является Spoof­ing — Proxy Dri­ver (CVE-2024–26234): что это за зверь такой?

По этой уязвимости один источник — статья в блоге компании Sophos.

🔻 В декабре 2023 года Sophos входе проверок ложных срабатываний обнаруживает странный файл Catalog.exe с опечатками в свойствах ('Copy­rigth' вместо 'Copy­right', 'rigths' вместо 'rights'). 🙄

🔻 После изучения оказывается, что это бэкдор с валидной подписью Microsoft Win­dows Hard­ware Com­pat­i­bil­i­ty Pro­gram (WHCP). 👾 Sophos ообщили об этой находке Microsoft. Microsoft, на основе этой информации обновили свой список отзыва (Win­dows Driver.STL revo­ca­tion list) и завели CVE-2024–26234.

🔻 А причём тут Proxy? Sophos пишут, что в подозрительный файл встроен крошечный бесплатный прокси-сервер 3proxy, который используется для мониторинга и перехвата сетевого трафика в зараженной системе.

Итого, что мы видим. CVE заведена по сути под конкретную подписанную малварь и обновление списка отзыва драйверов. Нужно ли под такое CVE заводить. Ну если для противодействия атакам требуется произвести обновление Win­dows, то наверное да. 🤷‍♂️ Хотя так и совсем до маразма можно дойти и, например, каждое обновление Microsoft Defend­er Antivirus как CVE оформлять. 🤪

Продолжение

Вышел выпуск новостей SecLab‑а с моей рубрикой по трендовым уязвимостям марта

Вышел выпуск новостей SecLab‑а с моей рубрикой по трендовым уязвимостям марта. 🙂 Пятиминутная рубрика "В тренде VM" начинается с 16:43. 🎞

По сравнению с прошлым месяцем, в рубрике чуть поменьше мемчиков и шутеек, чуть побольше фактологии.

Основным ведущим выпуска в этот раз был Денис Батранков, Александр Антипов пока в отпуске.

Подробности по трендовым уязвимостям марта читайте в дайджесте и на Хабре.