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

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

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

Про уязвимость 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 (США, Великобритания, Канада, Австралия и Новая Зеландия) призвали ускорить устранение уязвимостей, отказаться от легаси-систем и навести порядок на периметре

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

Руководители национальных агентств кибербезопасности альянса 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)

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

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"

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

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

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

Если несознательный исследователь опубликует полный ресерч по уязвимости, вообще не информируя вендора, т.е. сразу сделает full disclosure, это будет классический Zero Day. Тут вопросов нет. Но есть тонкости:

➡️ Является такая уязвимость Zero Day до момента публичного раскрытия?
➡️ Если сознательный исследователь информирует вендора, является ли уязвимость Zero Day от момента обнаружения её исследователем до момента передачи данных о ней вендору и во время разработки патча вендором?
➡️ Если уязвимость была Zero Day, то после выхода патча вендором, корректно ли продолжать называть такую уязвимость Zero Day?

Есть разные мнения и определения:

1. Trendmicro: "A zero-day vulnerability is a vulnerability in a system or device that has been disclosed but is not yet patched".
2. Kaspersky: "A zero-day vulnerability is a software vulnerability discovered by attackers before the vendor has become aware of it."
3. Portswigger: "A zero-day (0day) vulnerability refers to a security vulnerability for which no mitigation or patch is available at the time it is disclosed or made public".
4. ScienceDirect: "Zero-day vulnerability is defined as a security flaw that has not yet been disclosed to the vendor or developers".

Как видим, согласно некоторым определениям раскрытие информации (disclosure) требуется для отнесения уязвимости к Zero Day, а согласно другим вроде как и нет.

В глоссарии NIST нет понятия "zero day vulnerability".

В глоссарии ФСТЭК Уязвимость нулевого дня (Zero-day vulnerability) это "уязвимость, которая становится известной до момента выпуска разработчиком программного обеспечения информационной системы мер защиты информации по ее устранению, исправлений ошибок или соответствующих обновлений". Тут тоже не вполне понятно "становится известной" широкому кругу лиц или вообще, даже одному исследователю?

Лично мне НЕ нравится идея называть уязвимость Zero Day только в момент её опубликования. Почему? Если мы определяем таким образов, то в случае тайного зловредного использования уязвимости (например #Eternalblue до утечки из NSA) мы не можем сказать что это было использование Zero Day уязвимости. Публикации же (пока) не было! Хотя очевидно это было именно использование Zero Day уязвимости.

Ок, можем подкрутить и говорить, что нужно либо опубликование, либо использование. И какое использование? Вот есть исследователь, нашедший уязвимость. В ходе ресерча он эту уязвимость явно как-то использовал / тестировал на чем-то. Получается нужно не простое использование, а зловредное. А как определить зловредность? Это тоже добавляет неразберихи.

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