Уже завтра стартует онлайн-хакатон от команды MaxPatrol VM Positive Technologies по разработке правил детектирования уязвимостей. Ограничений на участие сотрудников PT не было, так что я тоже подался и буду делиться впечатлениями в канале. 😏 Весь в предвкушении. 🤩
Имхо, подключение сообщества к разработке security content‑а это как раз то, что кардинальным образом улучшит полноту и качество детектирования уязвимостей и мисконфигураций VM-продуктами. Т.е. самую их суть.
В новостях разгоняют про новую уязвимость в Chromium (CVE-2024–4671). Насколько я понимаю, в основном из-за строчки в бюллетене безопасности, в котором Google пишут, что им известно о существовании эксплоита для этой уязвимости ("exists in the wild"). Из этого делают вывод, что раз эксплоит есть, то видимо и уязвимость в атаках используется. Имхо, лучше всё же подождать подтвержденных инцидентов или попыток эксплуатации.
Тип уязвимости "use after free". Уязвимость нашли в компоненте Visuals, который отвечает за рендеринг и отображение контента. То, что уязвимость может приводить к RCE вендор НЕ сообщает, но CIS и Hive Pro утверждают, что это возможно. 🤷♂️
Обновления для Chromium/Chrome:
🔹 124.0.6367.201/.202 (Mac/Windows)
🔹 124.0.6367.201 (Linux)
Также стоит ждать обновлений для всех Chromium-based браузеров: Microsoft Edge, Vivaldi, Brave, Opera, Yandex Browser и т.д. И лучше ставить в настройках галку автообновления (если вы доверяете вендору).
Зарелизили материалы по апрельским трендовым уязвимостям. Всего выделили 5 уязвимостей.
🔻 Удалённое выполнение команд в устройствах PaloAlto (CVE-2024–3400) [Горячий пятничный привет]
🔻 4 уязвимости Microsoft Windows (CVE-2022–38028, CVE-2023–35628, CVE-2024–29988, CVE-2024–26234)
🗣 Моя статья на Хабре по мотивам постов из канала
🚀 Дайджест на сайте PT (коротко и по делу)
🟥 Пост в канале PT
🎞 Рубрика "В тренде VM" в ролике SecLab‑а выйдет в понедельник 🙂 Upd. Выложили.
На сайте ФСТЭК выложили финальную версию "Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации". Что изменилось по сравнению с драфтом в части Управления Уязвимостями?
🔻 Поправили опечатку "их сети Интернет".
🔻 В обоих пунктах появилась приписка "или в отношении таких уязвимостей реализованы компенсирующие меры".
Понятно почему появилась приписка про компенсирующие меры — не всегда уязвимости можно исправить обновлением. Но есть опасность, что этим будут злоупотреблять, т.к. не указано какие меры можно считать компенсирующими. Возможно толкование, что компенсирующие меры могут выбираться произвольно. В духе "на десктопе есть EDR, значит все уязвимости на нём скомпенсированы". 🤪 Но даже если меры будут браться строго от вендора или из БДУ непонятно как контролировать, то что они были корректно применены, а главное, что эти меры действительно препятствуют эксплуатации уязвимости. На практике это будет выглядеть так: сканер детектирует уязвимости, а IT/ИБ с покерфейсом говорят "а у нас всё скомпенсировано". 😐 Так что моё мнение — без приписки было лучше, не нужно было создавать такую лазейку.
Также остался вопрос с "датой публикации обновления (компенсирующих мер по устранению)". Такой даты нет в БДУ (равно как и в других базах уязвимостей). Непонятно откуда её массово забирать, чтобы автоматически отслеживать, что организация укладывается в сроки. Вряд ли источник с датами появится, так что видимо на практике в VM-решениях будут использовать какую-то другую дату (например дату заведения уязвимости). А в случае инцидента это будет повод для лишних разбирательств. Имхо, зря это сразу не прояснили.
На эту же тему может быть интересная ситуация: допустим выходит обновление в котором вендор втихую исправляет уязвимость критического уровня опасности. А о существовании этой уязвимости становится известно, допустим, через полгода. В момент публикации данных об этой уязвимости у организации сразу получается просрочка. 🤷♂️ Просто потому, что используется дата, привязанная к обновлению, а не к уязвимости. Надумана ли такая ситуация? Да нет, "silent patches" проблема достаточно распространенная.
В этом, правда, есть и позитивный момент. Чтобы не попасть в такую ситуацию организации придётся выстраивать Patch Management процесс независящий от уязвимостей. И с неплохими требованиями регулярности обновлений: 30 дней для хостов на периметре, 90 дней для десктопов и серверов. 😏
PS: Также pdf-документ выпустили как-то странно, так что по нему не работает поиск. По odt-документу поиск работает нормально.
Вчера Qualys представили CyberSecurity Asset Management 3.0. В названии решения значится "Asset Management", но само решение сразу презентуется нам как "переопределение управления поверхностью атаки" , т.е. EASM. Такая вот гартнеровская маркетинговая мешанина. 🤷♂️ При этом, у Qualys действительно достаточно необычный Asset Managementи и EASM. И необычно как они к этому пришли. Тут, естественно, исключительно мои впечатления как стороннего наблюдателя, никакого инсайда у меня нет.
🔹 В 2020 году Qualys представили решение Global AssetView. Если упрощённо, то пользователи могли бесплатно раскатать облачные агенты Qualys на известные в инфре хосты, развернуть Qualys Passive Sensor для поиска неизвестных активов по трафику и получить некоторое базовое представление о составе инфры и её состоянии (без расчета уязвимостей). Такое Freemium предложение, с которого можно было бы удобно апселить основную функциональность Vulnerability Management и Compliance Management. Ход весьма и весьма смелый.
🔹 В 2021 году как развитие Global AssetView появился продукт CyberSecurity Asset Management. Это уже был заход в полноценное Управление Активами: двусторонняя синхронизация с CMDB ServiceNow, учёт критичности активов, учёт ПО, оценка поверхности атаки при помощи Shodan (последнее тогда не особенно подчёркивали). Насколько я могу понять, изначальная цель CSAM была в том, чтобы отслеживать кейсы, которые влияют на безопасность активов, но уязвимостями, строго говоря, не являются: shadow IT, хосты с подходящими end-of-life (EoL)-of-support (EoS), хосты без установленных EDR, рискованные порты опубликованные в Интернет, мисконфигурации софта и сервисов.
🔹 В 2022 Qualys выпустили CyberSecurity Asset Management 2.0 с интегрированным решением по контролю внешней поверхности атаки (EASM). Сама идея, что EASM можно развивать и продавать в рамках решения по Управлению Активами весьма необычная. Но логика в этом есть. Уменьшение поверхности атаки это не про то, что нужно пропатчить тот или иной торчащий наружу сервер, а про то, что какого-то торчащего наружу старья вообще не должно быть ("if an externally facing asset or its configuration is not necessary for the business, then it should be shut down"). И вот с этой точки зрения EASM это действительно не столько периметровый сканер, сколько хитрая штуковина, которая накидывает неочевидные активы, с некоторой вероятностью относящиеся к компании, и показывает риски с ними связанные. 🐇 🎩 Часть управления активами? Ну видимо да.
Таким образом, насколько я понимаю, сейчас у Qualys есть VMDR (Vulnerability Management, Detection and Response), который включает в себя CSAM (CyberSecurity Asset Management ), который включает в себя EASM (External Attack Surface Management). Такая вот матрёшка. 🪆
А что же в версии CSAM 3.0?
🔻 Убрали упоминания Shodan. "CSAM 3.0 использует новую систему оценки атрибуции и расширяет использование технологий с открытым исходным кодом и собственного интернет-сканера для обеспечения точного обнаружения, атрибуции и оценки уязвимостей" . При атрибуции актива отображаются показатели достоверности (можно по ним фильтровать).
🔻Используются возможности детектирования активов Cloud Agent Passive Sensing (хостовые агенты, снифающие трафик — я о них уже писал)
🔻Коннекторы для интеграции с источниками данных об активах (анонсированы коннекторы для Active Directory и BMC Helix). Видимо раньше интеграции с AD не было. 🤷♂️
Детектирование известных (CVE, БДУ) уязвимостей без аутентификации (в режиме "Пентест"): излишество или необходимость? Есть такое мнение, что при детектировании уязвимостей внутренней инфраструктуры сканировать без аутентификации не нужно вовсе. Что достаточно расставить агенты по хостам. А те хосты, куда агенты установить нельзя, например сетевые устройства, достаточно сканировать с аутентификацией. Дескать сканы без аутентификации всегда менее достоверны, чем сканы с аутентификацией, и нужны они только для сканирования периметра или первичной инвентаризации сети. На мой взгляд, это не совсем правильно. Сканировать без аутентификации на наличие известных уязвимостей, обязательно нужно, особенно в случае хостов с веб-приложениями.
И связано это именно с особенностями детектирования уязвимостей при сканировании с аутентификацией. Возьмём Linux-хосты. Как правило, VM-вендоры при сканировании Linux-хостов с аутентификацией ограничиваются детектированием уязвимостей в пакетах из официального репозитория Linux-вендора. 🤷♂️ Просто потому, что эти уязвимости описываются в общедоступных бюллетенях безопасности или даже в виде формализованного OVAL-контента. Удобно. Научился работать с этим контентом и можно ставить галочку, что Linux-дистриб поддерживается VM-решением. А как насчёт уязвимостей софта, который отсутствует в официальном репозитории Linux-вендора? Вот тут всё сложнее.
Такой софт может быть установлен:
🔹 Из подключенного стороннего репозитория
🔹 Из пакета (вендорского или самосборного) стандартной пакетной системы дистрибутива (deb, rpm), который принесли на хост ручками
🔹 Из альтернативных пакетов для распространения софта (snap, flatpak, appimage и т.д.)
🔹 Из средств распространения модулей (pip, conda, npm и т.д.)
🔹 Из образа контейнера (docker, podman и т.д.)
🔹 Из исходников софта, при этом сборка софта может происходить на том же хосте или собранный софт может быть перенесён в виде бинарных файлов
В идеале, независимо от способа установки софта на хосте, сканер уязвимостей должен его корректно продетектировать, определить его версию, а по версии определить связанные уязвимости. 🧙♂️ Но на практике, из-за того что способов установки софта множество, это весьма нетривиальная задача. 🧐
В итоге мы получаем ситуацию: допустим, у нас есть какой-то коммерческий или опенсурсный софт на Linux-хосте (Zabbix, GitLab, Confluence, Jira). Рыская по хосту по SSH этот софт не так-то просто надёжно найти. А при взгляде на хост извне, он ищется тривиально: сканируем порты, находим web-GUI, зачастую на главной странице находим версию и по ней детектируем уязвимости. При этом мы вообще не зависим от конкретного способа установки и запуска софта на хосте. Главное, что мы сам веб-интерфейс приложения видим. 🤩
Такие "внешние" правила детектирования уязвимостей и самим гораздо проще разрабатывать, и открытой экспертизой можно воспользоваться. Фингерпринтинг для получения CPE в сочетании с поиском в NVD по CPE это, конечно, грязный способ. Зато массовый. 😏 И если грамотно подтачивать и фингепринтилку, и правила детектирования по CPE, то и количество фолзов можно уменьшить до приемлемого уровня. А если ещё и добавить валидацию с помощью проверок с попыткой эксплуатации уязвимости (подтянуть nuclei тот же), то значительный набор уязвимостей можно будет детектировать более чем надежно. 😉
В общем, "пентест"-сканирование для определения известных уязвимостей — must have и для внутрянки тоже, особенно для веб-приложений.
Более 826 новых уязвимостей добавили в NVD за один день 3 мая. Картинка из сервиса CVE.icu, который визуализирует изменения NVD. Также есть выгрузка этих уязвимостей. Большую часть из них, 709, добавили ZDI. А чего это они вдруг? 🤔
В ноябре прошлого года у меня был пост, что ряд трендовых уязвимостей, которые репортили ZDI, отображаются в NVD как "CVE ID Not Found". Так вот, похоже гении из Trend Micro ZDI наконец обратили внимание на то, что их CVE-шки до NVD не доходят и решили это пофиксить таким вот массовым импортом проблемных CVEшек. 🤷♂️ При этом наглядно продемонстрировав масштаб бедствия. 🙂
Не, ну так-то лучше поздно, чем никогда. Но задержку между заведением ZDI-CAN идентификатора и появлением уязвимости в NVD теперь будет занятно посчитать. 😏 Например, для эксплуатируемой в фишинговых атаках RCE — WinRAR CVE-2023–40477 она составила 260 дней. 🤠
PS: окончательная цифра за 3 мая — 847 CVE, но не суть.