Common Vulnerability Scoring System

Common Vulnerability Scoring System (CVSS) — открытый стандарт, используемый для расчета количественных оценок уязвимости в безопасности компьютерной системы, обычно с целью понять приоритет её исправления.

Оценки рассчитываются по специальным формулам на основе нескольких метрик и приблизительно оценивают простоту внедрения эксплойта и его влияние на компьютерную систему. Результатом расчета являются три числовые оценки (Base Score, Temporal Score и Environmental Score), каждая из которых может принимать значение от 0 до 10, где 10 выражает максимальную опасность.

Последней версией стандарта является 3.1, выпущенная в июне 2019 года. По разным соображениям одни компании используют старую версию стандарта CVSSv2, другие новую CVSSv3, а третьи совмещают использование разных версий.

История

Исследования, проводимые в 2003—2004 годах Национальным Консультативным Советом по Инфраструктуре (англ. National Infrastructure Advisory Council, NIAC), привели к появлению в феврале 2005 года первой версии CVSS. Первоначальной целью было получение открытых и универсальных методов оценки серьёзности уязвимостей в программном обеспечении. В апреле 2005 NIAC запустила сайт Forum of Incident Response and Security Teams (сокр. FIRST), на котором была опубликована первая версия стандарта.

Первая версия стандарта не подвергалась экспертной оценке сторонних организаций, поэтому реальные отзывы компаний, специализировавшихся на разработке программного обеспечения и пытавшихся его использовать, обнажили многие серьёзные проблемы, в связи с чем в июне 2007 вышла вторая версия стандарта. Дальнейшее развитие привело к выходу третьей версии стандарта в июне 2015.

Основные моменты

CVSS пытается оценить уязвимость с разных сторон:

1. Качественная оценка уязвимости, которая не зависит ни от времени, ни от программного окружения, выражаемая через базовые метрики (Base metrics):
   1. Access Vector (AV) показывает каким путём уязвимость может быть внедрена.
   2. Access Complexity (AC) показывает насколько легко или сложно использовать данную уязвимость.
   3. Authentication (Au) оценивает количество аутентификаций, которые атакующий должен произвести прежде чем воспользоваться уязвимостью.
   4. Влияние уязвимости на компьютерную систему (Impact metrics):
      1. Confidentiality (C) описывает влияние на конфиденциальность данных, обрабатываемых системой.
      2. Integrity (I) описывает влияние на целостность данных компьютерной системы.
      3. Availability (A) описывает влияние уязвимости на доступность компьютерной системы. Например атаки, которые влияют на пропускную способность сети или занимающие процессорное время, влияют на доступность системы.
2. Временны́е метрики (Temporal metrics), учитывающие реакцию производителя уязвимого продукта, которые изменяются с момента обнаружения уязвимости и до момента её исправления:
   1. Exploitability (E) показывает текущее состояние способов эксплуатации уязвимости, в том числе автоматизированных.
   2. Remediation Level (RL) является корректирующим числом, позволяющим смягчать временную оценку по мере того, как становятся доступны исправления для уязвимости.
   3. Report confidence (RC) позволяет измерить уровень уверенности в существовании уязвимости и достоверности её технических данных.
3. Метрики уязвимости, учитывающие конкретные требования безопасности к системе, в которой работает уязвимый продукт (Environmental metrics):
   1. Collateral Damage Potential (CDP) оценивает потенциальный ущерб для компании от данной уязвимости, например потенциальный убыток, физический ущерб оборудованию и т. п.
   2. Target Distribution (TD) оценивает долю уязвимых систем в компьютерной сети.
   3. Impact Subscore Modifier включает в себя корректирующие числа confidentiality (CR), integrity (IR) и availability (AR), позволяющие скорректировать Impact metrics и конечную оценку под конкретные требования безопасности конкретного окружения.

Метрики для расчета берутся из таблиц, в которых приводится их описание, качественное и количественное значения. Ниже в таблице приведены метрики, введенные со второй версии стандарта.

Сводная таблица с метриками CVSSv2

Оценка	Метрика	Описание
Base Score	Access Vector (AV)	Качественное выражение Количественное выражение Пояснение Local (L) 0,395 Атакующий должен иметь физический доступ к системе, либо иметь локальную учётную запись Adjacent Network (A) 0,646 Атакующий должен иметь доступ к широковещательному каналу или к домену коллизий Network (N) 1 Уязвимый интерфейс работает на сетевом уровне или более верхнем уровне модели OSI
	Access Complexity (AC)	High (H) 0,35 Существуют некоторые особые условия для проведения атаки, например состояние гонки в системе, или выполняются некоторые требования социальной инженерии, которые могут быть подмечены знающим специалистом Medium (M) 0,61 Существуют некоторые дополнительные требования для атаки, например определяется конкретный источник атаки или есть требование специальной конфигурации для атакуемой системы, отличной от стандартной Low (L) 0,71 Не существует особых требований для использования уязвимости
	Authentication (Au)	Multiple (M) 0,45 Для использования уязвимости атакующий должен аутентифицироваться не менее двух раз, даже если используются одни и те же учётные данные Single (S) 0,56 Для использования уязвимости атакующий должен аутентифицироваться один раз None (N) 0,704 Для использования уязвимости аутентификация не нужна
	Confidentiality (C)	None (N) 0 Нет влияния на конфиденциальность системы Partial (P) 0,275 Широко раскрывается только отдельный ограниченный объём данных Complete (C) 0,660 Полное раскрытие всех данных системы
	Integrity (I)	None (N) 0 Нет влияния на целостность системы Partial (P) 0,275 Объем изменяемых данных системы четко ограничен Complete (C) 0,660 Атакующий может изменять любые данные системы
	Availability (A)	None (N) 0 Нет влияния на доступность системы Partial (P) 0,275 Наблюдается частичное снижение производительности Complete (C) 0,660 Полная потеря атакованного ресурса
Temporal Score	Exploitability (E)	Unproven (U) 0,85 Код эксплойта недоступен, либо эксплойт является теоретическим Proof-of-concept (P) 0,9 Доступен демонстрационный код эксплойта, но он не универсален и покрывает только один или несколько частных случаев Functional (F) 0,95 Доступен код эксплойта и он работает в большинстве ситуаций, где присутствует уязвимость High (H) 1,0 Доступен код эксплойта и он может внедряться в систему автоматизированным способом, например в форме червя или вируса Not Defined (ND) 1,0 Игнорировать эту метрику
	Remediation Level (RL)	Official Fix (O) 0,87 Доступно полное решение устранения уязвимости от поставщика либо в виде обновления, либо в виде патча Temporary Fix (T) 0,90 У поставщика есть временное решение, частично смягчающее негативные последствия от уязвимости Workaround (W) 0,95 Доступно неофициальное решение или средство защиты от сторонних разработчиков Unavailable (U) 1,0 Доступного решения нет, либо предложенное решение невозможно применить. Обычно уязвимость пребывает в этом состоянии сразу после обнаружения Not Defined (ND) 1,0 Игнорировать эту метрику
	Report Confidence (RC)	Unconfirmed (UC) 0,9 Один неподтвержденный источник, либо несколько источников, но не описывающих уязвимость более-менее одинаково. В том числе и слухи об уязвимости Uncorroborated (UR) 0,95 Несколько источников, которые в целом описывают уязвимость одинаково. Допустимы небольшие разногласия Confirmed (C) 1,0 Уязвимость подтверждена и поставщиком и производителем затронутого продукта Not Defined (ND) 1,0 Игнорировать эту метрику
Environmental Score	Collateral Damage Potential (CDP)	None (N) 0 Уязвимость не несет никаких потерь для бизнеса Low (L) 0,1 Незначительная потеря доходов или производительности системы Low-Medium (LM) 0,3 Умеренный ущерб Medium-High (MH) 0,4 Значительный ущерб High (H) 0,5 Катастрофический ущерб Not Defined (ND) 0 Игнорировать эту метрику
	Target Distribution (TD)	None (N) 0 Целевых систем не существует, либо они существуют в лабораторных условиях Low (L) 0,25 1-25 % затрагиваемой системы Medium (M) 0,75 26-75 % затрагиваемой системы High (H) 1,0 76-100 % затрагиваемой системы Not Defined (ND) 1,0 Игнорировать эту метрику
	Impact Subscore Modifier	Low (L) 0,5 Потеря (конфиденциальности (CR) / целостности (IR) / доступности (AR)), вероятно, будет иметь лишь ограниченное влияние на организацию Medium (M) 1,0 Потеря (конфиденциальности (CR) / целостности (IR) / доступности (AR)) может серьёзно повлиять на организацию High (H) 1,51 Потеря (конфиденциальности (CR) / целостности (IR) / доступности (AR)) может иметь катастрофические последствия для организации Not Defined (ND) 1,0 Игнорировать эту метрику

Формулы для расчета в CVSSv2

Оценка ${\textsf {BaseScore}}$ рассчитывается по следующим формулам. Значения для параметров выбираются из таблицы, приведенной выше. Дробные результирующие числа следует округлять до первого десятичного разряда, что ниже выражается через функцию ${\textsf {roundTo1Decimal}}$.

${\textsf {Exploitability}}=20\times {\textsf {AccessVector}}\times {\textsf {AccessComplexity}}\times {\textsf {Authentication}}$

${\textsf {Impact}}=10{,}41\times (1-(1-{\textsf {C}})\times (1-{\textsf {I}})\times (1-{\textsf {A}}))$

$f({\textsf {Impact}})={\begin{cases}0,&{\text{if }}{\textsf {Impact}}{\text{ = 0}}\\1{,}176,&{\text{otherwise }}\end{cases}}$

${\textsf {BaseScore}}={\textsf {roundTo1Decimal}}(((0{,}6\times {\textsf {Impact}}) (0{,}4\times {\textsf {Exploitability}})-1{,}5)\times f({\textsf {Impact}}))$

Для расчета ${\textsf {TemporalScrore}}$ используются следующие формулы.

${\textsf {TemporalScore}}={\textsf {roundTo1Decimal}}({\textsf {BaseScore}}\times {\textsf {Exploitability}}\times {\textsf {RemediationLevel}}\times {\textsf {ReportConfidence}})$

Для расчета ${\textsf {EnvironmentalScore}}$ используется следующие формулы. ${\textsf {AdjustedTemporal}}$ рассчитывается по той же формуле, что и ${\textsf {TemporalScore}}$, но вместо ${\textsf {BaseScore}}$ нужно подставить ${\textsf {AdjustedImpact}}$.

${\textsf {AdjustedImpact}}=\min(10,10{,}41\times (1-(1-{\textsf {C}}\times {\textsf {CR}})\times (1-{\textsf {I}}\times {\textsf {IR}})\times (1-{\textsf {A}}\times {\textsf {AR}})))$

${\textsf {EnvironmentalScore}}={\textsf {roundTo1Decimal}}(({\textsf {AdjustedTemporal}} (10-{\textsf {AdjustedTemporal}})\times {\textsf {CollateralDamagePotential}})\times {\textsf {TargetDistribution}})$

Пример

В 2002 году в серверном приложении Apache была выявлена уязвимость CVE-2002-0392, приводившая к повреждению памяти сервера при фрагментированном кодировании запросов для него. Зная это, злоумышленник может создать успешный эксплойт, способный в одних случаях привести к отказу сервера в обслуживании, а в других — к выполнению произвольного кода с привилегиями серверного приложения.

Используя CVSS метрики для расчета базовой оценки, проблему можно описать так:

• AV равняется N, так как запрос формируется удаленно на прикладном уровне модели OSI.
• AC равняется L, потому что для успешной работы эксплойта достаточно сформировать особый запрос для сервера и никаких особых требований со стороны сервера не требуется.
• Au равняется N, потому что сервер обработает этот запрос без аутентификации клиента.
• Поскольку конечный результат эксплуатации уязвимости зависит от самого запроса, то следует принимать во внимание только самый вероятный случай использования уязвимости. За такой случай можно принять исполнение произвольного кода злоумышленника для извлечения данных из базы данных сервера, например получения данных аутентификации других клиентов. В этом случае параметрам C и I следует присвоить значение P (Partial). Также, вероятно злоумышленник будет использовать эксплойт, чтобы вывести сервер из строя, тогда A следует присвоить значение С (Complete). В этом примере мы будем предполагать второй вариант использования, поэтому C и I мы присвоим N (None), а параметру A мы присвоим значение C.

Таким образом, параметры для расчета базовой оценки можно выразить следующей текстовой строкой, на практике называемой вектором: AV:N/AC:L/Au:N/C:N/I:N/A:C

Так как Apache Foundation подтвердил уязвимость для 1.3 и 2.0 версий сервера, то для Temporal Score вектор будет таким: E:F/RL:O/RC:C

Вектор для Environmental Score зависит от того, что для использующей сервер Apache компании важнее и какие у неё мощности. Для данного примера пусть вектор будет таким: CDP:H/TD:H/CR:M/IR:M/AR:H

Подставив количественные значения показателей из таблицы, получим следующие результаты.

${\textsf {Exploitability}}=20\times 1\times 0{,}71\times 0{,}704=10{,}0$

${\textsf {Impact}}=10{,}41\times (1-(1-0)\times (1-0)\times (1-0{,}66))=6{,}9$

$f(6{,}9)=1{,}176$

${\textsf {BaseScore}}=(0{,}6\times 6{,}9 0{,}4\times 10{,}0-1{,}5)\times 1{,}176=7{,}8$

${\textsf {TemporalScore}}=7{,}8\times 0{,}95\times 0{,}87\times 1=6{,}4$

${\textsf {AdjustedImpact}}=\min(10,10{,}41\times (1-(1-0\times 1)\times (1-(1-0\times 1)\times (1-(1-0{,}66\times 1{,}51)))=10$

${\textsf {AdjustedTemporal}}=10\times 0{,}95\times 0{,}87\times 1=8{,}3$

${\textsf {AdjustedBaseScore}}=(0{,}6\times 10 0{,}4\times 10{,}0-1{,}5)\times 1{,}176=10$

${\textsf {EnvironmentalScore}}=(8{,}3 (10-8{,}3)\times 0{,}5)\times 1{,}0=9{,}2$

Учитывая такие большие оценки для данной уязвимости, мы должны как можно скорее обновить наши серверы Apache, как минимум до версии 2.1.

Критика и сравнение версий стандарта

Несколько поставщиков программного обеспечения оказались недовольными CVSSv2:

• Компания Risk Based Security, которая управляет базой Open Sourced Vulnerability Database, и Open Security Foundation выразили своё недовольство стандартом в открытом письме к FIRST. В частности авторы указали на недостаточную детализацию в нескольких метриках, что не даёт должным образом различать уязвимости разных типов и профилей риска. Также было отмечено, что система оценок требует слишком глубоких знаний о влиянии уязвимости на систему.
• Компания Oracle предложила ещё один уровень для показателей Confidentiality, Integrity и Availability — Partial , — чтобы закрыть большой разрыв между значениями Partial и Complete.

Чтобы устранить некоторые из этих критических замечаний, в 2012 году началась разработка стандарта CVSSv3, окончательная версия которого была выпущена в июне 2015 года. Было изменено, добавлено и удалено несколько показателей и немного поправлены формулы при сохранении диапазона оценки от 0 до 10.

Основные отличия CVSSv3 от CVSSv2 следующие:

• Для базовой оценки были добавлены новые метрики (UI (взаимодействие с пользователем), PR (требуемые привилегии)), чтобы помочь в различении уязвимостей, связанных с привилегиями простого пользователя и администратора.
• В векторе базовой оценки была добавлена метрика S (Scope), чтобы отличать уязвимости, которые могут быть сначала внедрены, а потом использованы для атаки на другие части системы или сети.
• Метрики Confidentiality, Integrity и Availability в третьей версии имеют другие градации: None, Low и High, вместо None, Partial и Complete.
• Метрика Access Complexity была переименована в Attack Complexity, чтобы показать, что требования к правам доступа были перенесены в отдельную метрику.
• В метрику Access Vector было добавлено значение Physical (P), чтобы показать, что для использования уязвимости требуется физический доступ к оборудованию.
• Полностью изменены все метрики для Environmental Score, чтобы более точно описывать требования к безопасности системы. Были добавлены метрики отражающие важность конфиденциальности, целостности и доступности.

В июне 2019 года была выпущена версия 3.1. Данная версия не вносит новых изменений в стандарт, а лишь детализирует описание некоторых метрик для лучшего их понимания.

Применение

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

• National Vulnerability Database
• Open Source Vulnerability Database
• Координационный центр CERT

Примеры уязвимостей со счётом 10,0

CVE-2024-30510

Злонамеренный пользователь билетной системы Salon может записать на веб-сервер файл вредоносного типа, чтобы попытаться найти «дыру» в системе обработки, или в дальнейшем его исполнить, если веб-сервер позволяет.

CVE-2024-30247

Из-за неверной конфигурации веб-панели небольшого дистрибутива для встраиваемых систем NextCloudPi кто угодно может выполнять команды консоли от имени администратора.

CVE-2024-3094

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

Основная статья: Бэкдор в XZ

Ссылки

• The Forum of Incident Response and Security Teams (FIRST) CVSS site