Архив рубрики: Уязвимость

Аксиома обновления до последней версии ПО

Аксиома обновления до последней версии ПО. В комментариях к посту про Vulnerability Management как порождение хаоса в IT (пользуясь случаем, всех приглашаю комментировать мои посты в VK и добавляться в друзья 😉) Михаил Богаченко подсветил интересную тему. Мы действительно зачастую берём некоторые аспекты Vulnerability Management-а как аксиомы, которые не требуют доказательств.

В случае, если нужно закрыть уязвимость мы зачастую можем рекомендовать "обновиться до последней версии ПО". Хотя эта последняя версия ПО может, например, содержать бэкдор. Как было в случае с XZ Utils, 3CX Desktop App и Free Download Manager. Так что рекомендация может привести к инциденту. 🤷‍♂️ И кто будет в этом случае отвечать? 😏

Причём ладно ещё, если это рекомендации для устранения какой-то конкретной критичной уязвимости. Но мы ведь можем (и, имхо, должны) рекомендовать устанавливать обновления безопасности регулярно и безусловно. Чтобы большая часть уязвимостей исправлялась в этом регулярном процессе, без участия Vulnerability Management специалистов.

И что же делать? Я думаю следующее:

🔸 Риски привнести НДВ с обновлениями всегда есть и будут. Поэтому и существует методика тестирования безопасности обновлений. 😉 Которая должна применяться, как минимум, для зарубежного и опенсурсного ПО. Насколько она реально применяется - пусть будет на совести каждого. 🙂

🔸 Выбор новой версии ПО для исправления конкретной критичной уязвимости лучше оставить на усмотрение IT. Хотят ставить минорную версию, которая исправляет только одну уязвимость, но с меньшей вероятностью влияет на основную функциональность ПО - их право. 🤷‍♂️ Уязвимость исправлена и ладушки.

🔸 Безусловные регулярные обновления ПО до последней версии всё равно считаю правильной и прогрессивной мерой. Риски, что вендора подломят и проведут Supply Chain Attack или вендор сойдёт с ума и сам внесёт зловредную функциональность, всё-таки гораздо ниже, чем риски эксплуатации известных уязвимостей. Чтобы риски были ещё ниже стоит внимательнее подходить к подбору вендоров и мониторить новости об инцидентах с ними, чтобы в случае, если (когда) они будут скомпрометированы, отработать оперативно.

ITшникам не до уязвимостей

Добавить комментарий

ITшникам не до уязвимостей. Мне написал подписчик, которого триггернули мои слова в посте про Vulnerability Management как порождение хаоса в IT.

"Почему есть потребность в VM-е? Потому что IT без живительной стимуляции со стороны не могут поддерживать удовлетворительный уровень безопасности инфраструктуры организации. "

Привожу его сообщение:

"У меня есть некоторый опыт работы в ИТ, включая ИБ-шные компании. ИТ нужна не живительная стимуляция со стороны, а ресурсы и нормально простроенные процессы. Я не видел ещё ни одной конторы, в которой бы подразделения ИТ не были бы тотально перегружены (из-за нехватки людей, большого количества задач или неудовлетворительной организации процессов их работы — в частности, недостаточного внимания к автоматизации IT ops.

Потому что в условиях, когда критериями является "чтобы не падало", и чтобы никто не жаловался [на сроки исполнения]", и очередь задач в десятки на одного сотрудника — совсем не до VM.

Вспоминаются слова одного руководителя ИБ-шной компании: "Смотрю я на наше ИТ, и постоянно возникает желание разгонать всех нахер, и нанять других, порасторопнее". В то время как ИТ страдала совсем не от недостатка расторопности — люди херачили днями и ночами."

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

Linux Patch Wednesday: вот где этот майский пик!

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

Linux Patch Wednesday: вот где этот майский пик! 🤦‍♂️ Также об июньском Linux Patch Wednesday. Помните, я в посте про майский Linux Patch Wednesday радовался, что, несмотря на введение правила по Unknown датам, пик в мае был незначительный. Хотя "32 406 oval definition-ов без даты получили номинальную дату 2024-05-15". Оказалось пик не был виден из-за ошибки в коде. Ба-дум-тсс! 🥸🤷‍♂️

То, что не все CVE-шки у меня попадаются в LPW бюллетени, несмотря на введение номинальных дат, я заметил на примере громкой уязвимости Elevation of Privilege (Local Privilege Escalation) - Linux Kernel (CVE-2024-1086), которой действительно нигде не было. Подебажил функцию распределения по бюллетеням, добавил тесты. Добился того, что все 38 362 CVE-шки из Linux-ового OVAL-контента действительно раскидываются по бюллетеням. Включая CVE-2024-1086. Вот она в феврале:

$ grep "CVE-2024-1086"  bulletins/*
bulletins/2024-02-21.json:        "CVE-2024-1086": [
bulletins/2024-02-21.json:                "title": "CVE-2024-1086 linux",
bulletins/2024-02-21.json:                "title": "CVE-2024-1086 linux",
bulletins/2024-02-21.json:                "title": "CVE-2024-1086 linux",

Ну и пик в мае действительно есть. Да ещё какой! 11 476 CVE! 😱 Настолько много, что я перегенерил Vulristics отчёт для него только с использованием 2 источников: Vulners и БДУ. И даже из Vulners данные подгружались не быстро. В отчёте 77 уязвимостей с признаком активной эксплуатации вживую и 1 404 уязвимости с эксплоитами, но без признаков активной эксплуатации. Т.к. по больше части это уязвимости старые, для которых просто не было понятно когда именно они были исправлены, например, Remote Code Execution - Apache HTTP Server (CVE-2021-42013), я не буду подробно их разбирать - кому интересно смотрите отчёт. Но обратите внимание, что размер отчёта очень большой.

🗒 Отчёт Vulristics по майскому Linux Patch Wednesday (31.3 мб.)

Что касается июньского Linux Patch Wedneday, который финализировался 19 июня, то там 1040 уязвимости. Тоже довольно много. Почему так? С одной стороны правило по Unknown датам добавило 977 Debian-овских OVAL дефинишенов без даты. Не 30к, как в мае, но тоже значительно. Из 1040 уязвимостей 854 это уязвимости Linux Kernel. Причём, довольно много "старых" идентификаторов уязвимостей, но заведенных в 2024 году. Например, CVE-2021-47489 с NVD Published Date 05/22/2024. 🤔 Что-то странное творит CNA Linux Kernel.

🔻 С признаками эксплуатации вживую опять Remote Code Execution - Chromium (CVE-2024-5274, CVE-2024-4947), как и Microsoft Patch Tuesday. Судя по данным БДУ, Remote Code Execution - Libarchive (CVE-2024-26256) также активно эксплуатируется.

🔸 Ещё 20 уязвимостей с публичным эксплоитом. Можно подсветить отдельно Remote Code Execution - Cacti (CVE-2024-25641) и Remote Code Execution - onnx/onnx framework (CVE-2024-5187).

🗒 Отчёт Vulristics по июньскому Linux Patch Wednesday (4.4 мб.)

upd. 30.06 Обновил отчёт.

Резко повысилась критичность уязвимости Elevation of Privilege - Windows CSC Service (CVE-2024-26229)

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

Резко повысилась критичность уязвимости Elevation of Privilege - Windows CSC Service (CVE-2024-26229). Уязвимость из апрельского Microsoft Patch Tuesday. В апреле эту уязвимость вообще никто не подсвечивал.

"На Танечку внимания никто не обращал" ©

Microsoft про неё писали "Exploitation Less Likely". Известно было только то, что в случае успешной эксплуатации злоумышленник может получить привилегии SYSTEM.

Но через 2 месяца, 10 июня, на GitHub появился рабочий эксплоит. 🤷‍♂️ Сюрприз! Критичность уязвимости скачкообразно повысилась.

Можно было это как-то прогнозировать? Имхо, вообще никак. Ещё одно подтверждение, что прогнозирование трендовости это, конечно, хорошо и правильно, но регулярный безусловный патчинг согласно установленному SLA (AIT) не отменяет.

Небольшая подробность. Автор эксплоита уточнил CWE уязвимости.

Было: CWE-122 - Heap-based Buffer Overflow

Стало: CWE-781 - Improper Address Validation in IOCTL with METHOD_NEITHER I/O Control Code

Vulnerability Management как порождение хаоса в IT

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

Vulnerability Management как порождение хаоса в IT. Тема очевидная и несколько избитая. Почему есть потребность в VM-е? Потому что IT без живительной стимуляции со стороны не могут поддерживать удовлетворительный уровень безопасности инфраструктуры организации. 🤷‍♂️

А как бы было хорошо: ITшники сами устанавливают регламент по обновлениям (включая экстренные обновления) и сами следят за его выполнением, сами разбираются в харденинге и внедряют его. А ИБ только периодически проводят аудиты и поражаются насколько же всё грамотно выстроено и работает как отлаженный смазанный механизм. И, со слезами умиления на глазах, закупают ITшникам всякие вкусняшки, поют соками-водами и долго трясут руки героям невидимого фронта. Нет, без шуток. Мой идеальный VM это полное отсутствие VM-а вообще, ввиду его ненужности, ведь безопасность в организации наступает сама, by design, без каких-либо избыточных костылей.

Но вот что-то в реальной жизни так решительно не получается. И чем больше масштаб организации, тем больше хаоса, адища, скверны и пагубы там образуется со временем. Возможно оттого, что цели разные. У кого-то учёт в рублях, а у кого-то в сутках. Когда в IT платят за то, чтобы просто надёжно работало, нужно быть отбитым фанатиком, чтобы ещё и по собственной инициативе постоянно обновлять своё хозяйство для исправления уязвимостей. Сложная задача становится сложной задачей со звёздочкой. И зачастую без какой-либо положительной мотивации, скорее наоборот - втыки за то, что опять что-то отъехало после обновления. И всё равно продолжать это делать. Потому, что "так надо", "так правильно". Мало таких буйных и не надолго их хватает.

Поэтому дорога одна - вниз, в адище и хаос. Из которого, после инцидентов или под воздействием регуляторной дубины, рождается то, что должно с ним как-то бороться - Vulnerability Management. Порождение по природе своей ограниченное, компромиссное и неполное. Ну а что вы хотели? От осинки не родятся апельсинки.

По определению неполная база известных уязвимостей становится отправной точкой для ещё более неполной базы уязвимостей с формализованными детектами. Детектами, которые не всегда могут достоверно найти уязвимость ввиду многообразия способов установки ПО. Затем набор продетектированных уязвимостей о большей части которых неизвестно вообще ничего подвергается анализу и приоритизации: "а ну малыш, давай, попробуй отгадай" какая из них станет трендовой завтра и через какую организацию поломают. 🙂 Чистый кайф.

И, к сожалению, ничего лучшего для борьбы с IT-хаосом пока не придумали. 🤷‍♂️

Полезный AI для Vulnerability Management-а, каким он будет?

Добавить комментарий

Полезный AI для Vulnerability Management-а, каким он будет? Имхо, работа с ним должна сводиться к генерации приоритезированного потока задач и их выполнения (насколько возможно автоматизированного).

🔸 Скажи мне, VMGPT, на основе данных о нашей инфраструктуре и известных угрозах, какие конкретные задачи необходимо выполнить в первую очередь для повышения безопасности организации и/или улучшения VM-процесса? Эти задачи должны быть достаточно конкретными, например, исправить уязвимость X на хосте Y или раскатать агента для детектирования уязвимостей на хост Z.

🔸 Скажи мне, VMGPT, на основе данных о нашей инфраструктуре, сотрудниках, имеющихся инструментах и формализованных процессах IT и ИБ, как решить конкретную задачу из предыдущего пункта наиболее быстро и эффективно. И, если возможно, выполни эту задачу полностью самостоятельно и напиши по ней отчёт. Например, пропуши нерадивого админа, который не запатчил свои хосты в срок. Или разберись почему агенты не раскатаны на какие-то хосты и дораскати. Или почему есть несоответствие между хостами в VM-е и CMDB.

Человек-аналитик, возможно, справился бы с каждой конкретной задачкой лучше, но человека нужно найти, нанять и зарплату ему платить - а тут очень быстро, условно бесплатно и с приемлемым уровнем качества. То есть +- такой же расклад, как и с другими AI сервисами, которые сейчас активно используются для автоматического перевода, анализа текстов, генерации картинок, музыки и прочего.

Заметки по сегодняшнему запуску MaxPatrol VM 2.5, часть 2

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

Заметки по сегодняшнему запуску MaxPatrol VM 2.5, часть 2. Продолжаю делиться заметками.

Q&A сессия

🔹 Все стандарты CIS переносить не планируется. Будут курсы по продукту, чтобы можно было реализовать их самостоятельно в HCC.
🔹 Вся инфра в облаке? Ставьте MPVM в облако.
🔹 MaxPatrol VM Light будет - следите за обновлениями. 😉
🔹 Первое на что стоит смотрить при устранении уязвимостей - трендовые уязвимости
🔹 PT BlackBox отличается целевой аудиторией. У PT BlackBox целевая аудитория AppSec, а у MPVM - инфраструктурные VM-щики.
🔹 Лицензия на сканирования тратится, когда рассчитывается уязвимость для хоста.
🔹 Новый интенсив по MaxPatrol VM стартует в сентябре.
🔹 Сканировать web-таргеты правильнее по fqdn.
🔹 Настройка цепочек задач? В бэклоге.
🔹 Анализ мобильных устройств? Пока такого запроса нет, т.к. сложно патчить устройства.
🔹 Постановка задач IT? Пока интеграция с тикетницами через API, но следите за новостями. 😉
🔹 А если Nuclei не подтвердил? Будет просто показывать, что для уязвимости есть эксплоит.
🔹 Когда будет доступна новая версия? Можно завтра с утра, но рекомендуем ставить с понедельника.
🔹 Когда будет поддержка ИнфоТеКС? Есть в роадмапе. Есть сложности с получением рута. Вообще про российские решения: об уязвимостях нужно как-то узнать - вендоры должны где-то уязвимости публиковать (ИнфоТеКС тут молодцы)
🔹 Редактор кастомных требований в самом VM будет.
🔹 Тёмная тема будет с переездом на новый Angular.
🔹 Функционал очистки? В работе. Процессинг - зарелижен, Scans - в работе, TRM - для части есть.

Александр В. Леонов

Управление Уязвимостями и прочее