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

Детали по Remote Code Execution - Palo Alto PAN-OS (CVE-2024-3400)

Детали по Remote Code Execution - Palo Alto PAN-OS (CVE-2024-3400)

Детали по Remote Code Execution - Palo Alto PAN-OS (CVE-2024-3400). Пост с деталями вышел в блоге Palo Alto 19 апреля.

🔹В Palo Alto узнали об этой уязвимости в среду 10 апреля. Информация о подозрительной активности в инфраструктуре клиента пришла от компании Volexity, это вендор решений по компьютерной форензике и безопасности оперативной памяти. Совместно эксперты из компании Palo Alto и Volexity обнаружили источник подозрительного трафика - скомпрометированный файервол. В пятницу 12 апреля, когда в Москве был уже вечер, Palo Alto выпустили блогпост и публичный бюллетень безопасности с описанием уязвимости и workaround-а. А в понедельник 15 апреля были выпущены новые версии PAN-OS для исправления уязвимости.

🔹 Для уязвимости сразу была определена максимальная критичность по CVSS (10). CISA сразу добавила уязвимость в Known Exploited Vulnerabilities Catalog.

🔹 Что представляет собой уязвимость? Комбинируя две ошибки в PAN-OS, злоумышленники могут выполнить двухэтапную атаку и добиться выполнения команд на уязвимом устройстве. На первом этапе злоумышленник отправляет в GlobalProtect (компонент PAN-OS для защиты мобильных сотрудников) специально подготовленную shell-команду вместо идентификатора сессии. В результате на устройстве создаётся пустой файл, в имени которого содержится необходимая злоумышленнику команда. 🤷‍♂️ На втором этапе на устройстве запускается валидная задача cron, которая использует имя этого пустого файла, тем самым непосредственно выполняя команду злоумышленника с повышенными привилегиями. 😏

🔹 Первые попытки эксплуатации уязвимости были зафиксированы 26 марта. Для этих атак исследователи выбрали название "операция MidnightEclipse" ("ПолуночноеЗатмение"). В ходе атак злоумышленники устанавливали на уязвимые устройства кастомный бэкдор на Python, который исследователи из Volexity назвали UPSTYLE, а также другие утилиты для упрощения эксплуатации. Например, утилиту для тунелирования GOST (GO Simple Tunnel).

🔹 На следующий день после выпуска патчей, 16 апреля, вышло подробное техническое исследование уязвимости от компании Rapid7 с указанием PoC-а. Уже 17 апреля эксплоит стал доступен виде модуля для Metasploit. Так что сейчас эксплуатация этой уязвимости максимально упрощена.

🔹 Количество потенциально уязвимых хостов доступных из Интернет, по состоянию на 19 апреля, Shadowserver оценивали на уровне 22500. Большая часть из них в США (9626), в России совсем немного (44). Но тут вопрос, конечно, насколько сейчас достоверны детекты Shadowserver для России.

Выводы?

🔻 Next Generation решето, которое давно пора импортозамещать. Всякое бывает, но это какие-то особенно позорные уязвимости для ИБ-вендора.

🔻 Дата выхода патча для громкой уязвимости = дата выхода публичного эксплоита. Это практически гарантировано. Слишком соблазнительно ресерчерам попиариться на этом первыми. 🤷‍♂️ Поэтому нужно подпрыгивать и патчить сразу, не дожидаясь появления публичных эксплоитов и атак скрипткидисов.

Vulnerability Management и горячая картошка

Vulnerability Management и горячая картошка

Vulnerability Management и горячая картошка. 🥔 Подумалось, что важнейшая задача Vulnerability Management решения заключается в том, чтобы защищать самого VM-специалиста (и его руководителей вплоть до CISO). Решение должно предоставлять надёжные доказательства, что специалист добросовестно выполнял свою часть работы:

🔸 Своевременно и достаточно полно анализировал инфраструктуру.
🔸 Оперативно информировал ответственных о найденных уязвимостях и связанных рисках, ставил им задачи на исправление.
🔸 Контролировал выполнение задач ответственными и указывал, если задачи не были выполнены в срок.
🔸 Особое внимание уделял критичным уязвимостям из рассылок регуляторов.

Цель в том, чтобы в момент внешнего аудита или расследования инцидента, в руках VM-щика не было "горячей картошки" (необработанных критичных уязвимостей). 😏 Это значит, необходимо постоянно оценивать количество "картошки" в руках и автоматически минимизировать его или предлагать шаги для этого. Задача для AI? 🤔 Возможно.

В понедельник на сайте Positive Technologies вышла большая статья про SteganoAmor - операцию по обнаружению атак группировки TA558

В понедельник на сайте Positive Technologies вышла большая статья про SteganoAmor - операцию по обнаружению атак группировки TA558

В понедельник на сайте Positive Technologies вышла большая статья про SteganoAmor - операцию по обнаружению атак группировки TA558. Несмотря на многообразие инструментов и методов атак, которые использовала группировка, в статье упоминается только одна CVE уязвимость. Это старая RCE в Microsoft Office (CVE-2017-11882), которая используется для запуска макросов в RTF-документах. Несмотря на возраст, уязвимость регулярно всплывает в описаниях актуальных атак.

Отсюда вывод для VM-процесса. Не так важно, что какая-то команда обновляется раз в 2 месяца, а не каждый месяц. Важно выделить хосты и софты, которые принципиально не обновляются и не будут обновляться и бороться прежде всего с ними.

Одновременно курьёзный и печальный факт. Уязвимость была обнаружена исследователем из Embedi. К сожалению, компания не пережила американские санкции и на их сайте, где было выложено оригинальное исследование, теперь онлайн-казино. 🎰🤷‍♂️

Повысилась критичность уязвимости RCE - Windows MSHTML Platform (CVE-2023-35628)

Повысилась критичность уязвимости RCE - Windows MSHTML Platform (CVE-2023-35628)
Повысилась критичность уязвимости RCE - Windows MSHTML Platform (CVE-2023-35628)

Повысилась критичность уязвимости RCE - Windows MSHTML Platform (CVE-2023-35628). Уязвимость была исправлена в декабрьском Microsoft Patch Tuesday 2023.

"По данным Microsoft, злоумышленник может отправить специальное email-сообщение, которое будет автоматически обработано при получении Microsoft Outlook (до просмотра в Preview Pane). 🔥"

И вот через 4 месяца Akamai выложили подробный write-up и PoC эксплоита. Эксплоит это файл test.url, который крашит Windows File Explorer. 🤔

А где zero-click RCE в Outlook? Такая эксплуатация возможна вместе с EoP - Microsoft Outlook (CVE-2023-23397):

"This vulnerability can be triggered through Outlook (0-click using CVE-2023-23397)".

Впрочем, CVE-2023-23397 и без того была супер-критичной на момент выхода в марте 2023 с признаками активной эксплуатации вживую. Есть надежда, что её уже пофиксили везде. 🙏

По данным из БДУ ФСТЭК уязвимость CVE-2023-35628 эксплуатируется вживую (флаг vul_incident).

13 мая стартует онлайн-хакатон от команды MaxPatrol VM Positive Technologies: получи реальный опыт в разработке правил детектирования уязвимостей на нейтральном опенсурсном стеке и выиграй денежные призы

13 мая стартует онлайн-хакатон от команды MaxPatrol VM Positive Technologies: получи реальный опыт в разработке правил детектирования уязвимостей на нейтральном опенсурсном стеке и выиграй денежные призы

13 мая стартует онлайн-хакатон от команды MaxPatrol VM Positive Technologies: получи реальный опыт в разработке правил детектирования уязвимостей на нейтральном опенсурсном стеке и выиграй денежные призы. Активность просто огненная. 🔥

Задания хакатона:

🔻 Стендирование. Написать плейбук для развертывания ПО с помощью Ansible.
🔻 Обнаружение ПО. Написать скрипт для обнаружения ПО на хосте на языке Python. Цель скрипта сгенерировать OVAL Variables с информацией по софту.
🔻 Обнаружение уязвимостей. Распарсить источник данных об уязвимостях и сформировать OVAL Definitions. Затем провести детектирование уязвимостей используя OVAL Definitions и артефакт работы скрипта обнаружения ПО (OVAL Variables) с помощью утилиты OpenSCAP.

Таким образом участники хакатона пройдут весь путь поддержки продукта в сканере уязвимостей с использованием нейтрального опенсурсного стека:

Ansible + Python + OVAL/OpenSCAP

При этом использование Python для сборки OVAL Variables позволит снять ограничения связанные с OVAL объектами (мороки с их сбором - атас, а OpenSCAP под Windows вообще dicscontinued) и при этом получить все преимущества OVAL - формализованное описание правил детектирования уязвимостей и готовые инстурумент для расчёта статусов в виде OpenSCAP.
Б - Баланс. 👍

💳 За выполнение заданий участники будут получать баллы, которые будут конвертированы в деньги.

🚀 Результаты работы участников не пропадут, а будут использованы в MaxPatrol VM (после ревью и через конвертацию в пакеты MaxPatrol VM).

Для участников сплошной Win:

🔸 Получаем реальную практику с востребованными технологиями (Ansible и Python вообще must have в IT, а OVAL/SCAP кучей VM-продуктов используется и в России, и зарубежом).
🔸 Получаем отличную строчку в резюме (рассказывать на собесе как детекты писал, которые в MaxPatrol VM сейчас используется - круто же 🙂).
🔸 Получаем приятный денежный бонус с этого.
🔸 Получаем фаст-трек для вкатывания в команду разработки MaxPatrol VM, если процесс понравится и будут хорошие результаты. 😉

➡️ Подробности и регистрация тут
🟥 Официальный пост в канале Positive Technologies

По Linux Patch Wednesday можно задать справедливый вопрос: а правильно ли я отношу уязвимости к месяцам?

По Linux Patch Wednesday можно задать справедливый вопрос: а правильно ли я отношу уязвимости к месяцам?

По Linux Patch Wednesday можно задать справедливый вопрос: а правильно ли я отношу уязвимости к месяцам?

Напомню текущую логику: я беру таймстемпы бюллетеней из OVAL-контента Linux вендоров. Какой таймстемп самый старый, тот и считаю временем первого исправления уязвимости.

Но вот незадача: первыми обычно выпускают исправления Debian и они же, частенько, не указывают дату бюллетеня в OVAL (и в листах рассылки тоже не всегда). 😣 Вот и получается как на картинке. Debian выпустил патч непонятно когда, а RedOS в апреле 2024. Делаем вывод, что уязвимость апрельская, ага. Хотя "2023" в CVE намекает на то, что это, мягко говоря, не совсем так и первое исправление уязвимости вышло значительно раньше.

Что с этим делать? Можно сделать радикальный шаг: если для CVE в источнике дата Unknown, то тупо выставлять текущую дату. "Если вижу исправление и не знаю когда конкретно уязвимость была исправлена, значит она была исправлена сегодня". 🙂 И проводить такую "раздачу дат" для Unkown более-менее регулярно (не реже раза в месяц).

К чему приведет введение такого правила со следующего Linux Patch Wednesday? К тому, что огромная масса уязвимостей, которые непонятно когда были исправлены, станут "исправлены" в мае 2024 года. Мы на них посмотрим, ужаснёмся разок, но зато в следующих месяцах всплывающих внезапно старых уязвимостей будет минимальное количество. Там будет в основном свежачок. Но зато я попорчу статистику внезапным пиком в мае 2024. Дилемма. 🤷‍♂️

Как считаете, проводим операцию "Введение правила по Unknown датам с Мая 2024?".

Кит 🐳, если да (ввести правило, получить пик в статистике ради будущих красивых отчётов без старья).

Палец вниз 👎, если нет (оставить как есть в надежде, что в будущем появится хороший источник данных по таймстемпам исправления и статистика автоматом пересчитается правильным образом).

Сам я считаю, что ввести такое правило стоит.

Сгенерил отчёт Vulristics по апрельскому Linux Patch Wednesday

Сгенерил отчёт Vulristics по апрельскому Linux Patch Wednesday
Сгенерил отчёт Vulristics по апрельскому Linux Patch WednesdayСгенерил отчёт Vulristics по апрельскому Linux Patch WednesdayСгенерил отчёт Vulristics по апрельскому Linux Patch WednesdayСгенерил отчёт Vulristics по апрельскому Linux Patch WednesdayСгенерил отчёт Vulristics по апрельскому Linux Patch WednesdayСгенерил отчёт Vulristics по апрельскому Linux Patch Wednesday

Сгенерил отчёт Vulristics по апрельскому Linux Patch Wednesday. За прошедший месяц Linux-вендоры начали выпускать исправления для рекордного количества уязвимостей - 348. Есть признаки эксплуатации вживую для 7 уязвимостей (данные об инцидентах из БДУ ФСТЭК). Ещё для 165 есть ссылка на эксплоит или признак наличия публичного/приватного эксплоита.

Начнём с 7 уязвимостей с признаком активной эксплуатации вживую и эксплоитами:

🔻 В ТОП-е, внезапно, январская трендовая уязвимость Authentication Bypass - Jenkins (CVE-2024-23897). Насколько я понимаю, обычно Linux-дистрибутивы не включают пакеты Jenkins в официальные репозитарии и, соответственно, не добавляют детекты уязвимостей Jenkins в свой OVAL-контент. В отличие от отечественного RedOS. Поэтому самый ранний таймстемп исправления этой уязвимости именно у RedOS.

🔻 2 RCE уязвимости. Самая интересная это Remote Code Execution - Exim (CVE-2023-42118). Когда я выпускал отчёт, я специально не учитывал описание уязвимости и продукты из БДУ (флаги --bdu-use-product-names-flag, --bdu-use-vulnerability-descriptions-flag). Иначе это привело бы к тому, что часть отчёта была бы на английском, а часть на русском. Но оказалось, что для этой уязвимости адекватное описание есть пока только в БДУ. 🤷‍♂️ К этой уязвимости нужно присмотреться, т.к. Exim является достаточно популярным почтовым сервером. Вторая RCE уязвимость браузерная, Remote Code Execution - Safari (CVE-2023-42950).

🔻 2 DoS уязвимости. Denial of Service - nghttp2/Apache HTTP Server (CVE-2024-27316) и Denial of Service - Apache Traffic Server (CVE-2024-31309). Последняя в отчёте классифицируется как Security Feature Bypass, но это из-за некорректного CWE в NVD (CWE-20 - Improper Input Validation)

🔻 2 браузерные Security Feature Bypass - Chromium (CVE-2024-2628, CVE-2024-2630)

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

🔸 Большое количество RCE уязвимостей (71). Большая часть из них в продукте gtkwave. Это программа просмотра файлов VCD (Value Change Dump, дамп изменения значения), которые обычно создаются симуляторами цифровых схем. Выглядят опасными уязвимости Remote Code Execution - Cacti (CVE-2023-49084, CVE-2023-49085), это решения для мониторинга серверов и сетевых устройств.

🔸 Security Feature Bypass - Sendmail (CVE-2023-51765). Позволяет внедрить сообщения электронной почты с поддельным адресом MAIL FROM.

🔸 Пачка Cross Site Scripting в MediaWiki, Cacti, Grafana, Nextcloud.

В общем, в этот раз аж глаза разбегаются. 🤩

🗒 Апрельский Linux Patch Wednesday