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

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

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

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

Повышение критичности уязвимости Elevation of Privilege - Windows Error Reporting Service (CVE-2024-26169). В случае успешной эксплуатации злоумышленник может получить привилегии SYSTEM. Уязвимость была исправлена в мартовском Microsoft Patch Tuesday. Как это частенько бывает, тогда эту уязвимость никто не выделял. 🤷‍♂️

Однако, через 3 месяца, 12 июня, исследователи Symantec сообщили об атаках, связанных с известным шифровальщиком Black Basta, в которых использовались эксплоиты для данной уязвимости. Если верить меткам времени компиляции, эти эксплоиты были созданы задолго до выхода патчей от Microsoft, в феврале 2024 или даже в декабре 2023 года. Конечно, эти временные метки злоумышленники могли и подделать, но зачем? 🤔

13 июня уязвимость была добавлена в CISA KEV. В паблике эксплоита пока не видно.

Мораль та же: оценка и приоритизация уязвимостей хорошо, а регулярная безусловная установка обновлений - лучше.

Вышла новость, что VulnsIO интегрировали с SGRC SECURITM

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

Вышла новость, что VulnsIO интегрировали с SGRC SECURITM

Вышла новость, что VulnsIO интегрировали с SGRC SECURITM. Для настройки интеграции нужно ввести в SECURITM адрес API сервиса VulnsIO и токен для аутентификации, при необходимости указать периодичность синхронизации и включить/выключить создание новых активов на основе данных VulnsIO.

Помимо собственно уязвимостей, также прокидывают сырые данные по активам. Это позволяет делать дополнительный анализ в SECURITM:

🔸 контролировать установленное ПО по черным и белым спискам
🔸 контролировать запущенные сервисы
🔸 контролировать учётные записи
🔸 формировать метрики безопасности и использовать их в управлении рисками и соответствии требованиям

Классный пример того, что можно делать поверх сырых данных, собираемых VM-решением. Если вы пользуетесь VulnsIO и хотите сделать что-то такое самостоятельно, то у меня был отдельный пост про работу с их API.

Upd. В первой версии поста было про то, что SECURITM исключительно облачный. Это не так, у них есть on-prem вариант!

Домашний и Человеческий Vulnerability Management

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

Домашний и Человеческий Vulnerability Management

Домашний и Человеческий Vulnerability Management. Размышлял на неделе как говорить о Vulnerability Management-е на широкую аудиторию. Так, чтобы это касалось не только организаций, но и каждого конкретного человека. В итоге вырисовывается 2 направления.

Домашний (Home) VM - традиционный инфраструктурный VM спроецированный на устройства, которыми владеет и пользуется сам человек или его семья. Начиная просто от персональных устройств (смартфонов, ноутбуков, планшетов) и базовой сетевой инфраструктуры (wifi-роутер), заканчивая сколь угодно сложными системами умных домов (тут сделаю отсылку к "Будет ласковый дождь" Брэдбери), умными автомобилями и прочим. Естественно, для всего этого безобразия появляются уязвимости, которые необходимо как-то контролировать и исправлять, иначе могут быть проблемы. Насколько я могу судить, сейчас с этим полный швах. VM-решений уровня "для дома для семьи" практически нет. Понимания, что такие решения должны быть и их необходимо применять тоже нет.

Человеческий (Human) VM - проецирование подходов инфраструктурного VM-а персонально на человека. По сути это расширение того, что сейчас называется антифишингом, awareness-ом и автоматизированным анализом поведения пользователей в рамках DLP решений. То, что может быть натянуто и на общий VM-процесс. Актив - человек с персональными особенностями, сканирование - наблюдение за поведением, тестирование и практические учения, патчинг - обучение и т.д. Такую тему сейчас двигает, например, Holm Security. Human VM будет актуален и для организации (фишинг в ТОП-2 по первичному проникновению), и для каждого человека (звонки мошенников и разнообразнейшие схемы "разводов" это из той же темы). Если в компаниях этим как-то занимаются, то на персональном уровне всё тоже довольно грустно - только разрозненные предупреждения и социальная реклама.

Идея на миллион хамстер-коинов

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

Идея на миллион хамстер-коинов

Идея на миллион хамстер-коинов. 🐹😅 Делаем сайт/апп, на котором можно тапать CVE-шки. Но тапать будет иметь смысл не все CVE, а только те, у которых в течение следующей недели должен появиться подтверждённый эксплоит или признак эксплуатации вживую.

🪙 Когда такой признак или эксплоит действительно появляется, отсыпать коинов тем, кто за последнюю неделю тапал на эту уязвимость. Соразмерно количеству тапов, критичности уязвимости и т.п.

📈 А на основе анализа этих тапов делать прогнозы по эксплуатабельности уязвимостей. С помощью AI естественно.

Уверен, что работать такое будет всяко лучше EPSS и гадалкам по соцсетям. 😅

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 Обновил отчёт.