Архив метки: vulnerability

По поводу критичных уязвимостей Remote Code Execution - VMware vCenter (CVE-2024-37079, CVE-2024-37080)

По поводу критичных уязвимостей Remote Code Execution - VMware vCenter (CVE-2024-37079, CVE-2024-37080)

По поводу критичных уязвимостей Remote Code Execution - VMware vCenter (CVE-2024-37079, CVE-2024-37080). vCenter это продукт для централизованного управление виртуальной инфраструктурой на платформе VMware vSphere.

Обе уязвимости были исправлены 17 июня. У них одинаковое описание и CVSS 9.8.

Уязвимости связаны с переполнением кучи в реализации протокола DCERPC. Злоумышленник, имеющий сетевой доступ к vCenter Server, может отправить специально подготовленный сетевой пакет и потенциально получить RCE.

Публичного эксплоита и признака эксплуатации вживую пока нет, однако:

🔸 Уязвимости очень похожи по описанию на прошлогоднюю эксплуатируемую RCE уязвимость vCenter (CVE-2023-34048). И CVSS вектор такой же.

🔸 "Скриншот vSphere Client", интерфейса для vCenter, стал своеобразным мемом злоумышленников, подтверждающим, что в ходе атаки им удалось скомпрометировать виртуальную инфраструктуру организации. Цель очень лакомая!

Обязательно обновляйтесь!

Ещё немного про то, что не все сканеры одинаково хороши

Ещё немного про то, что не все сканеры одинаково хороши

Ещё немного про то, что не все сканеры одинаково хороши. Так как сейчас нет обязательной или даже добровольной системы сертификации сканеров уязвимостей, то под наименованием "сканер уязвимостей" может скрываться что угодно.

Доводя до абсурда, можно написать утилиту, которая будет детектировать одну CVE-шку, приделать к ней вебгуй с дашбордами и презентовать это как "сканер уязвимостей", альтернативу ТОП-овым решениям на рынке. Уязвимость ищет? Ищет! А то что одна - а сколько вам надо? Не знаете? Ну так чего теперь. 🤪

А если перелицевать и соединить опенсурсные утилиты, которые уязвимости действительно детектят (GVM/OpenVAS, OpenSCAP/Wazuh, Nmap с плагинами, Nuclei и т.д.), вообще не прикопаешься. 😉 С хостами софтина взаимодействует, список уязвимостей выдаёт. Достаточно ли хорошо? А фиг его знает. 🤷‍♂️

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

Не сканер детектирует уязвимости, а VM-щик детектирует уязвимости с помощью сканера

Не сканер детектирует уязвимости, а VM-щик детектирует уязвимости с помощью сканера

Не сканер детектирует уязвимости, а VM-щик детектирует уязвимости с помощью сканера. Такая вот невероятно глубокая мысль. 🙂 Сканер уязвимостей это просто инструмент. Если этот инструмент не выполняет заявленные функции, это не снимает ответственность с того, кто этот инструмент закупил и использует.

Представим ситуацию: сканер фолснегативил при детекте уязвимости, через неё поломали организацию. VM-щик бежит с претензией к VM-вендору. После боданий, если получилось доказать проблему, вендор извиняется и выпускает обновлённый детект. И всё. А из-за этой уязвимости возможно всю инфру пошифровали. 🤷‍♂️ И кто в этой ситуации будет крайним и будет иметь бледный вид?

Пока нет обязательной сертификации VM-решений, предъявляющей требования к детектированию уязвимостей, и/или ответственности за некачественный детект, оценка качества работы решений целиком лежит на клиенте. И, к сожалению, делать это нужно не только перед закупкой, но и в течение всего периода эксплуатации.

Что там у Greenbone и OpenVAS?

Что там у Greenbone и OpenVAS?

Что там у Greenbone и OpenVAS? Попался на глаза относительно свежий ролик Greenbone AG "Demystifying Greenbone" (вышел 3 месяца назад). Хороший такой ликбез по OpenVAS/GVM и куда ветер дует.

Что для себя отметил:

🔸 Greenbone корректно, но настойчиво отдаляются от бренда OpenVAS. Формула теперь такая: "Greenbone - это программное обеспечение с открытым исходным кодом и богатой историей". 😉

🔸 Greenbone Community Feed это для домашних продуктов "Home Application (only)", таких как Ubuntu Linux, AVM Fritzbox, MS Office. Если хотите комплаенса и "Enterprise grade" ПО, такого как MS Exchange, Palo Alto, Cisco IoT/OT, то нужен платный Greenbone Enterprise Feed. Был удивлён, что в бесплатном фиде есть немного комплаенса - German Policy IT-Grundschutz. Видимо для демки.

🔸 Методично отказываются от NASL-ового движка OpenVAS в пользу своего нового сканера Notus. В последнем стабильном релизе пишут, что Notus потенциально заменяет логику всех NASL-скриптов для локальных проверок: "Replaces the logic of potentially all NASL-based local security checks". Правда я что-то не нашёл в коде логику проверок для Windows, возможно имеются ввиду проверки только для Linux. 🤷‍♂️ Кстати, последней релиз был в июле 2022. В прошлом году стейбл так и не выпустили, но на GitHub новые пакеты выходят довольно часто.

В целом, прикольно, что до сих пор что-то движется и даже выкладывается в open source, но позывов бежать тестить это дело как не было, так и нет. Во-первых, с куцым контентом непонятен практический смысл, т.к. сканы будут заведомо недостоверными. Но даже не в контенте дело. Контент можно и собственный нагенерить, если прям очень хочется. Сама архитектура кажется переусложнённой и с кучей легаси. Одних репозиториев с какими-то либами и утилитами 62. 🫣 Вот уж действительно порождение "сумрачного германского гения". 🙂 Всё вроде так-то по уму, параллельно и перпендикулярно, но работать с этим решительно невозможно. 😣 Но будем наблюдать дальше. 😉

Нужно ли ставить целью снижение количества уязвимостей до нуля?

Нужно ли ставить целью снижение количества уязвимостей до нуля?

Нужно ли ставить целью снижение количества уязвимостей до нуля? В канале у Алексея Лукацкого сегодня про снижение веса как метафору исправления уязвимостей:

"Поэтому не надо ставить целью снижение количества инцидентов или уязвимостей до нуля - это опасно для службы ИБ. Выброшенные на ветер деньги, стресс… 🤔 Нужен баланс, приоритизация и вот это вот все."

Имхо, цель снижения количества уязвимостей до 0 нужно ставить. Но нужно уточнить: каких именно уязвимостей?

❌ Речь не о том, что в инфре не должно быть известных уязвимостей в любой момент времени. Это нереалистично.

✅ Речь о том, что каждая известная уязвимость должна находиться в процессе исправления (планового или приоритетного). Должно быть понимание кто, как и в какие сроки её исправляет. А уязвимостей, на которые мы тупо забили (вообще не продетектили, или продетектили, но посчитали не требующими исправления и т.п.) должно быть 0.

Метафора снижения веса тут не работает. Вес может быть нормальным. Уязвимость всегда ненормальна. И про уязвимость всегда недостаточно информации. Сегодня мы считаем, что это неэксплуатабельная ерунда, а через 3 месяца внезапно начинаем одурело бить в рынду. Ну вот так оно работает. 🤷‍♂️ Невозможно со стопроцентной вероятностью угадать, где и когда оно выстрелит.

Нет, ну если нравится подрываться и бежать фиксить, когда появляются признаки эксплуатации - ок. Это тоже не самый плохой вариант. Авось эти признаки будут не в вашей инфре. Но ведь гораздо лучше, если уязвимость будет исправлена в плановом порядке хотя бы за месяц-два и к моменту начала эксплуатации вы будете расслабленно наблюдать всю эту суету со стороны. Разве нет?

Так что как по мне - лучше стремитесь к 0 уязвимостей, которые НЕ находятся в процессе исправления. Да, вряд ли этот идеальный результат удастся достичь, но результат будет всяко лучше, чем если успокаивать себя, что все уязвимости исправлять не нужно, а нужно исправлять только самое-самое "красненькое". Объявлять такое за норму это уже, продолжая метафору снижения веса, бодипозитив в самых его гротескных и нездоровых формах. 😉

Повышение критичности уязвимости Elevation of Privilege - Windows Error Reporting Service (CVE-2024-26169)

Повышение критичности уязвимости Elevation of Privilege - Windows Error Reporting Service (CVE-2024-26169)

Повышение критичности уязвимости Elevation of Privilege - Windows Error Reporting Service (CVE-2024-26169). В случае успешной эксплуатации злоумышленник может получить привилегии SYSTEM. Уязвимость была исправлена в мартовском Microsoft Patch Tuesday. Как это частенько бывает, тогда эту уязвимость никто не выделял. 🤷‍♂️

Однако, через 3 месяца, 12 июня, исследователи Symantec сообщили об атаках, связанных с известным шифровальщиком Black Basta, в которых использовались эксплоиты для данной уязвимости. Если верить меткам времени компиляции, эти эксплоиты были созданы задолго до выхода патчей от Microsoft, в феврале 2024 или даже в декабре 2023 года. Конечно, эти временные метки злоумышленники могли и подделать, но зачем? 🤔

13 июня уязвимость была добавлена в CISA KEV. В паблике эксплоита пока не видно.

Мораль та же: оценка и приоритизация уязвимостей хорошо, а регулярная безусловная установка обновлений - лучше.

Вышла новость, что VulnsIO интегрировали с SGRC SECURITM

Вышла новость, что VulnsIO интегрировали с SGRC SECURITM

Вышла новость, что VulnsIO интегрировали с SGRC SECURITM. Для настройки интеграции нужно ввести в SECURITM адрес API сервиса VulnsIO и токен для аутентификации, при необходимости указать периодичность синхронизации и включить/выключить создание новых активов на основе данных VulnsIO.

Помимо собственно уязвимостей, также прокидывают сырые данные по активам. Это позволяет делать дополнительный анализ в SECURITM:

🔸 контролировать установленное ПО по черным и белым спискам
🔸 контролировать запущенные сервисы
🔸 контролировать учётные записи
🔸 формировать метрики безопасности и использовать их в управлении рисками и соответствии требованиям

Классный пример того, что можно делать поверх сырых данных, собираемых VM-решением. Если вы пользуетесь VulnsIO и хотите сделать что-то такое самостоятельно, то у меня был отдельный пост про работу с их API.

Upd. В первой версии поста было про то, что SECURITM исключительно облачный. Это не так, у них есть on-prem вариант!