Архивы автора: Alexander Leonov

Об авторе Alexander Leonov

Привет! Меня зовут Александр. Я специалист по Управлению Уязвимостями. Подробнее обо мне можно прочитать здесь. Приглашаю подписаться на мой канал в Telegram @avleonovrus. Я обновляю его чаще, чем этот сайт. Вы можете обсудить мои посты или задать вопросы в @avleonovchat или в группе ВКонтакте. And I invite all English-speaking people to another telegram channel @avleonovcom.

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

3 комментария

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-а. И повысят шансы успешного противодействия злоумышленникам.

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

Обновил июньский Linux Patch Wednesday и перевыпустил отчёт Vulristics

1 комментарий

Обновил июньский Linux Patch Wednesday и перевыпустил отчёт Vulristics

Обновил июньский Linux Patch Wednesday и перевыпустил отчёт Vulristics. Общее количество уязвимостей снизилось с 1053 до 1040. Видимо для них стали доступны более ранние таймстемпы фиксов. Но уязвимости с признаком эксплуатации вживую и с публичным эксплоитом это не зацепило, они остались теми же.

🗒 Отчёт Vulristics по июньскому Linux Patch Wednesday

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

3 комментария

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

Базовая Оценка Состояния Процесса Управления Уязвимостями (БОСПУУ): предварительная схема по текстовому описанию. Конечно, требуется дальнейшая детализация и расширение. Мне в первую очередь интересна оценка используемых средств детектирования. 😎

Upd. Обновленная версия 0.0.6

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

2 комментария

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

Базовая Оценка Состояния Процесса Управления Уязвимостями (БОСПУУ). Как правильно отслеживать и развивать Vulnerability Management процесс? Имхо, нет единственно правильного способа. Если уязвимости в инфраструктуре своевременно исправляются, аудиторы вас нахваливают, а пентестеры грустят, значит всё норм. 👍 Но некоторые свои соображения я сформулирую под названием БОСПУУ. 😉

Общая оценка состоит из 3 компонентов:

🔸 Оценка используемых средств детектирования уязвимостей (полнота базы детектов, достаточность способов детектирования, оперативность доставки детектов)

🔸 Оценка охвата инфраструктуры VM-процессом (несканируемые активы и сети, активы без ответственных, активы без SLA по устранению уязвимостей, уязвимости без тасков)

🔸 Оценка выполнения SLA по патчингу для скоупов активов. Каждый скоуп разбиваем на группы активов по критичности: целевые, ключевые, обычные. Для каждой группы отслеживаем выполнение SLA по плановому и приоритетному исправлению уязвимостей.

upd. Схема

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

1 комментарий

По поводу критичной уязвимости 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 были популярны в России и наверняка остаётся ещё много инсталляций. 🤔

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