Архив рубрики: Темы

В сентябрьском Microsoft Patch Tuesday были 3 RCE уязвимости в Exchange (CVE-2023-36744, CVE-2023-36745, CVE-2023-36756), которые по факту были втихую исправлены ещё в августовском Patch Tuesday

В сентябрьском Microsoft Patch Tuesday были 3 RCE уязвимости в Exchange (CVE-2023-36744, CVE-2023-36745, CVE-2023-36756), которые по факту были втихую исправлены ещё в августовском Patch Tuesday

В сентябрьском Microsoft Patch Tuesday были 3 RCE уязвимости в Exchange (CVE-2023-36744, CVE-2023-36745, CVE-2023-36756), которые по факту были втихую исправлены ещё в августовском Patch Tuesday. Что это значит?

🔸 Уязвимости были, но о них не сообщили. Значит пользователи, которые в августе делали выводы о необходимости обновления на основе анализа списка CVE могли принять решение не обновляться и были месяц уязвимыми. 🤷‍♂️
🔸 Пользователи, которые просто регулярно обновляются, поставили августовские обновления и НЕ были уязвимыми этот месяц. 👍
🔸 Список исправленных уязвимостей - это не истина в последней инстанции. Это просто некоторая справочная информация, которую вам сообщил вендор. О каких-то CVE они могли умолчать, какие-то по ошибке добавить. Могли и недекларированные возможности с обновлениями внести. 😏 Никто за руку не поймает.

Итого: не заморачивайтесь слишком CVE-шками, лучше просто регулярно обновляете продукты доверенных вендоров.

Темы по управлению уязвимостями для Бауманского курса записывали сегодня вместе с Павлом Поповым

Темы по управлению уязвимостями для Бауманского курса записывали сегодня вместе с Павлом ПоповымТемы по управлению уязвимостями для Бауманского курса записывали сегодня вместе с Павлом Поповым

Темы по управлению уязвимостями для Бауманского курса записывали сегодня вместе с Павлом Поповым. Вроде получилось неплохо, близко к тому, что задумывалось изначально.

Анализ Защищённости. Я рассказал про типы уязвимостей (с примерами реализации), базы уязвимостей, способы детектирования.

Управление Уязвимостями. Эту часть поделили с Павлом.
🔻 Я рассказал про важность управления активами, руководство по управлению уязвимостями ФСТЭК, методику по оценке критичности уязвимостей ФСТЭК и рекомендательный алгоритм НКЦКИ.
🔻 Павел рассказал про подход к управлению уязвимостями в парадигме результативной кибербезопаности (РКБ): про инвентаризацию и категоризацию IT-активов; выявление, анализ, приоритизацию и категоризацию уязвимостей; устранение уязвимостей; контроль и улучшении VM-процесса.

Управление Обновлениями. Я рассказал про безусловные обновления, методику тестирования обновлений ФСТЭК, психологические аспекты общения с IT (фрустрацию, челобитные, докажи-покажи).

Субботнее утро, Бауманка, УЛК

Субботнее утро, Бауманка, УЛК

Субботнее утро, Бауманка, УЛК. Хорошо хоть не к первой паре. 😅

Приехал записывать модули по Vulnerability Management-у для онлайн-курса.

9 октября Позитивы запускают новый продукт MaxPatrol EDR

9 октября Позитивы запускают новый продукт MaxPatrol EDR

9 октября Позитивы запускают новый продукт MaxPatrol EDR. Что это значит в контексте Vulnerability Management-а? То, что у PT теперь будет решение, предполагающее установку агентов на хостах. В первую очередь эти агенты будут собирать данные для отслеживания и блокировки зловредной активности. Но также напрашивается и идея использовать эти агенты для инвентаризации, чтобы детектить уязвимости и мисконфигурации. Так что будем следить за этой темой. Вполне вероятно, что до полноценного агентного сканирования в MaxPatrol VM может быть не так далеко.

Судя по фразе в лендинге "Автоматизирует обнаружение и реагирование, обеспечивает своевременную и непрерывную защиту устройств на различных операционных системах", агенты должны выпустить и под Windows, и под Linux.

Почему я довольно скептически отношусь к приоритизации/фильтрации уязвимостей, хотя сам делаю опенсурсный проект для этого? Такие решения в лучшем случае отображают положение дел в моменте

Почему я довольно скептически отношусь к приоритизации/фильтрации уязвимостей, хотя сам делаю опенсурсный проект для этого? Такие решения в лучшем случае отображают положение дел в моменте
Почему я довольно скептически отношусь к приоритизации/фильтрации уязвимостей, хотя сам делаю опенсурсный проект для этого? Такие решения в лучшем случае отображают положение дел в моментеПочему я довольно скептически отношусь к приоритизации/фильтрации уязвимостей, хотя сам делаю опенсурсный проект для этого? Такие решения в лучшем случае отображают положение дел в моменте

Почему я довольно скептически отношусь к приоритизации/фильтрации уязвимостей, хотя сам делаю опенсурсный проект для этого? Такие решения в лучшем случае отображают положение дел в моменте. Но делать выводы как ситуация будет развиваться в будущем на основании текущего состоянии практически невозможно. Данных для анализа, как правило, недостаточно и они замусоренные. Поэтому решения для фильтрации/приоритизации уязвимостей не могут рекомендовать ВООБЩЕ не исправлять какую-то уязвимость. Всегда есть вероятность, что выстрелит уязвимость, о которой никто и не думал.

Если вам сейлз говорит, что с помощью их волшебного решения можно будет исправить только 3% найденных уязвимостей, а на остальное забить - гоните его в шею.

Сегодняшний пример. Remote Code Execution - Windows Themes (CVE-2023-38146). Одна из 25 RCE-шек в сентябрьском Micorosoft Patch Tuesday.

Со страницы уязвимости на сайте Microsoft:

Publicly disclosed: No
Exploited: No
Exploitability assessment: Exploitation Less Likely

Никто про неё в обзорах не писал кроме ZDI, и то с комментом "This probably isn’t one of the most severe bugs…". Vulristics оценил уязвимость как High, т.к. всё-таки RCE.

И что, вот на днях выходит подробное описание и публичный PoC, уязвимость в Vulristics становится Critical и самой важной в этом MSPT, а СМИ начинают разгонять про ThemeBleed. 🤷‍♂️

Не надейтесь на приоритизацию/фильтрацию уязвимостей, обновляйте всё заранее! У этих решений по сути два состояния: покерфейс 😐 и с выпученными глазами одурело бить в рынду 😱 (зачастую когда уже поздно).

🗒 Vulristics report - обновил отчёт для сентябрьского Microsoft Patch Tuesday

Способ затормозить Vulnerability Management процесс "докажи, что эксплуатабельно!"

Способ затормозить Vulnerability Management процесс докажи, что эксплуатабельно!

Способ затормозить Vulnerability Management процесс "докажи, что эксплуатабельно!" Этот способ ещё более универсальный, чем предыдущий. Заключается в том, что IT постоянно требуют от VM-щика что-то доказывать перед тем как приступить к непосредственному исправлению уязвимостей. Причём после каждого успешного доказательства IT могут отойти на новый "рубеж обороны".

1. Мы уже исправили уязвимость, сканер наверное фолсит. VM-щику предлагается доказать, что уязвимость действительно присутствует и сканер не фолсит.

2. Да, эта уязвимость есть, но она неэксплуатабельная. VM-щику предлагается найти эксплоит и провести демонстрацию.

3. Да, эта уязвимость в принципе эксплуатабельная, но в условиях нашей инфраструктуры она неэксплуатабельная. VM-щику предлагается доказать эксплуатабельность уязвимости, при этом не навредив инфраструктуре.

4. Уязвимость на хосте, который не является критичным, и даже если он будет скомпрометирован, то ничего страшного не произойдет. VM-щику предлагается продемонстрировать критичные последствия компрометации уязвимого хоста.

А что в итоге? Допустим, потратив кучу времени и сил VM-щик добивает своего. Статус уязвимости подтверждается. IT-шники торжественно фиксят эту уязвимость. 🥳

ОДНУ. А что с остальными сотнями и тысячами? А также. Мыло-мочало, начинай сначала!

Вместо того, чтобы поднимать реальный уровень защищённости VM-щик занимается бесконечными недопенстестами. А IT-шникам в это время хорошо, пока VM-щики заняты доказыванием чего-то, их не допекают необходимостью постоянно патчиться. 😏

Как с этим бороться? Имхо, наиболее действенный способ поставить вопрос так:

🔸 Мы специалисты по уязвимостям, а вы специалисты по эксплуатации.
🔸 Мы вам говорим, что уязвимость критична и требует исправления, основываясь на информации от вендора и своей экспертизе, которой вы, объективно, не обладаете.
🔸 В случае инцидента с эксплуатацией этой уязвимости спрос за неисправленную вовремя уязвимость будет с нас, с VM-щиков, а то, что у вас было какое-то другое мнение по поводу этой уязвимости вообще никого волновать не будет, т.к. это не ваша область ответственности и не ваша специальность.
🔸 Мы вам задачу на исправление поставили и доказывать дополнительно ничего не намерены. Не будете выполнять задачу - ваши проблемы, но в случае масштабного инцидента именно вы можете попасть под 274 УК РФ ("Нарушение правил эксплуатации средств хранения, обработки или передачи компьютерной информации и информационно-телекоммуникационных сетей"), т.к. по правилам необходимо устанавливать обновления безопасности. 🤷‍♂️

Жёстко? Пожалуй. Я вообще за то, чтобы как-то по-хорошему договариваться. Но если пошла игра в "докажи-покажи", то тут уже по-хорошему становится сложно и нужно это сразу пресекать.

Довольно редкое явление, когда RCE уязвимость присутствует и в веб-браузерах на основе Chrome/Chromium (включая Edge), и в веб-браузерах на основе Firefox

Довольно редкое явление, когда RCE уязвимость присутствует и в веб-браузерах на основе Chrome/Chromium (включая Edge), и в веб-браузерах на основе Firefox

Довольно редкое явление, когда RCE уязвимость присутствует и в веб-браузерах на основе Chrome/Chromium (включая Edge), и в веб-браузерах на основе Firefox. Уязвимость CVE-2023-4863 нашли в libwebp, библиотеке для работы с растровыми изображениями в формате WebP (замена PNG и JPEG). Поэтому любой софт, который умеет открывать изображения в WebP, вполне вероятно использует libwebp и поэтому будет уязвим. Google пишут, что эксплоит есть в паблике.

И это не только про веб-браузеры. Пишут, что libwebp также используется в Electron framework, Signal, Honeyview, Affinity, Gimp, Inkscape, LibreOffice, Telegram, Thunderbird (есть патч), ffmpeg и других.

А как насчёт Safari? Про него пока молчат, но некоторые СМИ делают предположения, что недавние эксплуатируемые RCE в продуктах Apple, CVE-2023-41061 и CVE-2023-41064, "обработка вредоносного изображения может привести к выполнению произвольного кода" #BLASTPASS это про то же.

И что, как с log4j будет? Вряд ли, но видимо зацепит много кого.