Архив за месяц: Июль 2024

А можно мне, пожалуйста, не заниматься оценкой адекватности средств детектирования уязвимостей?

А можно мне, пожалуйста, не заниматься оценкой адекватности средств детектирования уязвимостей?

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

Да можно. 🙄 Я вообще мало знаю людей, кто этим заморачивается. К сожалению, большинство относится формально. Принимают всё на веру, VM-вендоров лишний раз не стимулируют. 🤷‍♂️

К чему это приводит? Маркетинг VM-вендоров решает, что детекты это коммодити, качество их никому не интересно и продажи не улучшает. Разработчики в VM-вендорах расслабляются. Главное же, чтобы на полностью обновлённой системе всё зелёненькое было, а на необновлённой красненькое. Остальное не так и важно, правда? 😏 VM-продукты деградируют.

Весь пафос VM-специалистов сыпется от того, что источник продетектированных уязвимостей неадекватный. И так оно тянется вплоть до реальных инцидентов, в которых VM-щики становятся крайними. 🤷‍♂️

В итоге имеем порочный круг лени и наплевательства, который гробит всю идею VM-а. 😔

EASM и CAASM - это просто сценарии применения сканера безопасности?

EASM и CAASM - это просто сценарии применения сканера безопасности?

EASM и CAASM - это просто сценарии применения сканера безопасности? Рубрика "занудно реагируем на мемасики". 🙂 У меня был пост по классам решений, включая EASM и CAASM.

EASM - это действительно сервис на основе сканера уязвимостей, который работает в режиме Pentest (без аутентификации). Так что выражение, отчасти, правда. Однако, EASM подразумевает функциональность по самостоятельному определению периметра организации (например, отталкиваясь от доменного имени) и фокус на контроле и учёте активов. Также этот сканер должен быть заточен под проблемы специфичные для периметра, например, искать админки. EASM может быть отправной точкой вендора к развитию полноценного инфраструктурного VM-а. И наоборот, VM-вендор может реализовать EASM модуль.

CAASM фокусируется на интеграции через API с другими системами, содержащими информацию об активах. Если там сканер и используется, то это побочная функциональность. Я бы не стал относить CAASM к "сценариям применения сканера безопасности".

А ты точно умеешь это детектировать? В продолжение предыдущего поста про оценку адекватности средств детектирования уязвимостей

А ты точно умеешь это детектировать? В продолжение предыдущего поста про оценку адекватности средств детектирования уязвимостей

А ты точно умеешь это детектировать? В продолжение предыдущего поста про оценку адекватности средств детектирования уязвимостей. Безусловно, недостаточно одной констатации VM-вендором, что тот или иной способ детектирования уязвимостей реализован в полной мере. Нужно идти ещё глубже.

Берём тот же базовый пример: детектирование уязвимостей на Linux хосте в пакетах из официального репозитория. Казалось бы - чего проще. Парсишь бюллетени безопасности (или даже готовый OVAL-контент Linux-вендора берёшь) и сравниваешь версии пакетов.

В реальности ошибиться можно много где. Самое частое:

🔹 Функция сравнения версий пакетов (например, эпоху не учитывают)
🔹 Источник безопасных версий пакетов (когда в бюллетенях source пакеты, а от них нужно перейти к версиям бинарных пакетов).

Особенно наглядно бывает, когда один хост проверяется несколькими сканерами. И в случае расхождений каждый вендор говорит, что их результаты правильные. 🤷‍♂️🤪 Пока не будет доказано обратное. 😏

Оценка адекватности используемых решений по детектированию уязвимостей

Оценка адекватности используемых решений по детектированию уязвимостей

Оценка адекватности используемых решений по детектированию уязвимостей. Заканчиваю отвечать на пост Алексея Лукацкого с критикой БОСПУУ. Согласен, что оценивать полноту базы детектов уязвимостей и достаточность способов детектирования непросто, и это имеет смысл только в контексте инфраструктуры конкретной организации.

Как оценивать?

🔹 Видим актив в инфре. Задаём вопрос: он в принципе поддерживается средством детектирования?

Если нет, то чешем репу, что делать: стимулировать VM-вендора, покупать другую детектилку / делать её самим, менять инфру.

Если да, идём глубже.

🔹 А как именно происходит детектирование?

Допустим, это Linux хост, и сканер детектирует уязвимости ТОЛЬКО в пакетах установленных из официального репозитория.

Нам этого достаточно? У нас там точно нет софта, установленного по-другому? 😏

Если достаточно, то всё ок.

Если нет - чешем репу как расширить способы детекта (пентест/WEB, анализ контейнеров и т.п.). Или меняем инфру. 🤷‍♂️

Далее

Где SLA, Лебовски?

Где SLA, Лебовски?

Где SLA, Лебовски? В посте с критикой БОСПУУ Алексей Лукацкий задаёт вопрос про SLA для задач на устранение уязвимостей: "Кто его устанавливает? ИТ?" И дальше предполагает, что сроки для устранения критичных уязвимостей будут неадекватно завышены.

Здесь сошлюсь на хорошую статью по управлению уязвимостями, которую я уже разбирал ранее.

SLA на выполнение задач по устранению уязвимостей (плановому и приоритетному) согласовывают совместно ИБ и ИТ/бизнес.

При этом учитывается:

🔹 критичность активов
🔹 требования к доступности активов и к версионности
🔹 технологические окна

Если какие-то активы невозможно обновлять даже в окна, следует рассмотреть возможность дублирования систем или обновления по частям.

Процесс согласования формального SLA непростой. Но если его не установить, задачи на устранение уязвимостей вообще не будут выполняться. 🤷‍♂️ По этой же причине следует аккуратно фиксировать просрочки, разбираться в их причинах и, при необходимости, пересматривать SLA.

Июльский Microsoft Patch Tuesday

Июльский Microsoft Patch Tuesday

Июльский Microsoft Patch Tuesday. Всего 175 уязвимостей, из них 33 набежало между июньским и июльским Patch Tuesday.

Есть 2 уязвимости с признаком эксплуатации вживую:

🔻 Spoofing - Windows MSHTML Platform (CVE-2024-38112). Spoofing подразумевает подделывание чего-то. Но тут непонятно, что именно подделывают. Ждём деталей. Пока известно, что для эксплуатации уязвимости злоумышленник должен отправить жертве вредоносный (MSHTML?) файл, который жертва должна каким-то образом запустить/открыть. Upd. Подъехали детали.
🔻 Elevation of Privilege - Windows Hyper-V (CVE-2024-38080). Эта уязвимость может позволить аутентифицированному злоумышленнику выполнить код с привилегиями SYSTEM. Опять же деталей нет. Под этим, при желании, можно понять и то, что пользователь гостевой ОС может получить привилегии в хостовой ОС (надеюсь, что это не так).

Из остального можно выделить:

🔸 Elevation of Privilege - различные компоненты Windows (CVE-2024-38059, CVE-2024-38066, CVE-2024-38100, CVE-2024-38034, CVE-2024-38079, CVE-2024-38085, CVE-2024-38062, CVE-2024-30079, CVE-2024-38050). EoP-шки в последнее время часто выстреливают.
🔸 Remote Code Execution - Windows Remote Desktop Licensing Service (CVE-2024-38074, CVE-2024-38076, CVE-2024-38077)
🔸 Remote Code Execution - Microsoft Office (CVE-2024-38021)
🔸 Remote Code Execution - Windows Imaging Component (CVE-2024-38060). Достаточно закинуть вредоносный TIFF файл на сервер.
🔸 Remote Code Execution - Microsoft SharePoint Server (CVE-2024-38023, CVE-2024-38024). Требуется аутентификация, но прав "Site Owner" хватит.

🗒 Отчёт Vulristics по июльскому Microsoft Patch Tuesday

Vulristics показывает эксплоит для Spoofing - RADIUS Protocol (CVE-2024-3596) на GitHub, но на самом деле это просто утилита для детектирования.

Трендовые уязвимости июня по версии Positive Technologies

Трендовые уязвимости июня по версии Positive Technologies. Традиционно в 3 форматах:

📹 Рубрика "В тренде VM" в новостном ролике SecLab-а (начинается с 15:03)
🗞 Пост на Хабре, фактически это несколько расширенный сценарий рубрики "В тренде VM"
🗒 Компактный дайджест с техническими деталями на официальном сайте PT

Список уязвимостей:

🔻 EoP в Microsoft Windows CSC (CVE-2024-26229)
🔻 EoP в Microsoft Windows Error Reporting (CVE-2024-26169)
🔻 EoP в Microsoft Windows Kernel (CVE-2024-30088)
🔻 RCE в PHP (CVE-2024-4577)
🔻 EoP в Linux Kernel (CVE-2024-1086)
🔻 InfDisclosure в Check Point Security Gateways (CVE-2024-24919)
🔻 RCE в VMware vCenter (CVE-2024-37079, CVE-2024-37080)
🔻 AuthBypass в Veeam Backup & Replication (CVE-2024-29849)