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

Про уязвимость Remote Code Execution - TrueConf Server (CVE-2026-72529, CVE-2026-72530)

Про уязвимость Remote Code Execution - TrueConf Server (CVE-2026-72529, CVE-2026-72530)

Про уязвимость Remote Code Execution - TrueConf Server (CVE-2026-72529, CVE-2026-72530). TrueConf Server - российский on-premise корпоративный мессенджер и платформа для UltraHD видеоконференций. Рассматриваемая цепочка состоит из двух критических уязвимостей. Первая уязвимость CVE-2026-72529, вызванная отсутствием аутентификации критически важной функции (CWE-306), позволяет неаутентифицированному удалённому злоумышленнику с сетевым доступом к TCP-порту 4307 (открыт по умолчанию, согласно документации TrueConf) обратиться к недокументированной функции TrueConf Server и выполнить произвольный скрипт внутри изолированной среды ("песочницы"), в которой недоступны потенциально опасные библиотеки. Вторая уязвимость CVE-2026-72530 позволяет злоумышленнику осуществить инъекцию кода (CWE-94), выйти за пределы изолированной среды и выполнить произвольный код на ОС хоста с максимальными привилегиями. В том числе злоумышленник может удалить из журналов событий TrueConf записи, связанные с использованием эксплоита.

⚙️ Исправления для уязвимостей были выпущены 18 июня 2026 года. Уязвимыми являются версии 5.3.x ниже 5.3.9, 5.4.x ниже 5.4.9, 5.5.x ниже 5.5.5, а также ветки 5.2 и ниже (для обновления старых версий требуется обращение в техподдержку). Перерегистрация сервера при обновлении в рамках веток 5.3-5.5 не требуется, однако перед установкой вендор настоятельно рекомендует сделать бэкап. Если немедленное обновление невозможно, рекомендуется ограничить доступ к TCP-порту 4307 доверенными сетями.

👾 Эксперты Kaspersky ICS CERT раскрыли детали эксплуатации цепочки уязвимостей в посте, опубликованном 12 августа. Атаки с эксплуатацией уязвимостей CVE-2026-72529 и CVE-2026-72530 проводились на российские организации с июля 2026 года. В ходе атак злоумышленники получали сетевой доступ к TrueConf Server через порт 4307, с помощью CVE-2026-72529 выполняли скрипт в песочнице, а затем использовали CVE-2026-72530 для выхода из неё и выполнения кода с правами NT AUTHORITY\SYSTEM. Это позволяло им заменить один из файлов сервера TrueConf собственным веб-шеллом. В дальнейшем этот веб-шелл использовался для сбора информации об ИТ-инфраструктуре атакуемой организации, получения привилегированного доступа к базе данных TrueConf Server и подмены легитимных установщиков TrueConf Client вредоносной версией, содержащей малварь PhantomCore. После этого пользователи получали сообщение о необходимости загрузить новую (вредоносную) версию клиента TrueConf.

ВАЖНО: даже если в вашей организации не используется TrueConf, ваши сотрудники могли подключаться к взломанным серверам TrueConf ваших подрядчиков и контрагентов для участия в совместных онлайн-конференциях и, как следствие, могли установить вредоносную версию клиента на свои рабочие десктопы!

Малварь PhantomCore, характерная для APT-группировки Head Mare, автоматически загружается после старта системы и позволяет выполнять произвольные команды, фактически предоставляя злоумышленникам полный контроль над заражённым хостом. Также исследователи Kaspersky сообщали об использовании в атаках нового бэкдора, который они назвали PhantomGraph. Обе уязвимости (CVE-2026-72529 и CVE-2026-72530) были добавлены в CISA KEV 20 августа 2026 года.

🛠 Публичный эксплойт для CVE-2026-72530 был опубликован на GitHub 26 августа. Для полной цепочки уязвимостей CVE-2026-72529 и CVE-2026-72530 публичного эксплойта пока не наблюдается (несмотря на соответствующие флаги в БДУ ФСТЭК).

🌐 TrueConf Server широко используется в России и за рубежом, в том числе государственными учреждениями, финансовыми, промышленными, медицинскими и образовательными организациями.

Посмотрел, какие кейсы победителей премии Pentest award 2026 от Awillix были непосредственно связаны с уязвимостями

Посмотрел, какие кейсы победителей премии Pentest award 2026 от Awillix были непосредственно связаны с уязвимостями

Посмотрел, какие кейсы победителей премии Pentest award 2026 от Awillix были непосредственно связаны с уязвимостями. Подробности, как обычно, будут в осеннем спецвыпуске журнала "Хакер". Но общее впечатление можно составить и по краткому описанию кейсов в Хабр-статье с итогами церемонии награждения.

🔻 L3G5, победивший в номинации "AI", обнаружил схожие уязвимости в архитектуре ИИ-агентов двух крупных российских компаний, которые позволяли агентам выполнять привилегированные действия. L3G5 удалось показать, что эксплуатация этих уязвимостей в одном случае могла привести к утечке пользовательских запросов на адрес злоумышленника при анализе отравленного документа, а во втором - к раскрытию исходного кода всей агентской системы и получению доступа на запись в S3-хранилище с диалогами пользователей компании.

🔻 Хайдар Кабибо, победивший в номинации "Out of Scope", обнаружил уязвимость PhantomRPC в архитектуре Windows RPC (Remote Procedure Call), которая позволяет локально повышать привилегии до уровня SYSTEM. "Поскольку проблема связана с архитектурной уязвимостью, количество потенциальных векторов атаки фактически неограничено: любой новый процесс или служба, зависящие от RPC, могут ввести дополнительный путь повышения привилегий". Занимательно, что в Microsoft решили не заводить CVE-идентификатор для этой уязвимости. 🤷‍♂️

🔻 Денис Горюшев, победивший в категории "Девайс", обнаружил серию уязвимостей в Bluetooth-стеке некоторого embedded-устройства крупного китайского вендора. Уязвимости находятся в процессе ответственного раскрытия.

🔻 Владимир Кононович (DrMefistO), занявший второе место в категории "Девайс", продемонстрировал возможность загрузить собственную прошивку на автомобильные сигнализации (иммобилайзеры).

🔻 Иван Глинкин, занявший третье место в категории "Девайс", продемонстрировал возможность частичного восстановления данных из криптографических USB-накопителей после заявленного производителем полного сброса устройств.

🔻 Алексей Соловьев и Никита Свешников, победившие в категории "Системный взлом (Web & Logic)", обнаружили скрытые уязвимости в Си-компонентах языка PHP. В качестве последствий упоминают SQL-инъекции и каскадную десинхронизацию данных.

🔻 Влад Дриев и Олег Лабынцев, победившие в категории "Kill Chain", продемонстрировали цепочку от total black-box до компрометации двух доменов AD и ряда целевых сервисов вне доменной инфраструктуры. Георгий Кумуржи и Даниил Мамонтов, занявшие второе место в этой категории, получили доступ из Интернета к ЛВС организации, закрепились в инфраструктуре и реализовали ряд недопустимых событий, однако из описания непонятно, о каких именно событиях идёт речь. Cotsom, занявший третье место, продемонстрировал полную цепочку компрометации кластера Kubernetes: от первоначального проникновения через внешний периметр и захвата корпоративного кластера ClearML до реализации двух независимых векторов атаки на production-инфраструктуру. Упоминаются компрометация CSI-провайдера, злоупотребление механизмами GitLab CI/CD, а также обход политик Kyverno, позволивший развернуть привилегированный pod и получить административный контроль над кластером.

К сожалению, в статье с итогами вообще нет CVE/БДУ-идентификаторов. Если для уязвимостей, находящихся в процессе раскрытия (ну или отклонённых вендором), это понятно, то идентификаторы публично известных уязвимостей можно было бы и упоминать - для лучшего понимания кейсов и приоритизации устранения таких уязвимостей в инфраструктурах организаций. 😉

В Ведомостях вчера вышла статья с моими комментариями по поводу развития Vulnerability Management рынка в России и мире

В Ведомостях вчера вышла статья с моими комментариями по поводу развития Vulnerability Management рынка в России и мире

В Ведомостях вчера вышла статья с моими комментариями по поводу развития Vulnerability Management рынка в России и мире. Сама статья за paywall-ом, и мои комментарии там, вполне естественно и ожидаемо, были сильно сокращены, поэтому я приведу их здесь в развёрнутом виде.

Насколько адекватно делать выводы о динамике раскрытия уязвимостей, основываясь только на БДУ ФСТЭК России? (такую статистику привели коллеги из ЛК, привязав к ней анонс Kaspersky VM 😉)

Говоря о базе уязвимостей БДУ ФСТЭК России, важно учитывать, что она методологически не предназначена для учёта всех существующих уязвимостей: в неё включаются данные об уязвимостях отечественных продуктов, а также иностранных коммерческих и опенсорсных решений, применяемых в ГИС и на объектах КИИ. Поэтому БДУ не покрывает весь спектр уязвимостей, актуальных для российских инфраструктур, и её данных недостаточно для анализа глобальных трендов; для этого лучше использовать более полные источники, такие как PT DBugs или NIST NVD. Для визуализации статистики NVD удобно использовать дашборды, такие как CVE ICU. Текущие данные NVD показывают значительное увеличение скорости добавления новых CVE: за одинаковый период в 2025 году было зарегистрировано 22 041 уязвимость, а в 2026 году уже 31 917, что соответствует увеличению на 44,8%.

Такую динамику следует интерпретировать осторожно: рост числа зарегистрированных уязвимостей не означает, что ПО стало менее защищённым. Он во многом связан с повышением зрелости процессов раскрытия и регистрации уязвимостей, а также развитием средств автоматизированного анализа программного обеспечения, в т.ч. с использованием ИИ-технологий.

Что сейчас происходит с Vulnerability Management рынком?

Рынок Vulnerability Management в последние годы растёт как в России, так и в мире. В России важным фактором стал уход западных вендоров в 2022 году, что привело к появлению новых отечественных игроков. Внутренняя конкуренция стимулирует развитие функциональности решений, повышение качества детектирования, точности приоритизации и расширение интеграций с другими средствами защиты и ИТ-системами. Отдельно стоит отметить внимание ФСТЭК России к этой теме: разработка методических документов и требований способствует формированию более структурированного подхода к управлению уязвимостями.

Если смотреть ретроспективно, рынок Vulnerability Management прошёл путь от массового сканирования и детектирования CVE-уязвимостей к платформенному управлению защищённостью инфраструктуры. Полный и качественный поиск уязвимостей остаётся важной базовой функциональностью, однако сегодня всё больше учитывается контекст: критичность затронутых активов и возможность реальной компрометации через комбинацию выявленных уязвимостей. На Западе всё чаще говорят не о классическом Vulnerability Management, а о более широком подходе - Exposure Management или Continuous Threat Exposure Management (CTEM), где объектом управления становятся не только уязвимости с CVE/BDU-идентификаторами, но и уязвимости в широком смысле ("экспозиции"): ошибки конфигурации, проблемы с учётками, небезопасные настройки, избыточная сетевая связность активов и т.п. Обнаруженные проблемы используются CTEM-решениями для моделирования возможных путей развития атаки (attack paths), что позволяет выявлять и приводить в порядок наиболее проблемные участки инфраструктуры, повышая сложность и стоимость реальной атаки для злоумышленников.

В ближайшие годы развитие CTEM-функциональности, вероятно, продолжится. Одновременно будет расти использование ИИ для детектирования и приоритизации уязвимостей, анализа связей между активами и автоматизации принятия решений. Также в фокусе будет упрощение устранения уязвимостей за счёт автоматизации как технических, так и административных составляющих процесса.

На прошлой неделе западные ИБ-шники активно обсуждали очередное заявление руководителей NIST NVD, что "у них лапки", и они будут обогащать ещё меньше уязвимостей

На прошлой неделе западные ИБ-шники активно обсуждали очередное заявление руководителей NIST NVD, что у них лапки, и они будут обогащать ещё меньше уязвимостей

На прошлой неделе западные ИБ-шники активно обсуждали очередное заявление руководителей NIST NVD, что "у них лапки", и они будут обогащать ещё меньше уязвимостей. Хотя, казалось бы куда уж меньше. 😏 Суть обращения, опубликованного NIST 15 апреля, в том, что из-за резкого роста числа CVE они меняют подход к ведению National Vulnerability Database: вместо анализа всех уязвимостей база переходит на риск-ориентированную модель. Полноценно обогащаться будут только приоритетные уязвимости:

🔥 уже эксплуатируемые (из каталога CISA KEV) - обещают обрабатывать за сутки
🏛️ относящиеся к ПО, используемому в госсекторе США (федеральным правительством)
🛠️ относящиеся к критическому ПО, определённому в Executive Order 14028

Остальные CVE останутся в базе, но получат низкий приоритет и будут долго оставаться без детального анализа. При этом NVD отказываются от дублирования CVSS-оценок (если CVSS пришёл от CNA, ему будут доверять, а свой CVSS рассчитывать не будут), будут реже перерабатывать записи, по которым изменилась ситуация, и фактически законсервируют накопившийся бэклог, чтобы сосредоточиться на наиболее опасных уязвимостях ценой снижения полноты и единообразия данных по остальным.

В целом, у меня такие новости вызывают сплошные фейспалмы. 🤦‍♂️ От NIST, которые, по-видимому, разогнали всех адекватных IT/ИБ-специалистов и превратились в синекуру для бюрократов, тратящих огромное финансирование непонятно на что. От CISA, которые не могут навести порядок в базовом ИБ-сервисе, критичном и для США, и для мира в целом. От американской администрации, которая тратит совершенно астрономические суммы на дикие геополитические прожекты, но совершенно не заботится о том, что происходит (разваливается) у них дома. MAGA? Лол, что? 😅

Ну а в практическом плане это означает, что если вы полагаетесь ТОЛЬКО на бесплатную NVD, то совершаете фатальную ошибку. Адекватность этой базы год от года стремительно снижается. Учитывайте альтернативные источники: Vulners, DBugs, VulnCheck, GCVE, БДУ ФСТЭК и прочие. Единственной мировой базы уязвимостей больше нет.

Ниже привожу полный перевод сообщения NIST.
Читать далее

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

Вот такую информационную карту уязвимостей 2025 года показывал сегодня Алексей Сердечный, начальник отдела ФАУ "ГНИИИ ПТЗИ ФСТЭК России", в рамках своего доклада "Ландшафт актуальных угроз безопасности информации и тенденции их развития" на ТБ Форум

Вот такую информационную карту уязвимостей 2025 года показывал сегодня Алексей Сердечный, начальник отдела ФАУ ГНИИИ ПТЗИ ФСТЭК России, в рамках своего доклада Ландшафт актуальных угроз безопасности информации и тенденции их развития на ТБ ФорумВот такую информационную карту уязвимостей 2025 года показывал сегодня Алексей Сердечный, начальник отдела ФАУ ГНИИИ ПТЗИ ФСТЭК России, в рамках своего доклада Ландшафт актуальных угроз безопасности информации и тенденции их развития на ТБ ФорумВот такую информационную карту уязвимостей 2025 года показывал сегодня Алексей Сердечный, начальник отдела ФАУ ГНИИИ ПТЗИ ФСТЭК России, в рамках своего доклада Ландшафт актуальных угроз безопасности информации и тенденции их развития на ТБ ФорумВот такую информационную карту уязвимостей 2025 года показывал сегодня Алексей Сердечный, начальник отдела ФАУ ГНИИИ ПТЗИ ФСТЭК России, в рамках своего доклада Ландшафт актуальных угроз безопасности информации и тенденции их развития на ТБ ФорумВот такую информационную карту уязвимостей 2025 года показывал сегодня Алексей Сердечный, начальник отдела ФАУ ГНИИИ ПТЗИ ФСТЭК России, в рамках своего доклада Ландшафт актуальных угроз безопасности информации и тенденции их развития на ТБ ФорумВот такую информационную карту уязвимостей 2025 года показывал сегодня Алексей Сердечный, начальник отдела ФАУ ГНИИИ ПТЗИ ФСТЭК России, в рамках своего доклада Ландшафт актуальных угроз безопасности информации и тенденции их развития на ТБ Форум

Вот такую информационную карту уязвимостей 2025 года показывал сегодня Алексей Сердечный, начальник отдела ФАУ "ГНИИИ ПТЗИ ФСТЭК России", в рамках своего доклада "Ландшафт актуальных угроз безопасности информации и тенденции их развития" на ТБ Форум. Очень красиво. 👍

🔹 Можно видеть основные "скопления": Аппаратное обеспечение, Windows, Linux/Unix, Прикладное ПО, Beб, Библиотеки (где-то в середине, не подписано).

🔹 Подсвечены кластеры по вендорам и типам уязвимостей. Правда, если присматриваться, есть вопросики. Почему, например, Chrome в Linux/Unix, а не в Прикладном ПО? Или стоит ли выделять COVID19 в отдельный кластер? 🙂

🔹 Показаны уязвимости БДУ ФСТЭК, уязвимости без CVE, непроанализированные уязвимости, уязвимости с эксплоитами и признаками эксплуатации. Были ещё картинки по CWE-шкам, но я не стал их все выкладывать.

Идея для визуализации крутая. 🔥 Если трендовые уязвимости PT на такой карте показывать, около половины окажутся в кластере Windows. 😉

Прочитал статью "NVD больше не успевает за реальностью: взгляд R-Vision на пересмотр роли NIST"

Прочитал статью NVD больше не успевает за реальностью: взгляд R-Vision на пересмотр роли NIST

Прочитал статью "NVD больше не успевает за реальностью: взгляд R-Vision на пересмотр роли NIST". Очередная рефлексия на статью CYBERSECURITY DIVE про то, что у NIST-а лапки. 🙂 Имхо, ключевой тезис в статье R-Vision вот этот:

"Для нас качество базы измеряется не количеством CVE, а:

- скоростью реакции;
- полнотой покрытия реальных технологий;
- способностью адаптации под инфраструктуры заказчиков."

С одной стороны, соглашусь, что простое покрытие CVE-шек в текущей ситуации, когда идентификаторы могут заводиться на мусор, а на критичные уязвимости могут не заводиться, перестаёт быть единственным фактором, определяющим качество детектирования VM-решений. Всё стало сложнее. 💯

Но с другой стороны, сравнение баз VM-решений пересечением наборов CVE-идентификаторов всё ещё позволяет эффективно подсвечивать разницу в ТЕКУЩИХ возможностях детектирования и, при необходимости, обсуждать её с VM-вендорами. 😏 Аналогично можно сравниваться и по БДУ-идентификаторам. 😉