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

По поводу сообщений о двух активно эксплуатируемых 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 в целом.

Про уязвимость Elevation of Privilege - Windows Ancillary Function Driver for WinSock (CVE-2026-68820)

Про уязвимость Elevation of Privilege - Windows Ancillary Function Driver for WinSock (CVE-2026-68820)

Про уязвимость Elevation of Privilege - Windows Ancillary Function Driver for WinSock (CVE-2026-68820). Ancillary Function Driver (AFD.sys, "драйвер вспомогательных функций") - компонент Windows, работающий в режиме ядра и обеспечивающий работу протокола сетевого взаимодействия Winsock TCP/IP. Уязвимость из августовского Microsoft Patch Tuesday. Использование памяти после её освобождения ("Use-after-free", CWE-416) в Windows Ancillary Function Driver for WinSock позволяет локальному злоумышленнику повысить привилегии до уровня SYSTEM. Для успешной эксплуатации требуется выиграть состояние гонки (race condition). В итоге злоумышленник может получить полный контроль над Windows-хостом, выполнять команды с максимальными привилегиями, отключать средства защиты, устанавливать вредоносное ПО и получать доступ к данным других пользователей.

👾 Уязвимость уже эксплуатировалась в реальных атаках на момент раскрытия в рамках августовского Microsoft Patch Tuesday, 11 августа. В тот же день уязвимость была добавлена в CISA KEV. Примечательно, что при этом в описании на сайте Microsoft зрелость кода эксплоита (Exploit Code Maturity) в CVSS была отмечена как "Unproven" ("не подтверждённый"). 🤷‍♂️ За сообщение об уязвимости Microsoft благодарили экспертов компании Check Point.

Подробности по эксплуатации уязвимости в атаках были опубликованы в блоге Check Point также 11 августа. Уязвимость эксплуатируется в рамках кампании "Operation Dream Job", нацеленной на организации по всему миру, с особым фокусом на оборонный сектор Европы и Индии. Кампания связана с группировкой Lazarus. Всё начинается с целевых фишинговых сообщений, в которых жертвам предлагают привлекательные вакансии в известных компаниях оборонной, аэрокосмической и авиационной отраслей. Жертву убеждают открыть PDF-приманку, имитирующую описание вакансии Lockheed Martin. При этом запускается лёгкий загрузчик - MISTPEN, работающий в памяти. Он использует Microsoft Graph API для доступа к OneDrive, откуда получает дополнительные модули и запускает их в памяти ("run them in memory"). На начальных этапах заражения злоумышленник развёртывает несколько модулей разведки, которые собирают информацию о системе и процессах. После подтверждения пригодности цели MISTPEN получает дополнительный модуль закрепления ("persistence module"), который устанавливает вредоносное ПО на диск и обеспечивает автоматический запуск MISTPEN после перезагрузки системы. После закрепления MISTPEN загружает находящийся в памяти модуль, предназначенный для эксплуатации рассматриваемой уязвимости CVE-2026-68820. Исследователи Check Point считают, что эта уязвимость эксплуатировалась в рамках кампании "Operation Dream Job" как минимум с начала июля 2026 года. Успешная эксплуатация позволяет вредоносному ПО запустить FudModule (руткит Lazarus уровня ядра) с привилегиями SYSTEM. Конечный бэкдор, доставляемый MISTPEN, - ForestTiger. Он обеспечивает злоумышленникам удалённый доступ к скомпрометированной системе, позволяет выполнять команды, собирать информацию о хосте и загружать дополнительные вредоносные компоненты.

🛠 Публичных эксплоитов для уязвимости пока не наблюдается. Есть несколько объявлений о продаже эксплоитов, но доверия они не вызывают.

⚙️ Обновления доступны для Windows 10, Windows 11 и Windows Server 2019.

На сайте Positive Technologies вышло исследование "Рынки монетизации уязвимостей"

На сайте Positive Technologies вышло исследование Рынки монетизации уязвимостейНа сайте Positive Technologies вышло исследование Рынки монетизации уязвимостейНа сайте Positive Technologies вышло исследование Рынки монетизации уязвимостейНа сайте Positive Technologies вышло исследование Рынки монетизации уязвимостейНа сайте Positive Technologies вышло исследование Рынки монетизации уязвимостейНа сайте Positive Technologies вышло исследование Рынки монетизации уязвимостейНа сайте Positive Technologies вышло исследование Рынки монетизации уязвимостейНа сайте Positive Technologies вышло исследование Рынки монетизации уязвимостейНа сайте Positive Technologies вышло исследование Рынки монетизации уязвимостейНа сайте Positive Technologies вышло исследование Рынки монетизации уязвимостей

На сайте Positive Technologies вышло исследование "Рынки монетизации уязвимостей". Сделаю краткую выжимку.

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

⚖️ Легальный рынок

Багбаунти является основным легальным способом монетизации уязвимостей. Компании выплачивают исследователям вознаграждения за найденные уязвимости в системах, продуктах и сервисах. Основной фокус багбаунти-программ составляет внешняя поверхность атаки: веб-приложения, API и корпоративная инфраструктура. 96% исследователей работают с веб-приложениями, а с ОС и ПО - лишь 38%. Чаще всего выявляют XSS, ошибки контроля доступа и конфигураций.

Компании могут запускать собственные программы или использовать платформы вроде HackerOne, Bugcrowd и Standoff Bug Bounty. Стоимость размещения компаний на платформе составляет около 1 млн ₽ в год в России и 15 000 - 50 000 $ за рубежом. Размер выплат зависит от критичности уязвимости. Максимальные вознаграждения за отдельные типы уязвимостей достигают 2,4 млн ₽.

🌫️ Серый рынок

Серый рынок монетизации уязвимостей занимает промежуточное положение между легальными багбаунти-программами и теневыми площадками. Исследователи передают данные об уязвимостях посредникам или специализированным компаниям, а дальнейшее использование информации часто остается непрозрачным. Как правило, брокеров интересуют эксплоиты для 0-day-уязвимостей, стоимость которых может достигать 2,5 млн $.

🚫 Нелегальный рынок

Теневые форумы представляют нелегальный рынок уязвимостей. 0-day уязвимости там ценятся выше всего и они чаще всего выставляются на продажу: 49% всех объявлений. Объявления о продаже 1-day уязвимостей встречаются реже и составляют 11% от общего числа. В 38% объявлений речь идёт не о продаже, а о покупке данных о конкретной уязвимости.

Наиболее востребованы уязвимости удаленного выполнения кода (RCE) и повышения привилегий (LPE), на которые приходится 43% и 25% объявлений о продаже уязвимостей соответственно. Основные цели: интернет сервисы (36%) и корпоративное ПО (33%).

Стоимость уязвимостей определяется их эксплуатационной ценностью. Наибольший интерес представляют редкие и сложные для обнаружения уязвимости с высоким потенциалом применения. В 47% объявлений цена на уязвимости не указывается. Цена 0-day уязвимостей на чёрном рынке может быть до 20 раз выше, чем в багбаунти-программах.

На этом рынке также активно развивается сервисная модель. Уже около 7% объявлений об услугах связаны с покупкой или продажей услуг по эксплуатации уязвимостей в программном обеспечении. При этом 0-day уязвимости упоминаются в 40% таких объявлений, что подтверждает их высокую востребованность.

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

💡 Рекомендации

Компаниям следует сочетать технические и аналитические меры защиты: использовать багбаунти для непрерывного поиска уязвимостей, кибериспытания для проверки реальных сценариев атак и threat intelligence для мониторинга угроз и теневых площадок.

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

Руководители национальных агентств кибербезопасности альянса Five Eyes (США, Великобритания, Канада, Австралия и Новая Зеландия) призвали ускорить устранение уязвимостей, отказаться от легаси-систем и навести порядок на периметре

Руководители национальных агентств кибербезопасности альянса Five Eyes (США, Великобритания, Канада, Австралия и Новая Зеландия) призвали ускорить устранение уязвимостей, отказаться от легаси-систем и навести порядок на периметре

Руководители национальных агентств кибербезопасности альянса Five Eyes (США, Великобритания, Канада, Австралия и Новая Зеландия) призвали ускорить устранение уязвимостей, отказаться от легаси-систем и навести порядок на периметре. AI радикально ускоряет и усложняет киберугрозы: атаки становятся быстрее, масштабнее и доступнее для злоумышленников, а время между обнаружением уязвимости и её эксплуатацией сокращается всё сильнее. Frontier AI (самые передовые и мощные модели искусственного интеллекта, находящиеся на границе текущих возможностей ИИ и задающие новый уровень развития) уже сейчас меняет баланс сил в киберпространстве, одновременно усиливая как возможности атакующих, так и обороняющихся. При этом киберриски перестают быть чисто технической проблемой и становятся критическим бизнес-риском, требующим внимания руководства и советов директоров.

Организации должны усиливать базовые практики кибербезопасности, повышать устойчивость ("resilience") и активно внедрять AI в защиту - для раннего выявления уязвимостей, анализа аномалий и ускорения реагирования на инциденты. Успех зависит не от количества инструментов, а от качества базовой кибердисциплины, скорости реакции и интеграции безопасности в стратегию бизнеса. Те, кто НЕ адаптируется быстро, столкнутся с растущими операционными и стратегическими рисками.

Ключевые действия для руководителей

Основные принципы:

🔻 Подход secure-by-design и secure-by-default должен стать стандартной практикой, а не просто декларируемым стремлением ("aspiration").
🔻 Устойчивость не может зависеть от одного решения или технологии. Многоуровневая защита ("defence in depth") остаётся необходимой.
🔻 По мере развития AI-систем будут появляться новые и ранее неизвестные уязвимости, включая zero-day уязвимости.
🔻 Инциденты ("breaches") будут происходить. Подготовка помогает быстро их локализовать и не допустить перерастания в серьёзные операционные и финансовые кризисы.

Практические действия

Эти меры нельзя назвать новыми, но сегодня их реализация особенно важна для снижения не только технических рисков, но и потенциального операционного, финансового и репутационного ущерба:

🔸 Сократите поверхность атаки: ограничьте ненужный доступ к системам и внешние подключения. Оценивайте, действительно ли системы должны быть доступны извне, и изолируйте те, которым это не требуется.
🔸 Ускорьте процессы установки патчей: AI сокращает время между обнаружением уязвимости и её эксплуатацией. Задержки с обновлениями увеличивают риск, особенно для производственных ("operational") систем с длинными циклами обновления. Приоритизируйте обновления безопасности соответственно.
🔸 Решайте проблему устаревших систем: неподдерживаемые системы - лёгкие цели. Это не просто технический долг, а стратегические обязательства ("liabilities").
🔸 Пересмотрите и усилите контроль идентификации и доступа: ограничьте, кто может получать доступ к критическим системам. Внедряйте строгую аутентификацию и регулярно пересматривайте права доступа.
🔸 Подготовьтесь к инцидентам заранее: тестируйте планы реагирования, обучайте команды и исходите из того, что взломы неизбежны. Фокус - на быстром сдерживании ("containment") и восстановлении.

Как видите, VM-ная тема, в связи с бурным развитием технологий ИИ, актуальна для англосаксов как никогда. 😎 И нам тоже стоит к этим призывам прислушаться. 😉

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

Выпустил свои размышлизмы о том, что такое Zero Day уязвимость как отдельный эпизод с видяшкой на английском

Выпустил свои размышлизмы о том, что такое Zero Day уязвимость как отдельный эпизод с видяшкой на английском. На русском было тут.

Vulnerability Management решения и Zero Day уязвимости (1/3)

Vulnerability Management решения и Zero Day уязвимости (1/3)

Vulnerability Management решения и Zero Day уязвимости (1/3)

В моем англоязычном телеграмм-чате @avleonovchat задали вопрос: "Как найти 0day уязвимости с помощью Qualys?" Видимо этот вопрос можно расширить. Не только с помощью Qualys, а вообще с помощью любого VM-решения. И возможно ли это сделать вообще? Там завязалась довольно интересная дискуссия.

Вопрос не такой однозначный. Чтобы ответить на него, следует определиться что такое Zero Day уязвимость. Если мы посмотрим википедию, то исторически "0" это количество дней, которое есть у вендора на фикс уязвимости.

"Eventually the term was applied to the vulnerabilities that allowed this hacking, and to the number of days that the vendor has had to fix them."

Иллюстрация сгенерирована Stable Diffusion 2.1: "calendar on the wall cyber security vulnerability zero day"