Архив за месяц: Ноябрь 2023

Про возраст уязвимости и её трендовость

Про возраст уязвимости и её трендовость

Про возраст уязвимости и её трендовость. В комментах к предыдущему посту Андрей Бешков поднимает правильную тему.

Вспоминаю сводки по эксплуатации уязвимостей от Microsoft. И там статистика показывает что больше всего эксплуатируют не модные «трендовые» а старые давно закрытые уязвимости.

Например как с Conficker который распространялся через уязвимость закрытую за много много месяцев до его появления. 😉

Трендовость уязвимости не зависит модности или наличия патчей. Она зависит от наличия (или экспертной оценки скорого появления) эксплоитов, критичных атак и актуальности уязвимого продукта для клиентов.

Cпорный вопрос: может ли уязвимость признанная трендовой перестать быть трендовой со временем?

Моё текущее мнение, что нет, не может. Так что и конфикеровскую CVE-2008-4250 я бы продолжал держать в списке трендовых. Несмотря на то, что ОС-и, которые она аффектила (Windows 2000/XP/Vista, Windows Server 2003/2008/2008 R2) актуальными быть перестали. 🤷‍♂️

➡️ Опрос

Послушал третий эпизод подкаста КиберДуршлаг про Трендовые Уязвимости

Послушал третий эпизод подкаста КиберДуршлаг про Трендовые Уязвимости

Послушал третий эпизод подкаста КиберДуршлаг про Трендовые Уязвимости. Гостями подкаста в этот раз были Юрий Шкодин и Егор Подмоков из 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.

Прожектор по ИБ, выпуск №10 (06.11.2023) с Иваном Шубиным: не суй TMUI, балансеры и Бесконечный VM

Прожектор по ИБ, выпуск №10 (06.11.2023) с Иваном Шубиным: не суй TMUI, балансеры и Бесконечный VM. Записали новый эпизод с небольшим опозданием, но в усиленном составе:

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

00:00 Здороваемся и смотрим статистику по просмотрам. Меньше 100 просмотров за неделю не набрали - печаль. 😔
02:33 Лев сходил на конференцию Норникеля "обратного типа", где ему подарили табличку, а также провёл бесплатную ПоИБэшечку
09:29 RCE и SQLi в F5 BIG-IP. "Не суй наружу свой TMUI"
12:34 Опрос "Что вы используете в качестве балансировщика нагрузки в вашей организации (в России)?"
19:13 Атаки на Госуслуги в Германии и России. У нас-то получше ситуация
20:23 Вайпилка для Confluence
25:35 RCE в Apache ActiveMQ
27:55 У Битрикс обнаружили 8 уязвимостей, в их числе RCE
31:14 Активность небезызвестного ботнета Mozzi ушла в небытие
32:34 Более 40 стран навсегда откажутся от уплаты выкупов хакерам-вымогателям
36:10 Мем недели: Решил выпускник ВУЗа выбрать, каким направлением ИБ он будет заниматься…
38:00 Аниме-новелла про Управление Уязвимостями? Обсуждаем, что бы это могла быть за игра, выбираем варианты на первом "скриншоте", приглашаем поучаствовать в разработке 😉
46:16 Скарлетт Йоханссон судится с разработчиками приложения, использовавшего ее голос без разрешения
49:50 Прощание от Максима Хараска и лучи добра для chaikae!

Выпустил ролик на 12 минут по итогам октября для своих англоязычных ресурсов

Выпустил ролик на 12 минут по итогам октября для своих англоязычных ресурсов. Интенсивный и интересный месяц был. Я вышел на новую работу, активно дорабатывал Vulristics, запустил Linux Patch Wednesday (пока не получил значительного отклика, но вижу здесь перспективы), традиционно проанализировал Microsoft Patch Tuesday, разобрался с кучей других уязвимостей и даже тему с обучением VM-у дальше продвинул. И ноябрь тоже бурно начался. Посмотрим, что в итоге выйдет. 🙂

---

Hello everyone! October was an interesting and busy month for me. I started a new job, worked on my open source Vulristics project, and analyzed vulnerabilities using it. Especially Linux vulnerabilities as part of my new Linux Patch Wednesday project. And, of course, analyzed Microsoft Patch Tuesday as well. In addition, at the end of October I was a guest lecturer at MIPT/PhysTech university.

00:29 Back to Positive Technologies
00:59 Vulristics NVD Data Source
02:20 Vulristics Custom Data Source
03:22 Linux Patch Wednesday Project
04:16 Linux Patch Wednesday October 2023
05:49 Microsoft Patch Tuesday October 2023
09:12 Other Vulnerabilities October 2023
10:14 Miercom released a report "Vulnerability Management Competitive Assessment"
10:54 Vulners presented AI Score v2
11:31 My PhysTech Lecture

🎞 Video
🎞 Video2 (for Russia)
📘 Blogpost

Под конец недели пришла в голову идея игрушки-обучалки по Vulnerability Management-у

Под конец недели пришла в голову идея игрушки-обучалки по Vulnerability Management-у

Под конец недели пришла в голову идея игрушки-обучалки по Vulnerability Management-у. Рабочее название "Бесконечный VM". 😁 По сюжету Олег Иванович Игнатов устраивается на работу в компанию ООО "ГазБанкСервис" и получает от своей начальницы, Анны Михайловны Смирновой, задачу - внедрить в организации Vulnerability Management процесс.

Как вам? Поиграли бы в такое?

1 ноября официально вышел CVSS v4.0, который и так-то никому не нужен, а особенно он не нужен в России

1 ноября официально вышел CVSS v4.0, который и так-то никому не нужен, а особенно он не нужен в России

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. Всё прозрачно и является по факту упрощением работы с методикой ФСТЭК, чем усложнением.

Вот это, похоже, громкая тема будет - RCE в Apache ActiveMQ (CVE-2023-46604)

Вот это, похоже, громкая тема будет - RCE в Apache ActiveMQ (CVE-2023-46604)

Вот это, похоже, громкая тема будет - RCE в Apache ActiveMQ (CVE-2023-46604). Что это вообще такое?

Apache ActiveMQ — брокер сообщений с открытым исходным кодом (распространяется под лицензией Apache 2.0), реализующий спецификацию JMS (Java Message Service) 1.1. Среди возможностей — кластеризация, возможность использовать для хранения сообщений различные СУБД, кэширование, ведение журналов.

Никогда раньше не сталкивался. 🤷‍♂️ Но вот у джавистов, похоже, достаточно популярная штука. Пишут, что 7к в Интернет торчат, 3к уязвимы. 🌝

Согласно описанию на NVD, уязвимость позволяет злоумышленнику с сетевым доступом выполнять произвольные shell команды. CVSS Base Score 10/10. Есть публичный PoC и рассказ Rapid7 о том, что уязвимость уже используется шифровальщиками. Причём там пошифровали Windows хосты. 🧐 Хороший повод поискать это у себя в инфре (если не на периметре 😉).