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

На сайте 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 оправдано только если мы говорим о каких-то прошедших событиях, когда фикса ещё не было.

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

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

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

Если мы условимся трактовать Zero Day уязвимости так широко, то можем рассмотреть такие их виды:

1. Публичные уязвимостей, для которых в момент публикации не было патча от вендора ПО (например, #ProxyNotShell). Такие уязвимости Vulnerability Management решения могут иногда детектировать. НО VM вендор должен приложить к этому дополнительные усилия. Большая часть правил детекта уязвимостей работают за счет проверки установки патчей или проверки версий ПО/пакетов. Раз обновления устраняющего уязвимость пока нет, значит требуется детектировать как-то иначе. Например попытаться проэксплуатировать уязвимость. Разработка таких правил это ручная работа, требующая больших усилий.
2. Непубличные уязвимости, о которых кто-то знает и возможно использует, но о которых не знает вендор ПО (например, #EternalBlue до утечки из NSA). Такие уязвимости вероятно могут находиться в некоторых непубличных базах уязвимостей. Обнаружить такие уязвимости при помощи VM решения невозможно. С обнаружением эксплуатации таких уязвимостей в какой-то степени могут помочь EDR решения и практики SOC.
3. Непубличные уязвимости, о которых вообще никто не знает. VM решение также не сможет продетектировать такие уязвимости. Это уже из области исследования ПО и SAST/DAST/IAST решений.

Так могут ли VM решения детектировать Zero Day уязвимости? Да, могут детектировать определенные Zero Day уязвимости в некоторых исключительных случаях. Это будет обычное сканирование на уязвимости и затем фильтрация по признаку "у уязвимости нет патча". Но обнаруженные таким образу уязвимости будут лишь малой частью от всех Zero Day уязвимостей (в том смысле как мы их определили выше). VM решения заточены на работу с известными уязвимости для которых вендором уже выпущены патчи. Именно такие уязвимости (а не Zero Day!) обычно и являются основной причиной взлома компаний. Zero Day уязвимости применяются все же довольно редко и в основном в таргетированных атаках.