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

БОСПУУ и светофоры

БОСПУУ и светофоры

БОСПУУ и светофоры. То, что вы видите на схеме БОСПУУ это характеристики нормального функционирующего Vulnerability Management процесса. Есть адекватный поток продетектированных уязвимостей, он обрабатывается, задачи на устранение уязвимостей заводятся, выполнение задач отслеживается.

А что, если у вас, как в посте Алексея Лукацкого, 10% активов не покрыты детектами? И, более того, эти активы не оценены и вы не знаете есть ли там целевые или ключевые системы. Это значит, что нормального VM-процесса у вас нет. 🤷‍♂️ И ваши красивые дашборды не отображают реального состояния инфры. Можно, как описывается в том же посте, спрятаться за светофорчик: 90% есть, красим в зелёненький. 🚦👌 Но это самообман и обман руководства организации. Заканчивается это плохо. В случае инцидента светофорчик вас не спасёт.

Рекомендую не приукрашивать положение дел, а приводить VM-процесс к нормальному функционирующему состоянию, которое подразумевает контроль всех активов и всех уязвимостей.

Обновил схему Базовой Оценки Состояния Процесса Управления Уязвимостями (БОСПУУ)

Обновил схему Базовой Оценки Состояния Процесса Управления Уязвимостями (БОСПУУ)

Обновил схему Базовой Оценки Состояния Процесса Управления Уязвимостями (БОСПУУ). Теперь там 4 компонента:

🔻 Адекватность используемых решений по детектированию уязвимостей
🔻 Анализ уязвимостей и заведение задач на устранение уязвимостей 🆕
🔻 Охват инфраструктуры, работа с активами и ответственными за устранение уязвимостей
🔻 Отслеживание выполнения SLA по задачам на устранение уязвимостей для скоупов активов

По сравнению с версией 0.0.5, разнёс работу с активами/ответственными и анализ уязвимостей/заведение задач на исправление. Подрихтовал формулировки, чтобы было меньше неоднозначного. Сознательно убрал про сканирование сетей - это укладывается в "нет активов без регулярных проверок на уязвимости".

Это всё ещё драфт, но вроде выглядит уже более-менее прилично и кажется, что всё основное в VM-процессе охватывает. Можно потихоньку отвечать на критику от Алексея Лукацкого. 😉

Если видите недочёты - не стесняйтесь, пишите в личку @leonov_av. 🙂

В непожатом виде

RCE от root-а в OpenSSH "regreSSHion" (CVE-2024-6387)

RCE от root-а в OpenSSH regreSSHion (CVE-2024-6387)

RCE от root-а в OpenSSH "regreSSHion" (CVE-2024-6387). Уязвимость нашли эксперты компании Qualys. Неаутентифицированный удалённый злоумышленник может выполнять произвольный код от root-а. Звучит жутко. 😱🙂

Эта уязвимость - регресс ранее исправленной уязвимости CVE-2006-5051. Для неё, кстати, признаков эксплуатации вживую и эксплоитов не видно.

🔻 Регресс произошёл в октябре 2020 г., начиная с OpenSSH 8.5p1
🔻 Уязвимы "glibc-based Linux systems" в конфигурации по умолчанию, OpenBSD уязвимости не подвержена
🔻 В Интернете 14 миллионов потенциально уязвимых хостов
🔻 Qualys эксплоит обещают не публиковать, но весьма вероятно, что эксплоит напишут сторонние исследователи по их подробному write-up-у

Уязвимые версии:

❌ OpenSSH 4.4p1
❌ 8.5p1 = OpenSSH 9.8p1 Неуязвимые версии: ✅ 4.4p1 = OpenSSH 8.5p1
✅ OpenSSH >= 9.8p1

Upd. В описании релиза пишут, что атака 32-битной системы с ASLR в лаборатных условиях заняла 6-8 часов. Видимо процесс всё же непростой. 😉

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

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

Повышение критичности уязвимости Elevation of Privilege - Windows Kernel (CVE-2024-30088). Уязвимость свежая, из июньского Microsoft Patch Tuesday. Я её выделял в обзоре, так как для неё, согласно CVSS вектору, существовал приватный Proof-of-Concept Exploit. Но подробностей не было. Было ясно только то, что в случае успешной эксплуатации, злоумышленник может получить привилегии SYSTEM. Согласно бюллетеню ZDI, уязвимость затрагивает реализацию NtQueryInformationToken и заключается в отсутствии правильной блокировки при выполнении операций над объектом.

24 июня, через 2 недели после июньского Patch Tuesday, на GitHub появился репозиторий с техническими деталями по этой уязвимости и PoC-ом эксплоита. Также доступно видео с запуском утилиты для получения привилегий SYSTEM.

В последнее время EoP/LPE уязвимости Windows очень часто докручивают до реальной эксплуатации. Обращайте, пожалуйста, на них внимание и исправляйте заранее.

БОСПУУ и/или результативный подход? Как правильно заметил Алексей Лукацкий в сегодняшнем посте, я начал формулировать своё видение оценки состояния VM-процесса в ответ на его материалы про измерение результативности VM-решения (поломают нас или нет) с использованием временных оценок Time to Notify/eXploit/Patch/Eliminate и т.д

БОСПУУ и/или результативный подход? Как правильно заметил Алексей Лукацкий в сегодняшнем посте, я начал формулировать своё видение оценки состояния VM-процесса в ответ на его материалы про измерение результативности VM-решения (поломают нас или нет) с использованием временных оценок Time to Notify/eXploit/Patch/Eliminate и т.д

БОСПУУ и/или результативный подход? Как правильно заметил Алексей Лукацкий в сегодняшнем посте, я начал формулировать своё видение оценки состояния VM-процесса в ответ на его материалы про измерение результативности VM-решения (поломают нас или нет) с использованием временных оценок Time to Notify/eXploit/Patch/Eliminate и т.д.

Тема интересная, но я и из первого поста, и из отдельного поста про TTE не понял конкретный механизм как это считать. 🤔 Для каждой CVE и актива организации? Так-то фиг угадаешь, когда конкретная уязвимость эксплуатироваться начнёт. А если это "общая температура по больнице", то какой в ней смысл? Пока это выглядит утопично и требующим детализации.

В БОСПУУ же я собираю конкретные измеримые вещи, которые точно приведут к улучшению VM-а. И повысят шансы успешного противодействия злоумышленникам.

Насколько? Это как раз и можно попробовать прикинуть с помощью результативного подхода. Но, имхо, это опциональное дополнение, не база.