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

По поводу критичной уязвимости Authentication Bypass - Veeam Backup & Replication (CVE-2024-29849)

По поводу критичной уязвимости Authentication Bypass - Veeam Backup & Replication (CVE-2024-29849)

По поводу критичной уязвимости Authentication Bypass - Veeam Backup & Replication (CVE-2024-29849). Veeam B&R - клиент-серверное ПО для централизованного резервного копирования виртуальных машин в средах VMware vSphere и Microsoft Hyper-V.

Уязвимость нашли в компоненте Backup Enterprise Manager - веб-консоль для управления и создания отчетов. Неаутентифицированный злоумышленник может войти в веб-консоль от имени любого пользователя. CVSS 9.8.

🔸 Уязвимость была исправлена вендором 21 мая.

🔸 Через 3 недели, 10 июня, исследователь под ником SinSinology выложил в своём блоге разбор этой уязвимости (на основе анализа патча) и PoC для неё.

Подтверждений эксплуатации уязвимости в реальных атаках пока нет, но, вероятнее всего, скоро будут. Компрометация бэкапов не менее лакомая цель, чем компрометация виртуальной инфраструктуры.

До 2022 года продукты Veeam были популярны в России и наверняка остаётся ещё много инсталляций. 🤔

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

По случаю пятницы поделюсь одним своим загоном

По случаю пятницы поделюсь одним своим загоном

По случаю пятницы поделюсь одним своим загоном. В одной небольшой азиатской стране есть небольшой ИБ-вендор, который предлагает сервис по управлению поверхностью атаки и редтимингом. И ещё публикует крутые ресёрчи по уязвимостям. И всё у них хорошо кроме названия.

Их название с точностью до одной буквы совпадает с кратким названием журнала, который издаёт одна религиозная организация, признанная в России экстремистской. Журнал этот вполне известный, в книге рекордов значится как "самый распространяемый в мире". Полное название журнала (на русском) есть в списке экстремистских материалов.

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

🔸 Просто писать как есть. Слово общеупотребительное, на английском, разница в букву - вроде норм. Или не норм? 🤔
🔸 Написать, что это вот не те, которые запрещённые и в реестре, просто совпадение. Вроде правильно, но мегастранно. 🤷‍♂️
🔸 Вообще не ссылаться на них от греха подальше. 🙈🙂

По поводу критичных уязвимостей 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 уязвимостей, которые НЕ находятся в процессе исправления. Да, вряд ли этот идеальный результат удастся достичь, но результат будет всяко лучше, чем если успокаивать себя, что все уязвимости исправлять не нужно, а нужно исправлять только самое-самое "красненькое". Объявлять такое за норму это уже, продолжая метафору снижения веса, бодипозитив в самых его гротескных и нездоровых формах. 😉