Руслан Рахметов, Security Vision
Несмотря на то, что непрерывная эволюция киберугроз приводит к изменению техник и инструментария для атак, год за годом основные методы злоумышленников остаются прежними – это использование вредоносного ПО, социальная инженерия (фишинг), а также эксплуатация уязвимостей в популярном ПО. Количество уязвимостей растет непрерывно и нелинейно, а их учет осложнены необходимостью перепроверки сведений и участием в работе многих заинтересованных лиц. При управлении уязвимостями в компании важно выстроить соответствующий процесс, в котором должен присутствовать источник достоверной информации об уязвимостях и методах их устранения. О таком источнике мы поговорим сегодня – речь идет о базе уязвимостей информационной безопасности CVE.
CVE (Common Vulnerabilities and Exposures, дословно «Общие уязвимости и подверженности воздействию») – это система (реестр, база) учета и классификации уязвимостей. Первая запись в ней появилась в сентябре 1999 года, а к концу 2000 года в ней уже была информация почти о двух тысячах уязвимостей. Со временем скорость разработки ПО возросла вместе с востребованностью автоматизации и информационных технологий, поэтому объем кодовой базы во всем мире непрерывно рос, а вместе с ним росло и число уязвимостей. Так, по итогам 2005 года в реестр CVE были добавлены почти 7 тысяч уязвимостей, по итогам 2017 года – 14 с половиной тысяч, а в 2024 году были добавлены уже целых 40 тысяч. В результате, на сегодняшний день в базе CVE содержатся более 270 тысяч записей об известных уязвимостях. Работа с таким большим объемом информации требует значительных ресурсов, поэтому реестр CVE, начинавшийся как исследовательский проект корпорации MITRE, со временем начал получать финансирование от различных американских государственных учреждений, а сейчас спонсируется Агентством по кибербезопасности и защите инфраструктуры США (Cybersecurity and Infrastructure Security Agency, CISA). При этом работа над учетом уязвимостей предполагает международное сотрудничество – записи в реестр вносят CNA-организации (CVE Numbering Authorities, уполномоченные организации по присвоению уязвимостям уникальных идентификаторов) со всего мира. Сейчас в списке CNA-организаций присутствуют уже 447 партнеров из 40 стран мира, но в 2016 году их было всего 24, а в 2020 году – 144. В списке CNA-организаций Россия представлена компаниями Kaspersky и Yandex. Структура организаций, участвующих в работе системы CVE, состоит из управляющего комитета (CVE Board), в который входят эксперты из различных коммерческих компаний, исследовательских учреждений и объединений, рабочих групп и секретариата под управлением MITRE. При этом ключевую роль в работе реестра CVE играют организации типа TL-Root (Top-Level Root, верхнеуровневая корневая организация) – это корпорация MITRE и агентство CISA, которое в структуре CVE является также единственным ADP (Authorized Data Publisher, авторизованный публикатор данных). Организации типа TL-Root подчиняются управляющему комитету CVE и имеют полномочия по управлению иерархией подчиненных CNA-организаций в своей зоне ответственности. Организация типа ADP обладает полномочиями по обогащению CVE-записей об уязвимостях, но при этом не может изменять исходные данные, сообщенные об уязвимости CNA-партнером. В структуре работы системы CVE также присутствуют CNA-организации типа CNA-LR (CVE Numbering Authority of Last Resort, CNA «на крайний случай»), к которым можно обратиться в случае, если не удалось найти подходящую CNA-организацию, принимающую сообщения об обнаруженных уязвимостях – партнерами типа CNA-LR являются CISA (для уязвимостей в системах АСУТП и медицинском оборудовании) и MITRE (для всех типов уязвимостей, включая уязвимости в продуктах Open Source).
При этом работа с реестром CVE для исследователей, которые ищут уязвимости, выстроена следующим образом:
1. После обнаружения уязвимости лицо или организация обращаются к партнеру реестра CVE.
2. Партнером CVE может быть организация типа CNA или CNA-LR – это могут быть компании-разработчики ПО, компании в области исследований уязвимостей, разработчики Open Source решений, группы CERT (группы реагирования на компьютерные инциденты), провайдеры облачных услуг, провайдеры программ Bug Bounty или консорциум организаций.
3. Для регистрации номера уязвимости в реестре CVE следует ознакомиться с политикой разглашения данных CNA-организации, которой будет направлено обращение, а её контактные данные можно взять из общего перечня партнеров. При этом CNA-партнеры следуют установленным правилам, а для того, чтобы стать партнером CVE, следует выполнять ряд условий и подать заявку.
4. После получения информации от исследователя, CNA-организация резервирует определенный идентификатор CVE ID и начинает процесс проверки информации, сообщенной исследователем. Идентификатор CVE ID представляет из себя запись вида CVE-YYYY-NNNNNNN, где YYYY - год обнаружения уязвимости, а NNNNNNN - её порядковый номер.
5. Если информация об уязвимости подтверждается, то запись о ней публикуется CNA-организацией в общем реестре CVE.
Рассмотрим в качестве примера запись об уязвимости с идентификатором CVE-2025-1316:
1. На странице уязвимости присутствует текстовое описание уязвимости, а также указана ссылка на описание в формате JSON, которое содержит более подробную информацию.
2. В верхней части страницы можно увидеть дату публикации информации об уязвимости и краткое описание (в IP-камере модели Edimax IC-7100 обнаружена уязвимость удаленного исполнения кода из-за отсутствия очистки входящих запросов), а также название CNA-организации, которая внесла эту информацию в реестр CVE.
3. Указаны метрики по системе CVSS (Common Vulnerability Scoring System, общая система скоринга уязвимостей) версий 4.0 и 3.1 с декомпозицией векторов (например, признак AV:N указывает на то, что уязвимость можно проэксплуатировать удаленно, AC:L – что сложность атаки низкая, а PR:N – что никаких привилегий для атаки не потребуется).
4. В нижнем блоке карточки уязвимости указана информация от ADP-организации CISA, которая внесла данную уязвимость в список KEV (Known Exploited Vulnerabilities, список эксплуатируемых уязвимостей в реальных атаках), а также классифицировала уязвимость по методике SSVC (Stakeholder-Specific Vulnerability Categorization, категоризация уязвимости по негативному влиянию на бизнес).
5. Кроме того, на странице уязвимости присутствует ссылка на запись в каталоге MITRE CWE (Common Weakness Enumeration, общий классификатор недостатков), в которой описана корневая причина возникновения рассматриваемой уязвимости – в данном случае, это CWE-78 «Некорректная нейтрализация специальных символов при передаче команд операционной системе» («Инъекция команд ОС»).
На классификатор CWE стоит обратить внимание - именно в нём ведется учет ошибок, обычно допускаемых при разработке программного и аппаратного обеспечения, которые в итоге приводят к возникновению уязвимостей. Кроме описания самой ошибки с примерами, в CWE-реестре поддерживается иерархия, которая помогает понять природу различных типов распространенных ошибок - например, указанная CWE-78 («Инъекция команд ОС») является дочерней для CWE-77 («Инъекция команд»), которая в свою очередь является дочерней для более общего типа ошибок с идентификаторами CWE-74 («Инъекция») и CWE-707 («Некорректная нейтрализация»). Кроме того, по итогам года проект MITRE CWE формирует список наиболее опасных ошибок "CWE Top 25".
Еще один проект MITRE, связанный с CVE и CWE – это реестр CAPEC (Common Attack Pattern Enumeration and Classification, общая система перечисления и классификации шаблонов атак). CAPEC – это база знаний о методах эксплуатации недостатков ПО (по реестру CWE) и уязвимостей (по реестру CVE). Например, уже описанная выше ошибка типа CWE-78 («Инъекция команд ОС») может быть проэксплуатирована за счет атаки типа CAPEC-88 («Инъекция команд ОС»), для которой описана последовательность шагов, выполняемых злоумышленником для реализации атаки (Explore – Experiment – Exploit). Более того, для некоторых шаблонов из реестра CAPEC приведена связь с матрицей MITRE ATT&CK, описывающей тактики, техники и процедуры атакующих. Например, для CAPEC-21 («Эксплуатация доверенных идентификаторов») указана связь с техниками T1134 («Манипуляция токеном доступа»), T1528 («Кража токена доступа приложения»), T1539 («Кража куки-файлов веб-сессии»).