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

Вышел эпизод "Почему компании не закрывают уязвимости?" [Belyaev_Podcast] с моим участием

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

Вышел эпизод "Почему компании не закрывают уязвимости?" [Belyaev_Podcast] с моим участием. Вместе с Дмитрием Беляевым и Рустамом Гусейновым обсудили Vulnerability Management и Exposure Management, CVSS/EPSS/KEV и приоритизацию уязвимостей, AI-агентов и нейросети в триаже, автоматизированный патчинг, моделирование атак, зашивание безопасности в разработку, проблемы взаимодействия с IT, работу с системами, которые нельзя патчить, будущее VM-специалистов и особенности управления уязвимостями в Linux, Kubernetes, контейнерах и облаках. Классно посидели, мне очень понравилось. Надо будет как-нибудь продолжить общение по теме. 😉

Таймстемпы:

00:00 Приветствие, медиа-партнёры
03:25 Справедливо ли мнение, что CVSS как основная метрика приоритизации - это уже "технология 2002 года"? Почему в 2026 году компании всё ещё живут в логике "сортируем по CVSS", хотя есть EPSS, KEV и трендовые метрики? Это лень, незнание или инерция?
07:49 Насколько вопросы триажа, ранжирования и приоритизации уязвимостей делаются лучше с помощью нейросетей? Будет ли в будущем происходить быстрое сопоставление по разным шкалам и интегральная оценка с учётом искажений, которые есть в тех или иных системах метрик?
10:09 Автономные AI-агенты и VM
12:00 System-hardening и патчинг уязвимостей агентами без участия человека - уже реальность?
15:33 Насколько справедливо утверждение, что Exposure Management - это не просто "VM 2.0", а действительно другой взгляд на управление риском? В твоём понимании это эволюция или всё-таки революция, но с новым ценником? (Я тут попутал "croûton" и "croissant" в известной кино-цитате - сорян 🤦‍♂️🤷‍♂️🙂)
20:32 Про зашивание безопасности в IT/разработку, почему так много Linux-уязвимостей, и нужна ли замена Linux Kernel
30:08 Если завтра появится "идеальный ИИ", который с точностью 99% предсказывает, что уязвимость будет эксплуатирована в течение 30 дней, - правда ли, что роль VM-специалиста всё равно не исчезнет? В чём тогда останется человеческая зона ответственности?
32:31 О реализуемости полного моделирования путей атаки и автоматизированном реагировании
37:46 Насколько справедливо утверждение, что IT-отделы часто фактически саботируют VM? Как это выглядит на практике: это злой умысел, защита своих интересов или просто боль от перегрузки?
42:43 Как выглядит VM-процесс для систем, которые нельзя патчить или даже активно сканировать?
45:51 Как превратить IT-шников в ответственных хозяев своих активов?
48:48 Насколько сильно отличается подход к детектированию и управлению уязвимостями в Linux, контейнерах, Kubernetes и облаках от классического сканирования Windows-хостов? Где сегодня самые большие слепые зоны?
51:30 Детектирование - это только начало, а вся драма начинается после? Какие этапы после детекции чаще всего "рассыпаются" в реальных компаниях?
54:26 Блиц-вопросы
56:11 Заключение

📺 Смотрите на платформах: VK Видео, RUTUBE, YouTube.
🎧 Слушайте на платформах: Яндекс Музыка, Звук, Spotify, Pocket Casts, Deezer, Podcast Addict, Mave.

Про уязвимость Spoofing - Microsoft SharePoint Server (CVE-2026-32201)

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

Про уязвимость Spoofing - Microsoft SharePoint Server (CVE-2026-32201)

Про уязвимость Spoofing - Microsoft SharePoint Server (CVE-2026-32201). Уязвимость из апрельского Microsoft Patch Tuesday. Описание, которое дали эксперты Microsoft, максимально неконкретное: "Некорректная проверка входных данных в Microsoft Office SharePoint позволяет неавторизованному атакующему выполнить спуфинг по сети. Атакующий, успешно проэксплуатировавший эту уязвимость, может просматривать некоторую чувствительную информацию (конфиденциальность), вносить изменения в раскрытую информацию (целостность), но не может ограничить доступ к ресурсу (доступность)." Спуфинг - это атака, при которой злоумышленник подделывает данные, адрес, идентификатор или доверенный источник, чтобы выдать себя за легитимного пользователя, сервис или систему.

Что же скрывается за этим описанием на самом деле? В апрельском обзоре на MSPT эксперт ZDI заметил, что уязвимости такого рода в SharePoint часто связаны с XSS-атаками.

🛠 23 апреля на GitHub был опубликован эксплойт, автор которого утверждает, что уязвимость сводится к следующему: "Неаутентифицированный атакующий может отправить специально сформированный HTTP-запрос для внедрения вредоносного JavaScript-кода (reflected XSS), который будет выполнен в контексте безопасности сайта SharePoint."

Иными словами, атакующий отправляет специально сформированный запрос на сервер SharePoint, из-за чего SharePoint формирует вредоносную ссылку от имени доверенного источника. Атакующий передаёт эту ссылку пользователю. Когда пользователь открывает такую ссылку, внедрённый вредоносный JavaScript выполняется в контексте SharePoint, что может использоваться для кражи данных из текущей сессии, перехвата токенов аутентификации, а также выполнения действий от имени пользователя через его активную сессию.

👾 Эксперты Microsoft отметили уязвимость как эксплуатируемую вживую в день публикации апрельского Microsoft Patch Tuesday, 14 апреля. Уязвимость была добавлена в CISA KEV. В тот же день исследователи из компании Defused сообщили о скоординированной разведывательной активности, нацеленной на уязвимые серверы SharePoint, которая осуществлялась с четырех IP-адресов в период с 1 по 11 апреля.

⚙️ Обновления доступны для Microsoft SharePoint Server 2016, 2019 и Subscription Edition.

VulnCheck (Vulnerability Intelligence вендор и CNA) выстроили занимательный конвейер регистрации CVE-идентификаторов для активно эксплуатирующихся уязвимостей через взаимодействие с мониторинговой организацией Shadowserver

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

VulnCheck (Vulnerability Intelligence вендор и CNA) выстроили занимательный конвейер регистрации CVE-идентификаторов для активно эксплуатирующихся уязвимостей через взаимодействие с мониторинговой организацией Shadowserver

VulnCheck (Vulnerability Intelligence вендор и CNA) выстроили занимательный конвейер регистрации CVE-идентификаторов для активно эксплуатирующихся уязвимостей через взаимодействие с мониторинговой организацией Shadowserver. Такой конвейер работает без участия вендоров уязвимого ПО и особенно полезен для регистрации уязвимостей в продуктах вендоров, которые по каким-то причинам совсем не инициируют регистрацию CVE или делают это со значительной задержкой (например, в случае некоторых вендоров из Китая).

Схема процесса:

🔎 Обнаружение эксплуатации: Shadowserver Foundation фиксируют, что для конкретной уязвимости наблюдается эксплуатация вживую, при этом CVE-идентификатор у уязвимости отсутствует.

🧪 Проверка информации: VulnCheck валидируют информацию и подтверждают, что для уязвимости ранее действительно не было зарегистрировано CVE.

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

🆔 Публикация CVE: после подтверждения уязвимости ей присваивается CVE-идентификатор с привязкой к году первоначального раскрытия (например, CVE-2021-4473, если уязвимость была раскрыта в CNVD в 2021 году). В качестве CNA выступают сами VulnCheck.

📡 Распространение: опубликованный CVE-идентификатор передаётся обратно в Shadowserver для использования в детектировании, а также добавляется в VulnCheck KEV. Дополнительно рассылаются уведомления подписчикам по email и Slack.

VulnCheck приводят примеры заведённых по такому процессу уязвимостей:

🔻 CVE-2026-22679 - уязвимость удалённого выполнения команд без аутентификации в Weaver (Fanwei) E-cology 10.0. Первые признаки эксплуатации зафиксированы Shadowserver Foundation 31.03.2026.

🔻 CVE-2021-4473 - уязвимость внедрения команд в Tianxin Internet Behavior Management System. Первые признаки эксплуатации зафиксированы Shadowserver Foundation 01.06.2024.

Итого. В таком процессе уязвимости фиксируются и оформляются на основе наблюдаемой эксплуатации и threat intelligence без обязательного участия вендора ПО. При этом регулятор, отвечающий за ведение базы уязвимостей, не перегружается операционной работой конвейера по сбору данных и заведению новых идентификаторов. 👍

🇷🇺 В российском контексте подобный подход можно было бы использовать для ускоренного заведения уязвимостей в БДУ ФСТЭК по факту их эксплуатации без активного участия в процессе регулятора и вендоров уязвимого ПО. Но для этого нужно фактически выдать некоторым российским Vulnerability Intelligence организациям полномочия по заведению идентификаторов БДУ, фактически аналогичные CNA, что, конечно, имеет свои плюсы и минусы. 🤔

Перед праздниками коллеги из CyberOK качественно накинули на EPSS с примерами недавних уязвимостей

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

Перед праздниками коллеги из CyberOK качественно накинули на EPSS с примерами недавних уязвимостей

Перед праздниками коллеги из CyberOK качественно накинули на EPSS с примерами недавних уязвимостей. Сразу поясню: у меня никаких претензий к идее EPSS нет. Предсказание скорого появления эксплоитов для уязвимостей! Для всех CVEшек! Бесплатно! Это же просто сказка! Ну, если бы это нормально работало. 😏

И ладно бы, эта штука просто колебалась вслед за новостным потоком: пошли новости о появлении эксплоитов или атак - взлетаем от 0 до 100%. Это, конечно, было бы никакое не предсказание, а просто очередная штука для отслеживания хайповости уязвимостей, тыщи их. Но ведь EPSS даже с этим не справляется! Для MongoBleed с публичным эксплоитом и признаками эксплуатации в атаках EPSS был околонулевой. 🤦‍♂️ И это обычное дело. Как посчитали в CyberOK, при слепом использовании фильтра EPSS>10% вы пропустите половину уязвимостей из CISA KEV. 🤷‍♂️

Я правда жду, когда EPSS-предсказания станут адекватнее, но пока от релиза к релизу ничего не меняется. 😟

ASUS и CISA откопали ShadowHammer в 2025

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

ASUS и CISA откопали ShadowHammer в 2025

ASUS и CISA откопали ShadowHammer в 2025. 🤔 17 декабря CISA добавили в KEV уязвимость "CVE-2025-59374 - ASUS Live Update Embedded Malicious Code Vulnerability". В NVD уязвимость была также опубликована 17 декабря, CNA ASUS. Она про версию клиента ASUS Live Update с зловредными модификациями, внесёнными через компрометацию цепочки поставок.

По ссылке из NVD на сайт ASUS (с нероссийских IP) видим описание APT-атаки ShadowHammer 2019 года (❗️), в рамках которой серверы ASUS пять месяцев раздавали модифицированную версию Live Update, устанавливающую некоторым пользователям малвари. 😱

❓ Ок, шесть лет назад ASUS разово раздали бяку клиентам. Но зачем по этому кейсу сейчас заводить CVE и, тем более, тащить её в CISA KEV?

➡️ CISA ответили в духе "CVE есть, эксплуатация подтверждена; а как давно эксплуатация была и насколько уязвимость сейчас критична - нам пофигу".

ASUS формально завели CVE, CISA формально добавили её в KEV. 👌🌝