1 ноября официально вышел CVSS v4.0, который и так-то никому не нужен, а особенно он не нужен в России. Технические детали были известны ещё у июне, так что тут мало интересного. В чём там суть? Есть такая организация FIRST (пионЭры). Они с 2005 года занимаются развитием  стандарта CVSS для оценки уязвимостей через заполнение опросников. Тема прижилась, стала использоваться в американской National Vulnerability Database, где можно бесплатно получить оценки для CVE уязвимостей в формате CVSS (только базовые метрики).

В принципе и отлично. Но нет покоя одержимым и FIRST периодически выкатывает новую версию CVSS. Причём каждый раз всё более сложную и несовместимую с предыдущей. Строго говоря, нельзя автоматом получить CVSS v3/3.1 из CVSS v2 и наоборот, нужно садиться и перезаполнять опросник. И не просто заполнять, а ориентируясь на разъяснения и примеры заполнения указанные в стандарте.

И ладно бы ещё результат этой оценки был годный, так нет. Поныть на тему того, что оценки по CVSS это какая-то субъективная ерунда это любимое развлечение безопасников. Аз грешный и сам в этом был неоднократно замечен. Достаточно просто погуглить "CVSS critique", чтобы погрузиться в пучины отчаянья.

Станет ли CVSS 4.0 лучше? Посмотрим. Но, имхо нет, т.к. CVSS остаётся таким же опросником, заполняемым субъективно, но теперь несколько иначе и сложнее. Теперь исследователям и аналитикам NIST NVD придётся разобраться в правильном заполнении очередного опросника. Естественно только базовых метрик - остальным никто опять по собственной воле пользоваться не будет. 🙃 На NVD для старых уязвимостей будет только заполнение на CVSS 2.0/3.0/3.1, для новых с какого-то времени будет 3.1 и 4.0, потом только 4.0. Пока First через несколько лет опять всё не поменяют с новым стандартом. 😏🤷‍♂️

А пользователи как лазили на NVD за цифирей от 0 до 10 (Base Score), так и будут лазить. Ну да, этих цифирей теперь будет несколько для разных версий стандарта. Ну наверное будут брать по максимальной версии стандарта или по максимальному значению. 🌝

Теперь о главном: как это заденет методику ФСТЭК по оценке критичности уязвимостей. Тут, как мне кажется, могут быть 3 пути:

1) Игнор. Ну записано в методике 3.0/3.1, делаем как записано. Всё равно, что у американцев другая версия актуальная. Но понятно, что такое положение дел бесконечно продолжаться не может.

2) Признание 4.0. Ну то есть в тексте добавят 3.0/3.1/4.0 или вообще изменят на 4.0 и будьте любезны всю эту методику CVSS 4.0 для оценки уязвимостей у себя имплементировать as is (всё, а не только базовые метрики!) Кажется наиболее вероятным вариантом, хотя мне он решительно не нравится. 😔

3) Отказ от CVSS в пользу своего аналога с долгосрочной поддержкой и бережным переходом на новую версию (с возможностью автоматического пересчёта метрики). Мне кажется это был бы наиболее правильный вариант. И пусть американцы меняют свои опросники хоть каждый месяц, если им так хочется. Вместе с прочей шизой типа переименования терминов "MiTM", "master/slave" и прочее. У них там своя атмосфера. 🤷‍♂️

Как можно реализовать российский аналог CVSS в щадящем режиме без особых изменений методики я уже описывал в рамках своего проекта ОСОКА: форкаем базовые метрики CVSS v3, вместо временных метрик CVSS v3 вводим свои простые и автоматизируемые метрики по эксплуатабельности (самое важное!), оформляем Iinfr в инфраструктурные метрики, делаем рекомендации как получать наши базовые метрики из базового вектора CVSS v2/3/4. Всё прозрачно и является по факту упрощением работы с методикой ФСТЭК, чем усложнением.

@avleonovrus #CVSS #FIRST #NVD #ОСОКА #ФСТЭК #FSTEC

Послушал третий эпизод подкаста КиберДуршлаг про Трендовые Уязвимости. Гостями подкаста в этот раз были Юрий Шкодин и Егор Подмоков из PT Expert Security Center (ESC). Для меня особенно интересный эпизод, т.к. ответ на вопрос куда именно в PT я вышел - вот конкретно к ним. 🙂 Выписал некоторые тезисы.

1. Трендовые уязвимости - уязвимости, которые эксплуатируются сейчас (на которые есть эксплоиты) или которые будут эксплуатироваться в ближайшее время. Это те уязвимости, на которые заказчики должны обратить внимание в первую очередь в своей инфраструктуре.
2. Трендовых уязвимостей не должно быть везде в инфраструктуре или только в DMZ? Дискуссионный вопрос, нужно исходить из модели рисков. Трендовая уязвимость на тестовом стенде внутри IT-инфраструктуры это не очень важная уязвимость.
3. Трендовость Уязвимости зависит от уязвимого продукта. Они могут быть очень специфичными: Church Management система, управления автомобилями и т.п. Необходимо учитывать реальные возможности по детектированию. Продукты, которые неинтересны ни нам, ни заказчикам, мы добавляем в black list, который, при необходимости, пересматриваем.
4. Исходные данные для оценки трендовости собираем из баз уязвимостей, бюллетеней безопасности вендоров, социальных сетей и мессенджеров, баз эксплоитов, публичных репозиториев кода.
5. Фолзы детектов уязвимостей, отчего они? Например, в детекте уязвимостей Windows по KB-шкам. Могут быть ошибки роботов-сборщиков данных. Может быть задержка реагирования на изменение в контенте вендора. Может быть вендор ПО предоставляет информацию об обновлениях недостаточно прозрачно.
6. Форки Open Source продуктов, которые не фиксят и не сообщают об уязвимостях исходного продукта. Призываем вендоров за этим следить. И желательно, чтобы вендоры публиковали информацию о своих уязвимостях в одном месте, идеально в БДУ ФСТЭК.
7. Сложности с детектами. Версионные детекты: уязвимость в выключенной фиче или выключенном ПО это уязвимость? Детекты с эксплуатацией: проверка не сработала, а насколько этому можно верить? Насколько правильно проверки реализованы и на основе каких эксплоитов?
8. Пользовательские детекты для софтов и уязвимостей - крутая тема. Идём в эту сторону.
9. Для отладки детектов необходимы реальные стенды с уязвимыми продуктами. Здесь вопросы с оценкой популярности софта (невозможно поддерживать всё) и нотификациями о выпуске новых версий софта. В эти темы тоже идём.
10. Доставка трендовых уязвимостей в MP VM за 12 часов. Трендовые уязвимости, как правило, начинают эксплуатировать через 24 часа (плюс это требование ФСТЭК из методики оценки критичности). Из них 12 нужно VM вендору на реализацию проверки и 12 нужны клиенту на детекты и исправление. Для более быстрой доставки идём к тому, что в базе MP VM будут все уязвимости, не только те, для которых есть детекты. Нужно будет только быстро добавлять детекты (возможно силами самих клиентов). Ассетная модель позволяет получить сработки без пересканирования по имеющимся данным.
11. BugBounty может использоваться для контроля известных уязвимостей сетевого периметра и выполнения SLA (например хантер может сдавать известные уязвимости старше 30 дней).
12. HCC PT Essentials это минимальный набор требований к конфигурациям, которые обязательно должны выполняться. Идём в сторону возможности реализовывать свои проверки.
13. Идеальный VM вендор. Прозрачность по текущим и будущим фичам (открытый roadmap). Улучшение покрытия продуктов. Самостоятельность заказчиков в плане наполнения базы знаний уязвимостей и детектов, возможность делиться этим контентом через маркетплейс. Метапродукты работающие с минимальным количеством людей. Автоматизированное исправление уязвимостей с аппрувом от IT.

@avleonovrus #КиберДуршлаг #TrendVulns #PositiveTechnologies #MaxPatrolVM #HCC #Microsoft #ФСТЭК #FSTEC #BDU

Парочка занимательных аномалий из National Vulnerability Database. Помните в августе была RCE уязвимость в WinRAR CVE-2023-40477? Так вот, NVD не знает такой уязвимости! CVE ID Not Found. 🤤 Сам RARLAB пишет про эту CVE, ZDI пишет, а NVD типа не при делах. Нет такой CVEшки, потеряли. 🤷‍♂️ Вот уж действительно 404. 😄

А вот помните совсем недавно, в октябре, RCE в Exim CVE-2023-42115 была? Трендовая, все дела. Куча публикаций. А чего NVD? Аналогично! CVE ID Not Found. 🙃

У NVD (вместе с Mitre) была всего одна задача, поддерживать реестр CVEшек, и они фейлятся из раза в раз. 😏

Обе уязвимости заводили, кстати, через ZDI, так что подозреваю здесь ошибку на стороне гениев из Trend Micro. А NVD что, им вообще пофиг.

PS: в BDU есть и первая, и вторая. 👍

@avleonovrus #NVD #ZDI #Exim #WinRAR #BDU #FSTEC

Прожектор по ИБ, выпуск №11 (12.11.2023): не верь описаниям, периметр и Аврора для физиков. Записали очередной эпизод нашего еженедельного подкаста. В этот раз записывали таким составом:

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Иван Шубин

00:00 Здороваемся и смотрим статистику
02:29 Как Лев съездил на Цифротех
07:52 Не верь описанию уязвимости - может внезапно поменяться (на примере недавней Improper Authorization в Confluence CVE-2023-22518)
11:36 Специалисты из Check Point Research раскрыли уязвимость в Microsoft Access, которая может быть использована злоумышленниками для получения NTLM-токенов пользователя Windows
15:31 Парочка занимательных аномалий из National Vulnerability Database
18:27 Про возраст уязвимости и её трендовость
29:38 Ещё один экран Бесконечного VM-a про сетевой периметр
40:05 Делюсь впечатлениями от покупки первого смартфона на Авроре для физиков
55:19 В преддверии Черной пятницы число веб-атак на ретейл России возросло на 50%
57:27 Минцифры России запускает второй этап программы bug bounty, распространив ее на все ресурсы и системы электронного правительства
01:00:47 В Южной Корее робот насмерть прижал мужчину
01:06:11 Иван рекомендует книгу "How vCISOs, MSPs and MSSPs Can Keep their Customers Safe from Gen AI Risks"
01:10:21 Прощание от Льва

@avleonovrus #ПрожекторПоИБ #Цифротех #Atlassian #Colfluence #ImproperAuthorization #MicrosoftAccess #NVD #ZDI #Exim #WinRAR #BDU #FSTEC #TrendVulns #Conficker #RPC #fun #anime #game #education #VMprocess #EverlastingVM #perimeter #blackfriday #Минцифры #bugbounty #AuroraOS #ОМП #Fplus #R570E

Послушал четвёртый эпизод подкаста КиберДуршлаг про Управление Уязвимостями и Харденингом в банке. Гостями подкаста в этот раз были Сергей Алешинский и Андрей Исхаков из ПСБ (Промсвязьбанк). Т.к. я тоже 6 лет VM-ом в банке занимался, было интересно послушать. 🙂 Выписал некоторые тезисы.

1. IT стремятся занять позицию "давайте мы сейчас построим, а потом вы к нам придёте, мы вас послушаем и может быть что-то поправим". ИБ должны не допускать такого.
2. VM это прежде всего процесс взаимодействия людей. Важно уметь договариваться, в том числе на уровне руководства. Необходимость VM следует доносить грамотно, аргументированно и регулярно.
3. Доказывать необходимость исправления уязвимостей непросто, но это развивает технически и IT, и ИБ.
4. В ПСБ был выстроенный процесс обновления десктопов (АРМов), но после 22 года он усложнился. Теперь есть команда в составе RedTeam, которая проверяет обновления и новые версии западного ПО на закладки (дополнительно к проверенным обновлениям из БДУ). Также проходят проверки и собственные разработки.
5. Также применяется исправление уязвимостей путем отказа от legacy систем или внедрения компенсирующих мер (аудит сетевых подключений, максимальное урезание интеграций, обслуживание через терминальные станции).
6. Есть проблема с отсутствием бюллетеней безопасности отечественных вендоров. Отечественных вендоров СЗИ/САЗ это тоже касается.
7. Категоризация активов по сегментам, бизнесам, выделение наиболее критичных скоупов (например, DMZ).
8. Категоризация уязвимостей по автоматизированной методике оценки критичности уязвимостей ФСТЭК.
9. В идеале информацию об активах нужно забирать из супер-актуальной CMDB, которую обслуживает IT. А ИБ должна проводить поиск теневых активов в факультативном режиме. На практике вовлеченность ИБ в поиск проблем CMDB выше, в т.ч. приходится самим искать владельцев систем и обслуживающих подразделений. Периодичность рескана фиксируется в документации на IT-систему. Статус комплаенса систем будет виден на уровне CMDB. Необходимо внедрять VM в ITSM.
10. Проводится сканирование периметра извне. Необходимо следить за состоянием внешних сканеров, т.к. они зачастую добавлены в white list. Для внутренних сканеров, проводящих сканирование с аутентификацией, это ещё более критично.
11. У каждого компонента IT-систем есть утвержденный стандарт настроек. Разработка стандартов настроек выполняется внешней организацией. Проверки на соответствие реализуют сами. Конкретные требования зависят от контура, в котором находится сервер. Желательно иметь возможность перенести этот набор скриптов в VM-решение.
12. Этапы процесса Управления Соответствием: утверждение стандарта, тестирование на ограниченном скоупе, расширение скоупа и контроль соответствия. Центр IT-архитектуры утверждает единый тех. стек допустимых технологий. Его необходимо ограничивать и иметь в виде реестра а-ля CMDB. Проблема расширения стека (в глобальном смысле) это и проблема VM-вендора, который должен уметь всё.
13. При наслоении стандартов (например, ОС и СУБД) могут быть конфликты. Отхождения от стандарта должны согласовываться и журналироваться.
14. Трендовые уязвимости на периметре фиксятся оперативно без формального обоснования критичности. Согласование в рамках конфколла. Но тестирование патча на ограниченном скоупе всё равно необходимо выполнять.
15. Еженедельные отчёты: новая инфраструктура введенная в эксплуатацию, какая инфраструктура прошла проверки, какие уязвимости выявлены с приоритизацией. Отчёты также нужны для аудиторов.
16. Нужно стремиться к открытости VM-решений: полнота базы знаний детектов, обязательство поддерживать API-интеграции.

@avleonovrus #КиберДуршлаг #ПСБ #VMprocess #Compliance #CMDB #HCC #ITSM #ФСТЭК #FSTEC #BDU #RedTeam

Vulristics и BDU уязвимости без идентификаторов CVE. Что делать, если уязвимость содержится в базе уязвимостей БДУ ФСТЭК, но CVE-идентификатора у неё нет? Можно ли обрабатывать такие уязвимости в Vulristics?

Например, в случае с
🔻RCE в 1С-Битрикс: Управление сайтом (BDU:2023-05857)
🔻Уязвимость механизма обновления Dr.Web Enterprise Security Suite (BDU:2014-00226)

Сейчас BDU-идентификаторы можно подавать на вход Vulristics также как и CVE-идентификаторы. Обрабатываться они будут одинаково. Но так как коннектор для BDU пока не реализован, а в других источниках данных BDU-идентификаторы не упоминаются, готовые данные придётся подавать самостоятельно через Custom Data Source.

Таким образом, требуется некоторая ручная работа, но обрабатывать такие уязвимости в рамках единого workflow с CVE-шками вполне реально.

@avleonovrus #Vulristics #BDU #FSTEC #CustomDataSource

Испытал вчера wow-эффект от того как бесплатный AI сервис для написания кода переписал мой Bash-скрипт на Python. Bash-скрипт был примитивный: скачать zip-архив с XML-выгрузкой из БДУ ФСТЭК, распаковать, поискать уязвимости, которые были добавлены в этом году. Я такое накидываю быстро и на автомате. Расплачиваюсь за это последующим рутинным переписыванием на Python. 😕 Автоматизированную же трансляцию толком не сделаешь - слишком много утилит и их особенностей. Или сделаешь? 😏

На удачу забил этот bash-скрипт в сервис с комментарием "rewrite in python" и железяка практически справилась. 🤩 Скачала архив по урлу, распаковала, циклически прошлась по файлу и поискала то, что нужно. Было только несколько минорных ошибок. Magic. 🪄

Продолжу эксперименты с чем-то посложнее, с кучей sed-ов и awk. Но похоже, что будет можно по кайфу фигачить парсеры на Bash-е и влегкую превращать это потом в приличный Python. 😊 Если не прямо сейчас, то в обозримом будущем.

@avleonovrus #bash #python #ФСТЭК #FSTEC #AI #zzzcodeai

ФСТЭК России 50 лет! Сегодня день основания Гостехкомиссии СССР (18 декабря 1973), которая в итоге превратилась во ФСТЭК. С праздником, коллеги! 🎉

ФСТЭК это главный российский регулятор в области Управления Уязвимостями:

🔸 Руководство по организации процесса управления уязвимостями в органе (организации)
🔸 Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств
🔸 База угроз и уязвимостей; регламент добавления
🔸 Бесплатный сканер уязвимостей ScanOVAL
🔸 ГОСТ Р 56546-2015 Классификация уязвимостей информационных систем
🔸 ГОСТ Р 56545-2015 Правила описания уязвимостей
🔸 Методика тестирования обновлений безопасности программных, программно-аппаратных средств

@avleonovrus #ФСТЭК #FSTEC #BDU

Прожектор по ИБ, выпуск №17 (23.12.2023): Слово пацана или стих от Mr. X

🔸 Александр Леонов, "Управление уязвимостями и прочее"
🔸 Лев Палей, "Вести из Палей"
🔸 Максим Хараск, "Global Digital Space"

Перебрались для записи эпизода с ТГ на платформу VK Звонки. По-моему вполне удачно. В первый раз выходим в 1080p! 🙂 Это последний эпизод в этом году, следующий выпуск планируем записать уже в январе.

00:00 Здороваемся и смотрим статистику по предыдущему эпизоду
02:20 Злоумышленники получили доступ к корпоративным системам компании MongoDB
05:35 Декабрьский Linux Patch Wednesday
10:04 ФСТЭК России 50 лет
12:32 CISA BOD 23-01 и аналогичные инициативы отечественных регуляторов
20:41 Презентация POCA Мобайл и Р-ФОН
26:29 Ежегодная предновогодняя Поибешечка
32:12 Хакер, который участвовал во взломе Rockstar Games, останется в закрытой клинике до конца жизни
37:32 Сериал "Слово пацана"
40:27 Производитель косметики EOS выпустил кодовый замок для своего лосьона, чтобы мужчины не могли пользоваться им
44:56 Правительство займётся безопасностью видеоигр
48:22 Запрет на использование телeфонов в школе
51:22 В Санкт-Петербурге проведены аресты по делу о телефонном мошенничестве
53:20 Так совпало - Гарвард и ГРЧЦ Роскомнадзора поделились своими взглядами на развитие ИИ в 2024-м году
59:24 DevSecOps Maturity Model 2023
1:01:25 Прощание в стихах от Mr. X

@avleonovrus #ПрожекторПоИБ #MongoDB #MongoDBAtlas #LinuxPatchWednesday #Vulristics #ФСТЭК #FSTEC #BDU #CISA #BOD2301 #AssetManagement #VMprocess #ROSA #ROSAMobile #AuroraOS #ОМП #РФОН #RUTEQ #Поибешечка #Rockstar #СловоПацана #EOS #videogames #smartphone #ГРЧЦ #Роскомнадзор #DevSecOps

Вышел драфт "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации". Что там с Управлением Уязвимостями?

Есть 2 показателя безопасности, зависящие от оперативности устранения уязвимостей:

🔸 3.2. "На устройствах и интерфейсах, доступных их сети Интернет, отсутствуют уязвимости критического уровня опасности с датой публикации обновлений (компенсирующих мер по устранению) в банке данных угроз ФСТЭК России, на официальных сайтах разработчиков, иных открытых источниках более 30 дней"

🔸 3.3 "На пользовательских устройствах и серверах отсутствуют уязвимости критического уровня с датой публикации обновления (компенсирующих мер по устранению) более 90 дней (не менее 90% устройств и серверов)"

❓Во втором случае не указано откуда дату публикации обновления брать. Наверное нужно сделать единообразно.
❓"доступных их сети Интернет" - опечаточка, "из".

Из пунктов следует, что нужно:

🔻 покрывать все активы детектами уязвимостей
🔻 понимать какие именно активы опубликованы в Интернет
🔻 уметь оценивать критичность уязвимостей по методике ФСТЭК
🔻 отслеживать дату публикации обновления (а не дату публикации самой уязвимости!) в разных источниках 😲

Последнее выглядит как нетривиальная задача, т.к. общего реестра данных по обновлениям не наблюдается, получается ведение такого реестра и наполнение его ляжет на организацию. На практике, скорее всего, придется ориентироваться именно на дату публикации уязвимости, т.к. её гораздо проще определять (непосредственно в NVD/BDU) и, по идее, она должна быть всегда более ранней или равной дате публикации обновления. 🤔 Поэтому, возможно, имеет смысл подкрутить формулировочку, например на "дата публикации уязвимости или обновления (компенсирующих мер по устранению)". И сделать пометочку, что допустимо взять наибольшую из имеющихся дат.

И, в идеале, хотелось бы ещё видеть аналог CISA KEV с непосредственно указанными датами, когда конкретные уязвимости должны быть исправлены.

@avleonovrus #ФСТЭК #FSTEC #КИИ

Завершаю серию постов про свой мини-ресерч уязвимостей БДУ без ссылок на CVE следующими выводами.

🔹 Vulristics теперь умеет работать с БДУ, его можно использовать для приоритизации продетектированных уязвимостей и поиска аномалий в базе БДУ.
🔹 Уязвимостей в БДУ без ссылок на CVE около 2.4% от общего количества, но они представляют большой интерес, т.к. они в других базах уязвимостей не описаны. Особенно интересны уязвимости в отечественных продуктах и те, что с эксплоитами и эксплуатацией вживую.
🔹 Уязвимости в БДУ без CVE это не только уязвимости в отечественных продуктах, но и в Open Source, и в западных проприетарных продуктах.
🔹 Иногда для «уязвимости без CVE» на самом деле есть CVE. 🤷‍♂️ Нужно выявлять такое и репортить.

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

@avleonovrus #Vulristics #БДУ #ФСТЭК #FSTEC #BDU #tb2024 #event

Важное уточнение по поводу БДУ уязвимостей Astra Linux без CVE идентификаторов. Я пообщался в личке с руководителем анализа защищённости ОС Astra Linux Олегом Кочетовым по поводу кейса из вчерашнего поста.

🔹 Это может выглядеть как уязвимость, исправление которой пришло из апстрима Bash, которую зачем-то завели в БДУ по бюллетеню Астры, потеряв по дороге CVE. Но ситуация там совсем другая! Эту уязвимость обнаружили специалисты Астры, но так как она аффектила только Astra Linux, то в апстрим её не репортили (и не получали CVE), а зарепортили только в БДУ. Такие уязвимости можно отличать по идентификаторам "ASE" (ранее "ALV").

🔹 В бюллетенях, исправляющих CVE-шные уязвимости, ссылки на CVE проставляются, но могут быть накладки, когда одну и ту же уязвимость репортят разные вендоры.

Подробнее Олег расскажет 12 апреля на CISO Forum в докладе "Как не утонуть в море уязвимостей или как мы управляем кораблем «ОС Astra Linux»"

@avleonovrus #Vulristics #БДУ #ФСТЭК #FSTEC #BDU #tb2024 #event #Astra

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

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

🔻 В ТОП-е, внезапно, январская трендовая уязвимость Authentication Bypass - Jenkins (CVE-2024-23897). Насколько я понимаю, обычно Linux-дистрибутивы не включают пакеты Jenkins в официальные репозитарии и, соответственно, не добавляют детекты уязвимостей Jenkins в свой OVAL-контент. В отличие от отечественного RedOS. Поэтому самый ранний таймстемп исправления этой уязвимости именно у RedOS.

🔻 2 RCE уязвимости. Самая интересная это Remote Code Execution - Exim (CVE-2023-42118). Когда я выпускал отчёт, я специально не учитывал описание уязвимости и продукты из БДУ (флаги --bdu-use-product-names-flag, --bdu-use-vulnerability-descriptions-flag). Иначе это привело бы к тому, что часть отчёта была бы на английском, а часть на русском. Но оказалось, что для этой уязвимости адекватное описание есть пока только в БДУ. 🤷‍♂️ К этой уязвимости нужно присмотреться, т.к. Exim является достаточно популярным почтовым сервером. Вторая RCE уязвимость браузерная, Remote Code Execution - Safari (CVE-2023-42950).

🔻 2 DoS уязвимости. Denial of Service - nghttp2/Apache HTTP Server (CVE-2024-27316) и Denial of Service - Apache Traffic Server (CVE-2024-31309). Последняя в отчёте классифицируется как Security Feature Bypass, но это из-за некорректного CWE в NVD (CWE-20 - Improper Input Validation)

🔻 2 браузерные Security Feature Bypass - Chromium (CVE-2024-2628, CVE-2024-2630)

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

🔸 Большое количество RCE уязвимостей (71). Большая часть из них в продукте gtkwave. Это программа просмотра файлов VCD (Value Change Dump, дамп изменения значения), которые обычно создаются симуляторами цифровых схем. Выглядят опасными уязвимости Remote Code Execution - Cacti (CVE-2023-49084, CVE-2023-49085), это решения для мониторинга серверов и сетевых устройств.

🔸 Security Feature Bypass - Sendmail (CVE-2023-51765). Позволяет внедрить сообщения электронной почты с поддельным адресом MAIL FROM.

🔸 Пачка Cross Site Scripting в MediaWiki, Cacti, Grafana, Nextcloud.

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

🗒 Апрельский Linux Patch Wednesday

@avleonovrus #LinuxPatchWednesday #Vulristics #BDU #FSTEC #Jenkins #RedOS #Exim #Safari #Apache #nghttp2 #ApacheTrafficServer #Chromium #gtkwave #Cacti #Sendmail #MediaWiki #Grafana #Nextcloud

На сайте ФСТЭК выложили финальную версию "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации". Что изменилось по сравнению с драфтом в части Управления Уязвимостями?

🔻 Поправили опечатку "их сети Интернет".
🔻 В обоих пунктах появилась приписка "или в отношении таких уязвимостей реализованы компенсирующие меры".

Понятно почему появилась приписка про компенсирующие меры - не всегда уязвимости можно исправить обновлением. Но есть опасность, что этим будут злоупотреблять, т.к. не указано какие меры можно считать компенсирующими. Возможно толкование, что компенсирующие меры могут выбираться произвольно. В духе "на десктопе есть EDR, значит все уязвимости на нём скомпенсированы". 🤪 Но даже если меры будут браться строго от вендора или из БДУ непонятно как контролировать, то что они были корректно применены, а главное, что эти меры действительно препятствуют эксплуатации уязвимости. На практике это будет выглядеть так: сканер детектирует уязвимости, а IT/ИБ с покерфейсом говорят "а у нас всё скомпенсировано". 😐 Так что моё мнение - без приписки было лучше, не нужно было создавать такую лазейку.

Также остался вопрос с "датой публикации обновления (компенсирующих мер по устранению)". Такой даты нет в БДУ (равно как и в других базах уязвимостей). Непонятно откуда её массово забирать, чтобы автоматически отслеживать, что организация укладывается в сроки. Вряд ли источник с датами появится, так что видимо на практике в VM-решениях будут использовать какую-то другую дату (например дату заведения уязвимости). А в случае инцидента это будет повод для лишних разбирательств. Имхо, зря это сразу не прояснили.

На эту же тему может быть интересная ситуация: допустим выходит обновление в котором вендор втихую исправляет уязвимость критического уровня опасности. А о существовании этой уязвимости становится известно, допустим, через полгода. В момент публикации данных об этой уязвимости у организации сразу получается просрочка. 🤷‍♂️ Просто потому, что используется дата, привязанная к обновлению, а не к уязвимости. Надумана ли такая ситуация? Да нет, "silent patches" проблема достаточно распространенная.

В этом, правда, есть и позитивный момент. Чтобы не попасть в такую ситуацию организации придётся выстраивать Patch Management процесс независящий от уязвимостей. И с неплохими требованиями регулярности обновлений: 30 дней для хостов на периметре, 90 дней для десктопов и серверов. 😏

PS: Также pdf-документ выпустили как-то странно, так что по нему не работает поиск. По odt-документу поиск работает нормально.

@avleonovrus #ФСТЭК #FSTEC #КИИ

Также распишу более подробно про эксплуатирующуюся вживую уязвимость Elevation of Privilege - Windows DWM Core Library (CVE-2024-30051) из майского Microsoft Patch Tuesday.

💻 DWM (Desktop Window Manager) - это композитный оконный менеджер в Microsoft Windows, начиная с Windows Vista, который позволяет использовать аппаратное ускорение для визуализации графического пользовательского интерфейса Windows..

🦹‍♂️ Злоумышленник, получив первоначальный доступ к уязвимому Windows хосту, может проэксплуатировать данную уязвимость DWM, чтобы поднять свои привилегии до уровня SYSTEM. Это позволит ему закрепиться на хосте и продолжить развитие атаки.

👾 Исследователи из Лаборатории Касперского делятся в своём блоге интересной историей о том, как они нашли информацию об этой уязвимости в таинственном документе на ломаном английском, загруженном на VirusTotal 1 апреля 2024 года. VirusTotal - это бесплатная служба, осуществляющая анализ подозрительных файлов и ссылок на предмет выявления вирусов, червей, троянов и всевозможных вредоносных программ. В ходе исследования эксперты ЛК подтвердили наличие уязвимости, описанной в документе, сообщили о ней в Microsoft, и, начиная с середины апреля, фиксировали эксплуатацию этой уязвимости банковским трояном QakBot и другими зловредами. Таким образом атаки начали фиксироваться где-то за месяц до выхода патчей Microsoft.

🛡 База уязвимостей БДУ ФСТЭК сообщает о наличии эксплоита в паблике, однако в сплоит-паках и на GitHub он пока не находится.

🟥 Positive Technologies относит уязвимость к трендовым,

@avleonovrus #DWM #Microsoft #Kaspersky #QakBot #BDU #FSTEC #PositiveTechnologies

Ездили сегодня с участниками PHDшной дискуссии в гости к ФСТЭК. Обсуждали наши предложения по улучшению БДУ (24 пункта совместно насобирали). Впечатления от 3 часов обсуждения самые приятные. 👍 Очень обстоятельно и конструктивно по пунктам прошлись. Особенно большие надежды возлагаю на улучшение формализации данных по уязвимым версиям ПО, чтобы можно было в некоторой перспективе делать что-то вроде CPE-детектов. Свою ОСОКу, к сожалению, я пока не продал. 🤷‍♂️😅

Режим там строгий, так что без фоток. Иллюстрирую общедоступным скриншотом из Яндекс-панорам. 🙂

@avleonovrus #FSTEC #ФСТЭК #БДУ #BDU