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

Следующим мероприятием, в котором я собираюсь поучаствовать, будет форум "ПРОВЕРКА НА ПРОЧНОСТЬ: практика анализа защищённости"

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

Следующим мероприятием, в котором я собираюсь поучаствовать, будет форум ПРОВЕРКА НА ПРОЧНОСТЬ: практика анализа защищённости

Следующим мероприятием, в котором я собираюсь поучаствовать, будет форум "ПРОВЕРКА НА ПРОЧНОСТЬ: практика анализа защищённости". Пройдёт это мероприятие 14 октября в "Холидей Инн Сокольники". Фактически это спин-офф "Территории Безопасности" с фокусом на работе с уязвимостями во всех проявлениях. 😇

В программе - дискуссии, доклады и мастер-классы о реальной оценке защищённости, управлении уязвимостями (и экспозициями), анализе поверхности атаки, выборе методов проверки (аудит, пентест, Red Team, Purple Team, Bug Bounty), применении ИИ и автоматизации, метриках, защите АСУ ТП, проверке подрядчиков и правовых аспектах этичного хакинга.

В общем, наконец-то мы дождались большой нейтральной конфы, где VM/CTEM будет непосредственно в фокусе, а не где-то сбоку. 🤩🥳

Мои активности:

🔹 Выступлю с 20-минутным докладом "Трендовые уязвимости в 2026 году: как определить, что действительно важно". Расскажу о различных методах оценки критичности уязвимостей, о трендовых уязвимостях текущего года и о том, как мы в Positive Technologies их отбираем. 😉🤫

🔹 Буду модерировать часовой круглый стол "VM, DETECTION & RESPONSE: Придёт ли к нам реальная автоматизация?". Побеседуем о перспективном и наболевшем в VM/VMDR/CTEM. Со стороны вендоров заявлены Андрей Никонов из Vulns io VM, Дмитрий Черняков из RedCheck, Кирилл Евтушенко из Кауч. Со стороны клиентов заявлены Владимир Мельников из SOC Билайн, Дарина Кривошеева из VK, Иван Советкин из МТС Банк. Состав топовый, должно пройти интересно. Накидывайте в комментарии каверзные вопросы. 😏

Все на ПнП 14 октября! 🏃‍♂️

Сентябрьский "В тренде VM": уязвимости TeamCity, TrueConf, SharePoint, Windows и Zimbra Collaboration

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

Сентябрьский В тренде VM: уязвимости TeamCity, TrueConf, SharePoint, Windows и Zimbra Collaboration

Сентябрьский "В тренде VM": уязвимости TeamCity, TrueConf, SharePoint, Windows и Zimbra Collaboration. Представляю традиционную ежемесячную подборку трендовых уязвимостей по версии Positive Technologies. В прошлом августовском выпуске было четыре уязвимости. В этот раз их набралось шесть.

🗞 Пост на Хабре
🗒 Дайджест на сайте PT

🔻 RCE - TeamCity (CVE-2026-63077). Активно эксплуатируемая уязвимость в проприетарном решении компании JetBrains, предназначенном для автоматизации сборки, тестирования и развёртывания программного обеспечения. Есть публичные эксплоиты.

🔻 RCE - TrueConf Server (CVE-2026-72529, CVE-2026-72530). Активно эксплуатируемая цепочка уязвимостей в отечественном корпоративном мессенджере и платформе для UltraHD видеоконференций.

🔻 AuthBypass - Microsoft SharePoint (CVE-2026-55040). Активно эксплуатируемая уязвимость в веб-приложении от Microsoft, предназначенном для развёртывания корпоративных интранет-порталов, управления документами и совместной работы. Есть публичные эксплоиты.

🔻 EoP - Windows Ancillary Function Driver for WinSock (CVE-2026-68820). Активно эксплуатируемая уязвимость в компоненте Windows, обеспечивающем работу протокола сетевого взаимодействия Winsock TCP/IP.

🔻 RCE - Zimbra Collaboration (CVE-2026-73570). Активно эксплуатируемая уязвимость в пакете программного обеспечения для совместной работы, включающем почтовый сервер и веб-клиент. Есть публичные эксплоиты.

🟥 Полный список трендовых уязвимостей смотрите на портале

По поводу сообщений о двух активно эксплуатируемых 0day RCE-уязвимостях в Citrix NetScaler

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

По поводу сообщений о двух активно эксплуатируемых 0day RCE-уязвимостях в Citrix NetScaler

По поводу сообщений о двух активно эксплуатируемых 0day RCE-уязвимостях в Citrix NetScaler. NetScaler (Citrix NetScaler, Citrix ADC) - это контроллер доставки приложений (ADC), который анализирует, распределяет, оптимизирует и защищает сетевой трафик на уровнях L4-L7, в том числе выполняет балансировку нагрузки. В составе NetScaler также предусмотрена функциональность NetScaler Gateway, которая обеспечивает защищённый удалённый доступ пользователей к корпоративным приложениям и внутренним ресурсам.

25 сентября появились сообщения в Reddit r/Citrix с рекомендацией выключить NetScaler-ы. Упоминались две уязвимости нулевого дня. Один из пользователей сообщил, что эти сведения поступили из предварительного уведомления NCSC-NL (национального центра кибербезопасности Нидерландов), которое распространялось с ограничениями Traffic Light Protocol (TLP): AMBER+STRICT (разрешает делиться только внутри организации).

26 сентября эксперты watchTowr подтвердили сведения об обеих уязвимостях:

"Нам стало известно о дополнительной информации, которой мы делимся. Мы и понятия не имели, что системные администраторы Citrix как фанаты GTA6 - такие дружелюбные 🙂

Пожалуйста, направляйте дальнейшие вопросы в Citrix. Мы не являемся Citrix PSIRT (хотя иногда это выглядит именно так).

Ожидается, что Citrix опубликуют официальные сообщения и выпустит исправления в начале следующей недели. Две уязвимости - обе позволяют удалённое выполнение кода (RCE).

Уязвимости не пропатчены, это zero-day. Они уже эксплуатируются в реальных атаках - их обнаружили в ходе форензики.

Как всегда, клиенты watchTowr Platform уже имеют доступ к этой информации и располагают всем необходимым, чтобы снизить уровень риска."

П̶о̶ с̶о̶с̶т̶о̶я̶н̶и̶ю̶ н̶а̶ 2̶7̶ с̶е̶н̶т̶я̶б̶р̶я̶ о̶ф̶и̶ц̶и̶а̶л̶ь̶н̶о̶е̶ у̶в̶е̶д̶о̶м̶л̶е̶н̶и̶е̶ о̶т̶ C̶i̶t̶r̶i̶x̶ о̶п̶у̶б̶л̶и̶к̶о̶в̶а̶н̶о̶ н̶е̶ б̶ы̶л̶о̶,̶ и̶с̶п̶р̶а̶в̶л̶е̶н̶и̶я̶ в̶ н̶а̶с̶т̶о̶я̶щ̶е̶е̶ в̶р̶е̶м̶я̶ о̶т̶с̶у̶т̶с̶т̶в̶у̶ю̶т̶.̶

UPD. Вышел бюллетень и обновление для CVE-2026-88771 и CVE-2026-88772.

Пока не установлено, насколько масштабны атаки. 26 сентября исследователь Кевин Бомонт заявил: "История с уязвимостями нулевого дня в Netscaler реальна, они используются в активных атаках. Исправления пока нет, если для вас уязвимости Netscaler чувствительны, выключите его". Публично доступных индикаторов компрометации (IoC) пока нет.

Эти уязвимости нулевого дня, по-видимому, НЕ связаны с CVE-2026-19490 и CVE-2026-19489 - ранее раскрытыми уязвимостями в Citrix NetScaler ADC и NetScaler Gateway, для которых уже доступны исправления. CVE-2026-19490 была добавлена в CISA KEV 9 сентября. Citrix NetScaler исторически был популярной целью атакующих. С учётом CVE-2026-19490 по состоянию на 27 сентября 2026 года в CISA KEV насчитывалось 13 записей, связанных с NetScaler, и 24 записи по продуктам Citrix в целом.

На сайте CISA 22 сентября опубликовали документ "Программа CVE: формирование фреймворка эры качества"

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

На сайте CISA 22 сентября опубликовали документ Программа CVE: формирование фреймворка эры качестваНа сайте CISA 22 сентября опубликовали документ Программа CVE: формирование фреймворка эры качества

На сайте CISA 22 сентября опубликовали документ "Программа CVE: формирование фреймворка эры качества". В оригинале "CVE Program: Establishing a Quality Era Framework". Основная проблема, которую они там фиксируют: CVE Program быстро масштабируется, вместе с объёмом уязвимостей растёт нагрузка на процессы публикации, проверки и сопровождения CVE-записей.

По состоянию на 18 сентября 2026 года опубликовано более 67 тыс. новых CVE. По данным NVD, число CVE, поступивших на обработку, выросло на 263% в 2020-2025 годах. За первые три месяца 2026 года на обработку поступило на треть больше CVE, чем за тот же период 2025 года.

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

Руководство CISA выделяет четыре направления работы:

🔹 управление CVE Program;
🔹 участие представителей экосистемы - CNA, Roots, CNA-LR, исследователи, вендоры, поставщики инструментов и государственные организации;
🔹 инфраструктура данных - API, схемы, библиотеки проверки и CVE Org;
🔹 качество записей CVE - полнота, точность, своевременность и практическая применимость данных.

Для этих направлений определены показатели качества (на иллюстрации) - от времени принятия управленческих решений и надёжности API до доли записей CVE, соответствующих установленным критериям качества, и количества исправлений после публикации (или скорости внесения исправлений? 🤔 Имхо, тут неоднозначно: "Rate of corrections/updates needed post-publication").

"Эпоха качества требует согласованного развития по четырём направлениям: управление программой CVE, участие представителей экосистемы, инфраструктура данных и содержание записей CVE.

🔻 Улучшение содержания записей CVE зависит от чётких требований к данным, эффективных инструментов и активного участия CNA.
🔻 Развитие инфраструктуры данных требует постоянных инвестиций, защищённых и масштабируемых систем, а также обратной связи от пользователей, которые используют эти данные.
🔻 Расширение участия в экосистеме зависит от широкого представительства технологий, отраслей, регионов и сообществ, которые обслуживает программа CVE.
🔻 Совершенствование управления программой зависит от прозрачного управления, дальнейшего организационного развития, совместного участия, эффективности и способности оперативно реагировать на потребности мирового сообщества, занимающегося управлением уязвимостями."

Этот документ задаёт рамку для следующего этапа развития CVE Program (читай: по большей части вода-водичка, правильные общие слова и благие намерения без какой-либо конкретики 😉). Описания конкретных изменений обещают выложить в ближайшие месяцы: "в этой серии публикаций будут описаны текущие и планируемые улучшения ключевых компонентов инфраструктуры, обеспечивающих работу программы CVE".

Коллегам из ФСТЭК тоже стоит к этой движухе присмотреться и, возможно, что-то перенять для развития БДУ.

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

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

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

Про уязвимость Remote Code Execution - cPanel (CVE-2026-87899). cPanel - это коммерческая панель управления Linux-серверами от компании cPanel, L.L.C. (входит в WebPros), которую часто используют хостинг-провайдеры, чтобы клиенты могли управлять хостингом через браузер. Панель работает по платной лицензии: провайдер устанавливает её на свои серверы (выделенные или VPS) и создаёт клиентские аккаунты. Каждый клиент через cPanel управляет своими сайтами, доменами, файлами, базами данных, почтой, SSL-сертификатами и DNS. Согласно описанию вендора, уязвимость CVE-2026-87899 позволяет аутентифицированному злоумышленнику повысить свои привилегии через функциональность CalDAV и CardDAV (протоколы для синхронизации календарей и контактов) в cPanel. Успешная эксплуатация уязвимости приводит к выполнению произвольного кода от root-а, что предоставляет злоумышленнику полный контроль над сервером.

Таким образом, для получения root-доступа к серверу злоумышленнику достаточно иметь аккаунт cPanel. Для компании, предоставляющей услуги shared-хостинга публично и неограниченному кругу лиц, это означает, что уязвимость может эксплуатировать любой клиент. Кроме того, учётные данные для доступа к cPanel могут быть украдены злоумышленниками или приобретены на чёрном рынке. В результате эксплуатации злоумышленник может получить доступ к данным других клиентов shared-хостинга, размещённых на том же сервере. Это, в свою очередь, может привести к утечке персональных данных, использованию сайтов для распространения вредоносного ПО и размещения незаконного контента.

⚙️ Уязвимость затрагивает cPanel/WHM версии 120 и выше. Исправления доступны в сборках 11.134.0.57, 11.136.0.41, 11.138.0.8 и более новых, а для WP Squared - в версии 11.138.1.11 и выше. С 31 марта 2026 года американская компания WebPros, которой принадлежат cPanel и Plesk, прекратила обслуживание хостинг-провайдеров из России и Беларуси, сославшись на требования экспортного и санкционного законодательства. По данным ТАСС, подписки российских клиентов были аннулированы. В таких условиях у российских провайдеров, продолжающих использовать cPanel, могут возникнуть дополнительные сложности со своевременным обновлением этого ПО.

🌐 По данным экспертов Positive Technologies, на shared-хостингах под управлением cPanel могут быть размещены около 35 миллионов веб-сайтов, 27 тысяч из которых - российские. По оценке компании ispmanager, cPanel и Plesk на конец марта 2026 года суммарно занимали около 5% российского рынка панелей для shared-хостинга, что соответствует как минимум 50 тыс. сайтов на cPanel и Plesk в доменных зонах .ru и .рф. Эти оценки могут не учитывать сайты российских компаний, которые размещаются на зарубежных shared-хостингах и используют нероссийские доменные зоны.

🛠👾 Публичных эксплоитов и признаков эксплуатации в реальных атаках пока нет.

💡 При использовании shared-хостинга компания доверяет хостинг-провайдеру обслуживание, обновление и безопасную настройку сервера, на котором размещён её веб-сайт. К выбору хостинг-провайдера стоит подходить ответственно, потому что невыполнение им своих обязанностей может нанести компании крупный ущерб. В этом вопросе лучше не экономить, а выбирать проверенных поставщиков услуг с подтверждёнными компетенциями и хорошей репутацией на рынке. Другой вариант - не использовать shared-хостинг, а заниматься обслуживанием сервера самостоятельно.

🗞 Мой комментарий по этой уязвимости вышел в новости на сайте SecPost.

На Хабре вышла статья о том, как MaxPatrol Carbon использовался при подготовке инфраструктуры для кибербитвы Standoff 17

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

На Хабре вышла статья о том, как MaxPatrol Carbon использовался при подготовке инфраструктуры для кибербитвы Standoff 17

На Хабре вышла статья о том, как MaxPatrol Carbon использовался при подготовке инфраструктуры для кибербитвы Standoff 17. Главная задача архитектора ИТ-инфраструктуры Standoff - найти баланс между сложностью сценариев атак и временем, необходимым для их реализации атакующими, поскольку соревнования проходят всего несколько дней. Архитектор формализует векторы атак, которые должны быть заложены в инфраструктуру, собирает под них стенды, настраивает активы и ролевую модель, продумывает, где должны быть мисконфигурации и подсказки в виде оставленных данных или специальных условий для успешной реализации сценария атаки. При этом "одна забытая учётная запись, лишний ACL или избыточный сетевой доступ могут существенно сократить маршрут атакующего". Если цепочка из десятков шагов превращается в один-два, весь замысел, заложенный при проектировании, теряется.

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

Архитектор может считать, что всё отладил, а тут - бац! Для какого-то софта в инфраструктуре появляется критичная эксплуатабельная уязвимость, и её нужно патчить, иначе для атакующих появляется незапланированный короткий путь для реализации атаки. При этом патчинг уязвимости не должен поломать запланированные векторы. 🤯

Поддерживать всю эту картину вручную, особенно когда активов много, практически невозможно. Поэтому коллеги из Standoff решили использовать MaxPatrol Carbon в качестве инструмента для:

🔹 проверки запланированных сценариев;
🔹 поиска непредусмотренных путей атаки.

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

🔻 возможность компрометации дополнительной учётки;
🔻 возможность эксплуатации уязвимости Nginx;
🔻 ошибка в настройке правил сетевого доступа.

Оказалось, что MaxPatrol Carbon, изначально предназначенный для поддержания инфраструктуры в максимально безопасном состоянии, можно использовать и для ещё более сложной задачи - поддержания её в "контролируемо уязвимом" состоянии. 😉

На конференции IT Elements эксперты компании Инфосистемы Джет представили "Фреймворк антихрупкой ИТ-архитектуры", учитывающий состояние процесса Управления Уязвимостями в организации

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

На конференции IT Elements эксперты компании Инфосистемы Джет представили Фреймворк антихрупкой ИТ-архитектуры, учитывающий состояние процесса Управления Уязвимостями в организации

На конференции IT Elements эксперты компании Инфосистемы Джет представили "Фреймворк антихрупкой ИТ-архитектуры", учитывающий состояние процесса Управления Уязвимостями в организации. Фреймворк включает в себя 7 стратегий по четырём направлениям:

🔹 Подготовка к вторжению - 1. Системное развитие и контроль, 2. Подготовка и прогнозирование.
🔹 Слева от вторжения - 3. Вовлечение и нападение, 4. Защита, замедление, сдерживание.
🔹 Справа от вторжения - 5. Обнаружение и реагирование.
🔹 После вторжения - 6. Восстановление, 7. Адаптация и перестройка.

Эти стратегии раскладываются в 33 домена, которые, в свою очередь, раскладываются в 390 практик.

Чтобы замерить индекс антихрупкости для своей организации, можно воспользоваться специальным интерактивным опросником. Индекс оценивает способность компании пережить кибератаку, продолжать работу в её условиях и восстановиться после неё. По итогам заполнения опросника получаем индекс от 0 до 100%, разбор по направлениям защиты и сравнение с другими участниками. Отраслевой уровень обновляется автоматически по мере накопления ответов респондентов. Индекс рассчитывается по открытой методике. Опросник должен заполнять CISO. Вопросы однотипны, варианты ответов: "Да", "Частично", "Нет", "Неприменимо", "Не знаю".

Теперь пройдёмся по 13 практикам, которые непосредственно связаны с Управлением Уязвимостями. Они находятся в разделе Слева от вторжения -> 4. Защита, замедление, сдерживание -> 4.4 Непрерывная работа с уязвимостями.

📄 Формализация процесса, ответственные за устранение и сроки устранения

4.4-1 Регламентирован и реализуется процесс управления уязвимостями, определяющий порядок их выявления, оценки критичности, планирования и контроля устранения. Определяются ответственные за устранение уязвимостей и реализацию исправлений, а также целевые сроки, согласованные службами ИБ и ИТ

В опроснике: 49. Регламентирован и реализуется процесс управления уязвимостями. Определены ответственные за устранение уязвимостей и реализацию исправлений, а также целевые сроки, согласованные службами ИБ и ИТ

📄 Задачи на сканирование

4.4-2 Определен перечень, приоритеты и сроки сканирования каждого актива/типов активов. В область сканирования включены все активы, обеспечивающие критически значимые процессы организации

В опроснике нет.

📰 Отслеживание информации об уязвимостях

4.4-3 Определены источники информации об уязвимостях (например, БДУ ФСТЭК России, уведомления от регуляторов, сайты производителей ПО, каналы СМИ и др.). Информация из этих источников систематически анализируется на предмет применимости к активам организации, выявленные релевантные уязвимости регистрируются

В опроснике нет.

🚨 Экстренная обработка уязвимостей

4.4-4 Документирована и реализуется процедура экстренной обработки критических уязвимостей, определяющая порядок оповещения ИБ и ИТ, экстренной оценки применимости уязвимости, реализации временных защитных мер и координации действий с процессом кризисного реагирования.

В опроснике: 50. Документирована и реализуется процедура экстренной обработки критических уязвимостей, определяющая порядок оповещения ИБ и ИТ, экстренной оценки применимости уязвимости, реализации временных защитных мер и координации действий с процессом кризисного реагирования.

🔎 Сканирование на наличие уязвимостей

4.4-5 Функционирует процесс регулярного автоматизированного поиска уязвимостей. Поиск выполняется автоматизированными средствами, использующими актуальные базы данных (сканеры уязвимостей).

В опроснике: 51. Функционирует процесс регулярного автоматизированного поиска уязвимостей. Поиск выполняется автоматизированными средствами, использующими актуальные базы данных.

💿 Базовые образы

4.4-6 Процесс управления уязвимостями включает процедуры проверки и устранения уязвимостей в базовых образах инфраструктуры, используемых для развертывания корпоративных информационных систем.

В опроснике нет.

⚖️ Продвинутая приоритизация уязвимостей

4.4-7 Приоритизация устранения уязвимостей выполняется по риск-ориентированным критериям, включая критичность актива, последствия эксплуатации, наличие доступных способов эксплуатации и техническую оценку уязвимости. Приоритеты используются для определения сроков устранения и контроля выполнения.

В опроснике: 52. Приоритизация устранения уязвимостей выполняется по риск-ориентированным критериям. Приоритеты используются для определения сроков устранения и контроля выполнения.

🔐 Сканирование с аутентификацией

4.4-8 Для обнаружения уязвимостей применяется аутентифицированное сканирование узлов, при котором средство сканирования получает контролируемый доступ к системе для более точного выявления уязвимых компонентов и конфигураций.

В опроснике нет.

🔗 Интеграция с GRC

4.4-9 Данные об уязвимостях автоматически синхронизируются с реестром рисков или системой управления рисками (GRC-системой). Изменение статуса уязвимости приводит к пересчету параметров риска и созданию или обновлению карточки риска.

В опроснике нет.

🎫 Интеграция с Task Tracker

4.4-10 Реализована интеграция инструментов сканирования уязвимостей с системой управления задачами. Задачи на устранение уязвимостей формируются автоматически, приоритет задач определяется критичностью уязвимости и значимостью актива.

В опроснике нет.

↪️ Компенсирующие меры

4.4-11 Для уязвимостей, устранение которых невозможно или небезопасно, определяется и применяется набор компенсирующих мер, выбор которых документируется и привязывается к конкретной уязвимости и активу.

В опроснике нет.

💭 План снижения риска

4.4-12 Для унаследованных систем, которые невозможно привести к актуальному уровню безопасности, разработаны и выполняются планы снижения риска. Планы определяют целевое состояние системы (вывод из эксплуатации или замена) и устанавливают временные меры защиты на период ее эксплуатации.

В опроснике нет.

⏱️ Отслеживание сроков устранения

4.4-13 Осуществляется системный контроль соблюдения целевых сроков устранения уязвимостей. Устранение выявленных уязвимостей периодически контролируется, результаты контроля регистрируются.

В опроснике: 53. Осуществляется периодический контроль соблюдения целевых сроков устранения уязвимостей. Устранение выявленных уязвимостей периодически контролируется.

В целом, довольно толковый набор практик. 👍 Единственное, не очень понятно, почему практик больше, чем вопросов в опроснике. Возможно, отобрали самое важное, а может, опросник будут расширять. 🤷‍♂️