На проверке Уязвимость нулевого дня: жизненный цикл, реальные CVE и процесс патчинга

[Сергей Попов]

75 zero-day за 2024 год по данным GTIG. 44% атак - на корпоративные технологии, рекордный показатель. Time-to-exploit после публикации CVE (n-day) сжался до 5 дней - в 2018–2019 было около 32, по данным Mandiant M-Trends. А среднее время развёртывания патча в организациях - от 60 до 150 дней (GTIG). IBM X-Force Threat Intelligence Index 2025 добивает ещё одной цифрой: 29 месяцев - среднее время между публикацией CVE и фактическим устранением в организации. Двадцать девять. Месяцев. Ниже - разбор жизненного цикла уязвимости нулевого дня на конкретных CVE с CVSS-векторами, маппингом на MITRE ATT&CK и практическим чеклистом для исследователя.

Жизненный цикл уязвимости нулевого дня: шесть этапов от бага до боевого эксплойта​

Жизненный цикл уязвимости нулевого дня - не линейная последовательность «нашли → починили». На каждом этапе действуют разные участники, и каждый этап создаёт отдельное окно риска.

Этап 1. Внесение ошибки (Introduction). Баг появляется в коде в момент написания функции, подключения зависимости или изменения конфигурации. На этом этапе уязвимость не известна никому, включая автора кода. CWE помогает категоризировать типы таких ошибок: CWE-287 (Improper Authentication), CWE-798 (Use of Hard-coded Credentials), CWE-502 (Deserialization of Untrusted Data), CWE-400 (Uncontrolled Resource Consumption). Казалось бы - разные классы, но все они регулярно всплывают в enterprise-продуктах.

Этап 2. Обнаружение (Discovery). Уязвимость находит исследователь, автоматизированный сканер или злоумышленник. Методы: реверс бинарного кода в Ghidra или IDA Pro, фаззинг (AFL, libFuzzer), статический анализ исходного кода (SAST), patch diffing через BinDiff для сравнения версий до и после обновления. На стороне атакующих - техника Vulnerability Scanning (T1595.002, Reconnaissance) по MITRE ATT&CK. Решение, принятое на этом этапе - раскрыть, продать или эксплуатировать - определяет весь дальнейший жизненный цикл уязвимости.

Этап 3. Вооружение (Weaponization). Из бага собирают рабочий эксплойт: proof-of-concept, затем боевой payload. Атакующие тестируют его против разных версий ПО и защитных решений, добавляют обфускацию для обхода песочниц и антивирусов. В терминах MITRE ATT&CK - Exploits (T1587.004, Resource Development) при разработке собственных эксплойтов, или Exploits (T1588.005, Resource Development) при покупке готовых на рынке.

Этап 4. Эксплуатация (Exploitation). Zero-day эксплойт применяется против реальных целей. В зависимости от вектора:

• Exploit Public-Facing Application (T1190, Initial Access) - атака на внешний сервис или API
• Exploitation for Client Execution (T1203, Execution) - доставка через вредоносный документ или ссылку
• Exploitation for Privilege Escalation (T1068, Privilege Escalation) - повышение привилегий внутри уже скомпрометированной системы

По данным Mandiant M-Trends 2025, эксплойты составляют 38% всех расследованных initial access векторов - наиболее распространённый способ первичного проникновения пятый год подряд.

Этап 5. Раскрытие и патч (Disclosure & Patch). Вендор узнаёт об уязвимости - через responsible disclosure, CERT/CC или из отчётов об инцидентах. Начинается разработка патча. Стандартное окно координированного раскрытия - 90 дней (политика Google Project Zero, с 30-дневным grace period для сложных случаев). При подтверждённой эксплуатации in the wild - ускоренный 7-дневный таймлайн.

Этап 6. Развёртывание патча (Deployment). Патч выпущен, но это не конец. В организациях - тестирование совместимости, согласование maintenance window, каскадный rollout. Всё это время эксплуатация нулевого дня продолжается: уязвимость перешла из категории 0-day в категорию n-day.

Zero-day примеры: CVE-2026-20127 и CVE-2026-22769 под микроскопом​

Два свежих примера zero-day атак, оба - в каталоге CISA Known Exploited Vulnerabilities (KEV), оба получили решение SSVC: Act (критично, патчить немедленно).

CVE-2026-20127: обход аутентификации Cisco Catalyst SD-WAN​

Уязвимость в механизме peering-аутентификации Cisco Catalyst SD-WAN Controller (ранее vSmart), Cisco Catalyst SD-WAN Manager (ранее vManage) и Cisco Catalyst SD-WAN Validator (ранее vBond). Неаутентифицированный удалённый атакующий обходит аутентификацию и получает административные привилегии на затронутой системе. Без каких-либо учётных данных.

CVSS: 10.0 (CRITICAL). Вектор: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Разбор вектора по компонентам:

• AV:N - атака через сеть, без физического доступа
• AC:L - низкая сложность, специальных условий не требуется
• PR:N - не нужны учётные данные
• UI:N - действие пользователя не требуется
• S:C - атака выходит за пределы уязвимого компонента
• C:H/I:H/A:H - полная компрометация конфиденциальности, целостности и доступности

Короче: всё на максимум. Зайти можно по сети, без пароля, без взаимодействия пользователя, и ломается не только сам контроллер, но и всё, до чего он дотягивается.

CWE: CWE-287 (Improper Authentication). Этот класс ошибок входит в OWASP A07:2021 (Identification and Authentication Failures).

EPSS: 0.8824, 99.75-й перцентиль (Top 1% среди всех CVE в базе FIRST.org). Вероятность эксплуатации в ближайшие 30 дней - экстремально высокая.

SSVC: exploitation - active, automatable - yes, technical impact - total.

Место в kill chain: Exploit Public-Facing Application (T1190, Initial Access). SD-WAN контроллер - сетевой компонент, торчащий в интернет. Получив административный доступ, атакующий контролирует маршрутизацию трафика всей SD-WAN-сети. Дальше - lateral movement, перехват данных, добавление rogue peers для устойчивого присутствия.

CVE-2026-22769: hardcoded credentials в Dell RecoverPoint for Virtual Machines​

Уязвимость в Dell RecoverPoint for Virtual Machines (версии до 6.0.3.1 HF1) - вшитые учётные данные (hardcoded credentials). Неаутентифицированный удалённый атакующий, знающий эти credentials, получает доступ к ОС и root-уровень persistence.

Вектор: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

CVSS: 10.0 (CRITICAL). Обе уязвимости позволяют полную компрометацию без аутентификации.

CWE: CWE-798 (Use of Hard-coded Credentials). Казалось бы, 2026 год на дворе - а вшитые пароли в enterprise-продуктах всё ещё живут. Системы резервного копирования, IoT-устройства, appliance-решения - одни и те же грабли.

EPSS: 0.1312, 95.95-й перцентиль (Top 5%). Разница с CVE-2026-20127 (EPSS 0.8824) показательна: при одинаковом CVSS 10.0 модель EPSS учитывает доступность эксплойта, распространённость продукта и активность обсуждений на underground-площадках. Один и тот же CVSS - разный уровень реальной опасности.

Рекомендованное действие: «Apply mitigations per vendor instructions or discontinue use of the product if mitigations are unavailable».

SSVC: exploitation - active, automatable - yes, technical impact - total.

Место в kill chain: Exploit Public-Facing Application (T1190, Initial Access). Вшитые credentials обеспечивают persistent доступ, не зависящий от ротации паролей пользователями. Для системы резервного копирования это означает доступ к бэкапам всех виртуальных машин - полная компрометация данных организации.

Общий паттерн: инфраструктура вместо приложений​

Оба кейса вписываются в тренд, который GTIG фиксирует с 2023 года: атаки смещаются с пользовательских приложений (браузеры, офисные пакеты) на инфраструктурные компоненты. По данным GTIG за 2025 год, значительная доля enterprise-targeted zero-day была направлена на security и networking продукты - edge-устройства (роутеры, коммутаторы, firewall-аплайнсы).

Проблема для защитников: edge-устройства и инфраструктурные appliance не покрываются endpoint-решениями. Ни CrowdStrike Falcon, ни SentinelOne, ни Elastic Defend не мониторят firmware SD-WAN контроллеров или appliance-based систем типа Dell RecoverPoint. Обнаружение компрометации возможно только на уровне сетевого мониторинга - аномалии трафика, неожиданные peering-сессии, подключения к C2-серверам. EDR тут слеп.

0-day эксплойт vs n-day: реальная угроза в цифрах​

В русскоязычных материалах почти не встречается чёткое разграничение между 0-day и n-day уязвимостями. А на практике именно n-day создают бо́льшую операционную угрозу для большинства организаций.

Параметр	0-day	n-day	1-day
Патч доступен	Нет	Да	Да (первый день)
Сигнатура детекции	Нет	Да	Частично
Типичная стоимость эксплуатации	Высокая	Низкая (публичные PoC)	Средняя
Основная угроза	APT, коммерческий шпионаж	Массовые атаки, ransomware	Гонка атакующий vs patch management

Ключевой разрыв: 5 дней до создания эксплойта после публикации CVE против 60–150 дней до развёртывания патча. Каждая раскрытая уязвимость нулевого дня превращается в n-day, которая остаётся эксплуатируемой в большинстве инфраструктур месяцами. По данным Google Project Zero (отчёт по 0-days in-the-wild за 2022 год), значительная доля zero-day in the wild - варианты ранее закрытых уязвимостей, переработанные под непропатченные версии ПО. То есть атакующие берут старый баг, смотрят, как его закрыли, и ищут обход. Патч как документация для эксплойта.

По данным Verizon DBIR 2025, медианный выкуп ransomware составляет $46,000, а максимальный зафиксированный - $75M в единичном инциденте. CrowdStrike Global Threat Report 2025 отмечает, что 86% атак в 2024 году имели финансовую мотивацию (eCrime). Патч нулевого дня, выпущенный вендором, становится бесполезным, если организация не способна развернуть его быстрее, чем атакующие напишут эксплойт.

Классификация zero-day по CWE: типы ошибок, которые чаще эксплуатируются​

Не все баги превращаются в 0-day одинаково. CWE (Common Weakness Enumeration) группирует уязвимости по типу ошибки и позволяет увидеть системные паттерны - какие классы ошибок чаще всего фигурируют в zero-day атаках.

CWE-287 (Improper Authentication) - некорректная реализация аутентификации. Входит в OWASP A07:2021 (Identification and Authentication Failures), часто приводит к полному обходу аутентификации. Обнаружение: фаззинг аутентификационных endpoint'ов, ревью логики проверки токенов и сессий.

CWE-798 (Use of Hard-coded Credentials) - вшитые учётные данные в коде или конфигурации. Ошибка, которую стыдно допускать - но она регулярно появляется в enterprise-продуктах. Patch diffing для таких уязвимостей наиболее прямолинеен: diff покажет удаление или замену hardcoded строки.

CWE-502 (Deserialization of Untrusted Data) - десериализация недоверенных данных. Классический вектор для Remote Code Execution. Примеры: CVE-2015-4852 (Apache Commons Collections в WebLogic, CVSS 9.8 CRITICAL) и CVE-2017-9805 (Apache Struts 2 REST Plugin, CVSS 8.1 HIGH). Log4Shell (CVE-2021-44228) классифицирован по нескольким CWE (CWE-20, CWE-400, CWE-502, CWE-917) - композитный характер уязвимости: JNDI lookup, десериализация и injection в одном флаконе. Поиск: ревью точек десериализации пользовательского ввода (JSON, XML, Java-сериализация).

CWE-400 (Uncontrolled Resource Consumption) - неконтролируемое потребление ресурсов. Используется для DoS-атак на критическую инфраструктуру. Менее «громкий» класс, чем RCE, но для промышленных систем отказ в обслуживании может быть не менее разрушительным - остановка конвейера обходится дороже, чем утечка данных.

Системный анализ CWE-классов позволяет приоритизировать фаззинг и code review: если в кодовой базе есть самописные аутентификационные модули, точки десериализации или конфигурационные файлы с credentials - это первые кандидаты на проверку.

Процесс патчинга уязвимостей нулевого дня: от disclosure до production​

Responsible disclosure: 90 дней, 7 дней и дебаты вокруг сроков​

Координированное раскрытие (responsible disclosure) определяет, сколько времени вендор получает на разработку патча до публикации деталей уязвимости.

Google Project Zero использует 90-дневное окно с 30-дневным grace period для сложных исправлений. Для уязвимостей с подтверждённой эксплуатацией in the wild - 7 дней. Trend Zero Day Initiative (ZDI) и CERT/CC поддерживают собственные таймлайны. Индустрия де-факто пришла к двухуровневой модели: 7 дней при активной эксплуатации, 90 дней - стандартный цикл.

При текущем time-to-exploit в 5 дней даже 90-дневное окно может быть избыточно щедрым к вендору. С другой стороны, преждевременное раскрытие без готового патча превращает уязвимость в оружие для всех, а не только для первоначального атакующего. Баланс тут хрупкий.

Патч нулевого дня: пошаговый процесс​

1. Получение уведомления. Вендор получает отчёт - через bug bounty (HackerOne, Bugcrowd), CERT или напрямую от исследователя. Первый шаг: воспроизведение на внутреннем стенде.
2. Разработка и тестирование. Исправление кода, регрессионное тестирование. Для enterprise-продуктов (Cisco IOS XE, Dell firmware) - проверка совместимости с десятками аппаратных платформ. Тут и теряются недели.
3. Advisory и CVE. Публикация идентификатора, описания, CVSS-скора, затронутых версий и рекомендованных действий (патч, workaround, вывод из эксплуатации).
4. Развёртывание в организациях. Получатели патча запускают собственный цикл: тестирование → staging → production. Для федеральных агентств США сроки определяет CISA - 2–3 дня при active exploitation (как в случаях CVE-2026-20127 и CVE-2026-22769).
5. Верификация и мониторинг IoC. Проверка, что патч установлен на всех затронутых системах. Параллельно - поиск индикаторов компрометации для выявления проникновения, произошедшего до патчинга. Этот шаг пропускают чаще всего - а зря.

Когда патча нет: временные меры​

Не каждый вендор выпускает патч в разумные сроки. Иногда продукт уже End-of-Life. CISA в таких случаях прямо рекомендует: «discontinue use of the product if mitigations are unavailable». Звучит радикально, но выбор между «выключить» и «ждать, пока сломают» - не самый сложный.

Временные меры до выхода патча нулевого дня:

• Micro-segmentation - изоляция уязвимого компонента на уровне сети
• ACL для management-интерфейсов - ограничение доступа по IP
• Network-level мониторинг (NetFlow, PCAP) - поиск аномального трафика
• Virtual patching через WAF или IPS - блокировка известных паттернов эксплуатации

Обнаружение уязвимостей нулевого дня: инструменты и практический чеклист​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Последние два года я наблюдаю устойчивую проблему: организации приоритизируют патчинг по CVSS, а не по EPSS. CVSS 10.0 звучит максимально страшно - но если EPSS этого CVE равен 0.001, а рядом лежит CVE с CVSS 7.5 и EPSS 0.95, реальная угроза - второй. Переход от severity-based к likelihood-based приоритизации - то, что должно произойти в ближайшие пару лет. Но пока этому мешает инерция compliance-фреймворков, заточенных под CVSS. Аудиторы хотят видеть «все критикалы закрыты», а не «мы закрыли по EPSS-приоритету» - и это тормозит всю индустрию.

Commercial surveillance vendors (CSV) остаются одними из крупнейших потребителей zero-day эксплойтов. По данным GTIG за 2024 год, nation-state актёры и CSV - ключевые потребители zero-day, и разрыв между ними продолжает сокращаться. Рынок шпионского ПО стал крупнейшим потребителем 0-day. Для исследователя уязвимостей это меняет модель угроз: на стороне атакующего теперь не только разведки крупных государств, но и коммерческие компании с ресурсами на масштабную разработку эксплойтов.

Процесс патчинга уязвимостей - гонка, которую организации системно проигрывают. Mandiant фиксирует exploits как вектор номер один пятый год подряд, CISA вынуждена выпускать Emergency Directives с двухдневными дедлайнами, а корпоративный patch management оперирует в тайм-фреймах месяцев. Единственный способ сократить разрыв - перестать относиться к управлению уязвимостями как к compliance-упражнению и начать использовать EPSS + KEV как операционный приоритизатор. Если хочется отработать анализ уязвимостей и написание эксплойтов на практике - задачи по reverse и web на HackerLab позволяют пройти путь от поиска бага до PoC без подсказок.