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

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, что, конечно, имеет свои плюсы и минусы. 🤔

Про уязвимость Remote Code Execution - TrueConf Client (CVE-2026-3502) и "Операцию TrueChaos"

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

Про уязвимость Remote Code Execution - TrueConf Client (CVE-2026-3502) и Операцию TrueChaos

Про уязвимость Remote Code Execution - TrueConf Client (CVE-2026-3502) и "Операцию TrueChaos". Факт эксплуатации уязвимости клиента ВКС системы TrueConf в рамках кампании "TrueChaos", направленной на государственные структуры в Юго-Восточной Азии, обнаружили эксперты компании Check Point в начале 2026 года. Об этом они написали в блог-посте, вышедшем 31 марта. Они же зарепортили уязвимость вендору. После уведомления было разработано исправление, включенное в Windows-клиент TrueConf, начиная с версии 8.5.3 (выпущена в марте 2026 года).

Описание уязвимости: "Клиент TrueConf загружает код обновления приложения и применяет его без выполнения проверки. Злоумышленник, способный повлиять на путь доставки обновлений, может подменить полезную нагрузку обновления. Если такая нагрузка будет выполнена или установлена средством обновления, это может привести к выполнению произвольного кода в контексте процесса обновления или пользователя." CVSS:3.1/AV:A/AC:L/PR:H/UI:R/S:C/C:H/I:H/A:L (7.8)

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

Тут, конечно, можно сказать: раз уж сервер TrueConf был каким-то образом скомпрометирован, то чего удивляться, что через него скомпрометировали клиентов. 😏 Но, конечно, хорошо, что были внедрены меры безопасности, которые теперь затрудняют компрометацию через зловредные обновления, раздаваемые с сервера.

Скомпрометированный в рамках кампании "TrueChaos" сервер обслуживал десятки государственных учреждений, распространяя одно и то же вредоносное обновление. С высокой вероятностью в атаках использовался имплант Havoc - open-source фреймворк для постэксплуатации, позволяющий выполнять команды, управлять процессами, работать с токенами Windows, исполнять shellcode, загружать дополнительные payload-ы.

Честно говоря, я всегда воспринимал TrueConf как продукт, используемый только в России. Однако это не так. Эта платформа видеоконференций, поддерживающая как локальные (on-premises), так и облачные развёртывания, помимо России используется также в Восточной Азии, Европе и Америке. Более 100 000 организаций по всему миру используют её, включая правительства, оборонные структуры, критическую инфраструктуру, банки, энергетические компании и телеканалы. На странице Википедии упоминаются внедрения во Вьетнаме, Германии, Непале, Бангладеш. Учитывая, что CISA добавили 2 апреля уязвимость CVE-2026-3502 в CISA KEV, вероятно, что TrueConf может использоваться и в федеральных агентствах США.

Про уязвимость Remote Code Execution - Microsoft SharePoint (CVE-2026-20963)

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

Про уязвимость Remote Code Execution - Microsoft SharePoint (CVE-2026-20963)

Про уязвимость Remote Code Execution - Microsoft SharePoint (CVE-2026-20963). Уязвимость из январского MSPT. В момент публикации MSPT, 13 января, VM-вендоры не выделяли эту уязвимость в своих обзорах, а Microsoft не сообщали о признаках эксплуатации уязвимости. CVSS вектор для уязвимости был CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H (8.8). Из "PR:L" следует, что для эксплуатации уязвимости требуется аутентификация. Однако 17 марта Microsoft изменили описание уязвимости и CVSS вектор. Новый CVSS вектор: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8). Из "PR:N" следует, что аутентификация для эксплуатации уязвимости не требуется.

Актуальное описание уязвимости:

"Десериализация недоверенных данных (CWE-502) в Microsoft Office SharePoint позволяет неавторизованному атакующему выполнить код по сети. В сетевой атаке неаутентифицированный атакующий может записать произвольный код, чтобы внедрить (inject) и выполнить его удалённо на сервере SharePoint."

👾 18 марта уязвимость добавили в CISA KEV. Подробностей по эксплуатации пока нет. Публичных эксплоитов тоже пока нет. Но по потенциальным последствиям эксплуатации уязвимость может быть сравнима с прошлогодней RCE "ToolShell" (CVE-2025-49704).

Ситуация вокруг этой уязвимости демонстрирует: критичность уязвимости нельзя оценить один раз и навсегда. Для уязвимости не только могут в любой момент появляться признаки эксплуатации вживую или публичные эксплоиты, но даже сам вендор может в любой момент по каким-то причинам изменить описание и CVSS уязвимости. Поэтому данные по продетектированным в инфраструктуре уязвимостям необходимо постоянно отслеживать (самостоятельно или силами VM-вендора), актуализировать критичность уязвимостей и корректировать дедлайны задач на их устранение.

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

Поделюсь впечатлениями от сегодняшнего вебинара про Security Vision VM

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

Поделюсь впечатлениями от сегодняшнего вебинара про Security Vision VMПоделюсь впечатлениями от сегодняшнего вебинара про Security Vision VMПоделюсь впечатлениями от сегодняшнего вебинара про Security Vision VMПоделюсь впечатлениями от сегодняшнего вебинара про Security Vision VMПоделюсь впечатлениями от сегодняшнего вебинара про Security Vision VMПоделюсь впечатлениями от сегодняшнего вебинара про Security Vision VMПоделюсь впечатлениями от сегодняшнего вебинара про Security Vision VMПоделюсь впечатлениями от сегодняшнего вебинара про Security Vision VMПоделюсь впечатлениями от сегодняшнего вебинара про Security Vision VMПоделюсь впечатлениями от сегодняшнего вебинара про Security Vision VM

Поделюсь впечатлениями от сегодняшнего вебинара про Security Vision VM. Вебинар назывался достаточно провокационно: "98% уязвимостей можно игнорировать? Как перестать чинить всё подряд и заняться реальными угрозами". Меня формулировки про 2% всегда триггерят. 😤 Я считаю, что фиксить нужно ВСЕ уязвимости (но с разным SLA) и, по возможности, безусловным патчингом.

Но, по правде сказать, на этом вебинаре и НЕ транслировали идею, что 98% уязвимостей можно игнорировать. Скорее, подробно демонстрировали возможности Security Vision VM (я наделал ~100 скринов 🔥) и говорили о необходимости приоритизированного устранения уязвимостей. 👌

Для этого Security Vision представили свою версию Трендовых Уязвимостей. Это уязвимости из CISA KEV ИЛИ с EPSS > 0,5. Всего у них получается ~1500 таких уязвимостей.

Мне, конечно, есть что сказать и про EPSS, и про CISA KEV. 🙄 Но как быстрое решение, как плейсхолдер - почему бы и нет. Это лучше, чем ничего. 👍

Не пора ли создать систему государственного мониторинга инфраструктуры (активов и уязвимостей) аналогичную CISA BOD 23-01? Продолжу размышления о необходимости российского Реестра Известных Эксплуатабельных Уязвимостей с конкретными дедлайнами по их устранению, аналога CISA KEV

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

Не пора ли создать систему государственного мониторинга инфраструктуры (активов и уязвимостей) аналогичную CISA BOD 23-01? Продолжу размышления о необходимости российского Реестра Известных Эксплуатабельных Уязвимостей с конкретными дедлайнами по их устранению, аналога CISA KEV

Не пора ли создать систему государственного мониторинга инфраструктуры (активов и уязвимостей) аналогичную CISA BOD 23-01? Продолжу размышления о необходимости российского Реестра Известных Эксплуатабельных Уязвимостей с конкретными дедлайнами по их устранению, аналога CISA KEV. На это можно возразить: ну допустим, сроки устранения будут определены, как сделать так, чтобы в эти сроки укладывались? 🤔

Американцы решили эту проблему для инфраструктуры федеральных агентств с помощью системы, описанной в директиве CISA BOD 23-01. Я разбирал её года 1,5 назад. Она предусматривает

🔹 еженедельное обнаружение активов в инфраструктуре;

🔹 циклические двухнедельные сканы активов на уязвимости;

🔹 оперативную передачу информации об активах, уязвимостях и процессе сканирования регулятору.

Это позволяет регулятору отслеживать актуальное состояние инфраструктуры органа/организации и оперативно проводить необходимые стимуляции. 🥕

Имхо, перенимать можно практически 1 в 1. 😉

Не пора ли создать российский аналог CISA KEV?

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

Не пора ли создать российский аналог CISA KEV?

Не пора ли создать российский аналог CISA KEV? Я, конечно, не в курсе технических подробностей недавних инцидентов в крупных отечественных компаниях, но что-то подсказывает, что без эксплуатации известных критичных уязвимостей, незапатченных своевременно, там не обошлось.

Можно, конечно, говорить, что пострадавшие организации сами виноваты. Им дали базу уязвимостей, методику оценки критичности уязвимостей, руководство по построению VM-процесса. Могли бы делать, как написано, и эксплуатабельные уязвимости устранялись бы. Или, как минимум, могли бы обращать внимание на трендовые уязвимости от PT. Но, похоже, организации не тянут это без директивной стимуляции. 🤷‍♂️

Как CISA ставит федеральным агентствам США чёткие дедлайны по устранению конкретных особо критичных уязвимостей, эксплуатация которых была подтверждена, так и наши регуляторы могли бы ставить аналогичные дедлайны. Хотя бы для организаций, на которые распространяется 117-й приказ и для КИИ.

Июльский Linux Patch Wednesday

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

Июльский Linux Patch Wednesday

Июльский Linux Patch Wednesday. В этот раз 470 уязвимостей, чуть меньше, чем в июне. Из них 291 в Linux Kernel. Для одной уязвимости есть признаки эксплуатации вживую (CISA KEV):

🔻 SFB - Chromium (CVE-2025-6554)

Ещё для 36 (❗️) уязвимостей доступны публичные эксплоиты или имеются признаки их существования. Из них можно выделить:

🔸 RCE - Redis (CVE-2025-32023), pgAdmin (CVE-2024-3116), Git (CVE-2025-48384)
🔸 EoP - Sudo (CVE-2025-32462, CVE-2025-32463)
🔸 PathTrav - Tar (CVE-2025-45582)
🔸 XSS - jQuery (CVE-2012-6708)
🔸 SFB - PHP (CVE-2025-1220)
🔸 DoS - LuaJIT (CVE-2024-25177), Linux Kernel (CVE-2025-38089)
🔸 MemCor - DjVuLibre (CVE-2025-53367)

🗒 Полный отчёт Vulristics