CVSS 3.1: как оценить критичность уязвимости

Зачем хантеру CVSS

В CTF всё просто: флаг либо есть, либо нет. В багбаунти найти уязвимость — только половина дела. Размер выплаты часто зависит от того, насколько критичной признают находку. В отчёте мы предлагаем оценку, которую затем проверяет триаж. Завысим оценку — её понизят, а к следующим нашим отчётам станут относиться с меньшим доверием. Занизим — рискуем получить меньше, чем заслуживает находка.

На двух крупных российских площадках, Standoff 365 и BI.ZONE Bug Bounty, для этого используется система оценки CVSS.

CVSS (Common Vulnerability Scoring System) — это международный открытый стандарт оценки критичности уязвимостей в программном и аппаратном обеспечении.

Первая версия стандарта появилась в 2005 году, а сейчас есть уже четвёртая — CVSS 4.0. Версии 3.0 и 3.1 по-прежнему встречаются в отчётах. Вот как выглядит встроенный калькулятор BI.ZONE Bug Bounty:

На скриншоте калькулятор подставляет в вектор версию 3.0. Названия базовых метрик совпадают, но в 3.1 уточнили определения и изменили отдельные правила расчёта. Если программа принимает CVSS 3.1, пересчитайте вектор в калькуляторе этой версии. Формат и версию лучше сверить с правилами конкретной программы. Калькулятор CVSS 3.1 от FIRST.

В этой статье мы разберём, из каких метрик складывается оценка CVSS 3.1, посчитаем её для шести типовых уязвимостей, соберём частые ошибки и на двух отчётах посмотрим, как их исправить.

За что отвечают метрики

Базовая оценка CVSS 3.1 складывается из восьми метрик. Для удобства разделим их на две группы:

Как атакуют

AV – Вектор атаки

Метрика AV (Attack Vector, вектор атаки) показывает, откуда злоумышленник может проэксплуатировать найденную уязвимость. Чем дальше от цели он может при этом находиться, тем выше будет итоговая оценка.

Так, значение N (Network) означает, что атака возможна по сети без требования находиться в соседнем сегменте. A (Adjacent) означает, что атака ограничена общей или логически смежной сетью, L (Local) — что требуется локальный доступ к системе, а P (Physical) — физический доступ к устройству. Поскольку в багбаунти мы часто работаем с веб-приложениями, доступными из интернета, в наших отчётах эта метрика обычно принимает значение N.

AC – Сложность атаки

Метрика AC (Attack Complexity, сложность атаки) отвечает на вопрос, нужны ли для успешной атаки особые условия, которые от нас не зависят.

Значение L (Low) ставится, когда особых условий нет и атака даёт повторяемый результат. Значение H (High) выбирается, когда успех зависит от обстоятельств вне нашего контроля: например, от состояния гонки или положения между клиентом и сервером.

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

PR – Привилегии

Метрика PR (Privileges Required, требуемые привилегии) показывает, какие права нужны нам в системе до начала атаки.

Значение N (None) означает, что атаку можно провести вообще без наличия учётной записи, L (Low) – что достаточно прав обычного пользователя, а H (High) – что требуются права администратора или другой привилегированной роли.

Здесь встречается одна из самых частых ошибок: если для эксплуатации нужны права обычного пользователя приложения, многие всё равно ставят N, ведь регистрация открыта для всех. В этом примере требуемые привилегии есть, поэтому выбираем L.

UI – Действие жертвы

Метрика UI (User Interaction, взаимодействие с пользователем) отвечает на вопрос, должен ли кто-то, кроме нас самих, совершить действие, чтобы атака сработала.

Значение N (None) ставится, когда участие других людей не требуется, а R (Required) – когда жертва должна что-то сделать: перейти по ссылке, открыть страницу или нажать на кнопку.

Так, для большинства XSS и CSRF эта метрика будет принимать значение R, а для IDOR или SQL-инъекции – N.

Что ломается

S – Scope

Метрика S (Scope, область воздействия) показывает, пересекают ли последствия границу полномочий уязвимого компонента.

Значение U (Unchanged) означает, что последствия остаются в пределах той же области полномочий. При C (Changed) страдает компонент, доступ к которому регулируется отдельной областью полномочий.

Классический пример изменённой области — XSS. Уязвимость находится в веб-приложении, а воздействие происходит в браузере пользователя. При SQL-инъекции область часто остаётся неизменной, если последствия ограничены данными и полномочиями приложения.

Последние три метрики описывают влияние на конфиденциальность, целостность и доступность — так называемую триаду CIA.

C – Конфиденциальность

Метрика C (Confidentiality, конфиденциальность) показывает, к каким данным мы получаем доступ.

Значение H (High) ставится, когда читается всё или самое важное, например пароли и персональные данные всех пользователей, L (Low) — когда доступна лишь какая-то определенная часть информации, а N (None) — когда данные не раскрываются вовсе.

При этом стоит оценивать последствия, которые можно обосновать в отчёте.

I – Целостность

Метрика I (Integrity, целостность) устроена аналогично, но говорит уже не о чтении, а об изменении данных.

Значение H означает, что мы можем менять любые данные приложения, L – что изменения ограничены, а N – что повлиять на данные нельзя.

Удаление чужих записей тоже относится именно к этой метрике.

A – Доступность

Наконец, метрика A (Availability, доступность) показывает, можем ли мы нарушить работу самого сервиса.

Значение H ставится, когда приложение удаётся сделать полностью недоступным, L – когда оно начинает работать с перебоями или некоторой задержкой при ответе, а N – когда на работоспособность мы не влияем.

Важно помнить, что речь идет о самом сервисе, а не о данных в нём. Если мы удалили записи, но сайт продолжает открываться и успешно работать, то его доступность не пострадала.

По значениям восьми базовых метрик рассчитывается балл от 0 до 10. Уровни критичности: None (0,0), Low (0,1–3,9), Medium (4,0–6,9), High (7,0–8,9) и Critical (9,0–10,0). Базовый балл описывает свойства уязвимости. Оценка риска дополнительно учитывает, где и как используется система.

Разбор на примерах

Для начинающего багхантера одним из наиболее важных умений будет объективная, а главное, правильная оценка собственных находок. Одну и ту же уязвимость можно оценить по-разному в зависимости от контекста и программы, в которой она была найдена.

Reflected XSS

Начнём с классического примера. Веб-приложение небезопасно отображает поисковый запрос, и код может выполниться в браузере пользователя при открытии страницы.

Аккаунт для такой атаки нам не нужен, поэтому PR принимает значение N, а вот без действия жертвы не обойтись, поэтому UI — R. Самая интересная метрика здесь — Scope. Уязвимость находится в веб-приложении, но страдает от неё браузер пользователя, то есть другой компонент, поэтому ставим C.

Конфиденциальность и целостность оцениваются как L: скрипт может прочитать и изменить только то, что доступно жертве на этой странице, полного контроля над данными приложения мы не получаем. На доступность атака не влияет.

В итоге получаем 6,1 — уровень Medium.

Stored XSS

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

Вектор отличается от предыдущего всего одной метрикой. Чтобы оставить комментарий, нам нужна учётная запись, поэтому PR меняется с N на L, а оценка снижается до 5,4.

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

В CVSS 4.0 метрику взаимодействия с пользователем разделили на пассивное и активное. Обычный просмотр страницы с сохранённым содержимым — пример пассивного взаимодействия. Подробнее об этом поговорим во второй части.

В этом примере 5,4 соответствует ограниченному влиянию на данные. Если обосновано высокое влияние на конфиденциальность и целостность при тех же условиях, балл вырастает до 8,7. При высоком влиянии ещё и на доступность оценка достигает 9,0.

Одна и та же уязвимость может получить от Medium до Critical, и разница определяется тем, что мы смогли доказать.

IDOR

Перейдём к уязвимостям контроля доступа. Допустим, личный кабинет интернет-магазина показывает пользователю чужой заказ с именем, телефоном и адресом покупателя.

Для атаки нужен собственный аккаунт (PR — L), а участие жертвы не требуется (UI — N). Всё происходит внутри одного приложения, поэтому Scope остаётся U.

Спорной здесь будет конфиденциальность. Если таким образом раскрываются персональные данные любого пользователя и последствия серьёзные, ставим H и получаем 6,5. Если раскрывается лишь одно некритичное поле, например никнейм, подходящим значением будет L, а оценка составит 4,3. Если уязвимость также позволяет произвольно изменять эти данные, целостность может получить I:H, и балл вырастет до 8,1, уровня High.

CSRF

При CSRF приложение принимает запрос из браузера авторизованного пользователя без подтверждения его намерения. Допустим, последствия ограничиваются изменением некритичной настройки уведомлений.

Здесь часто путаются с привилегиями. Жертва должна быть авторизована, но нам самим учётная запись не нужна, поэтому PR — N, а вот действие жертвы необходимо, значит UI — R.

Влияние оценивается по последствиям запроса. Смена некритичной настройки — это I:L и итоговые 4,3. В официальных примерах FIRST CSRF с полным контролем над приложением оценён в 8,8.

Цепочка: path traversal + CSRF

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

Руководство CVSS предлагает рассчитывать общий вектор цепочки с учётом наименее строгих условий и самых серьёзных последствий, обоснованных для этой цепочки.

В нашем примере нужен аккаунт (PR — L) и действие администратора (UI — R), а в результате мы получаем доступ к данным и на чтение, и на изменение (C и I — H). Итог — 7,3 и уровень High. В отчёте при этом стоит привести и оценку каждой уязвимости по отдельности.

SQL-инъекция без аутентификации

Рассмотрим уязвимость с максимальными значениями почти по всем метрикам.

В этом сценарии уязвимость позволяет читать и менять любые данные приложения, а также нарушить работу самого сервиса.

Аккаунт не нужен, действие жертвы не требуется, а конфиденциальность, целостность и доступность оцениваются как H. В итоге получаем 9,8 Critical.

Тут стоит обратить внимание на Scope. В этом сценарии последствия ограничены областью полномочий приложения, поэтому Scope остаётся неизменным, даже если затронута база данных.

Частые ошибки

Мы уже разобрали метрики и примеры, а теперь соберём в одном месте ошибки, которые встречаются в отчётах чаще всего.

• Scope Changed. Значение Changed ставится, когда воздействие выходит за границу полномочий уязвимого компонента. Если эта граница сохраняется, выбираем Unchanged.
• PR:N при открытой регистрации. Если уязвимость требует обычных пользовательских прав, для этого сценария подходит PR:L.
• Теоретические последствия. Обычно оценивается то, что показано в отчёте. Если мы продемонстрировали только выполнение скрипта, то писать о захвате аккаунта администратора и ставить High по всем метрикам нельзя.
• AC:H за необходимость знать идентификатор. Само по себе знание номера не повышает сложность по CVSS. Значение High остаётся для случаев, когда успех зависит от особых условий вне нашего контроля.
• A:H за удаление данных. Удалённые или испорченные записи относятся к целостности. Доступность оцениваем отдельно, по влиянию на работу самого сервиса.
• Одна оценка на всю цепочку. Если уязвимостей несколько, стоит привести вектор каждой из них и отдельно вектор цепочки.
• Только число без вектора. Оценка вида «CVSS 9» ничего не объясняет: триаж не видит, в какой метрике мы ошиблись, и пересчитывает всё сам. В отчёте всегда нужен полный вектор.

Как оформить оценку в отчёте

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

Но и одного только вектора тоже будет недостаточно. Триаж/вендор видит только итоговую строку и не знает, почему мы выбрали именно эти значения. Поэтому рядом с вектором стоит коротко объяснить хотя бы спорные метрики. Как правило, это Scope, привилегии и влияние на данные.

Объяснять все восемь метрик не обязательно: значения вроде AV:N для веб-приложения очевидны. Обычно будет вполне достаточно одной строки на каждую метрику, которая может вызвать вопросы. Выглядеть это может так:

Критичность: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N — 6.5 (Medium)

• PR:L — для атаки нужна учётная запись обычного пользователя.
• S:U — данные читаются в пределах того же приложения.
• C:H — доступны ФИО, телефон и адрес любого клиента.

Исправляем ошибки

Чтобы закрепить все эти знания, разберём два отчёта с неверной оценкой. В первом критичность завышена, во втором — занижена.

Отчёт А. Stored XSS в комментариях

Stored XSS в комментариях к товару

Описание. Сохранённое содержимое комментария выполняется в браузерах посетителей страницы товара.

Что показано. Комментарий может оставить авторизованный пользователь. Воздействие наблюдается при просмотре страницы.

Заявленный импакт. В отчёте предполагается полный контроль над магазином.

Критичность. CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — 10.0 Critical

Что не так

В этом отчёте сразу три ошибки.

Во-первых, чтобы оставить комментарий, нужно войти в аккаунт, а значит, PR уже будет L, а не N.

Во-вторых, скрипт сработает только тогда, когда кто-то откроет страницу товара, поэтому UI — R.

В-третьих, заявленный полный контроль в отчёте не обоснован. В этом сценарии подтверждено ограниченное влияние на конфиденциальность и целостность. Выбираем C:L, I:L и A:N.

После исправления оценка падает с 10,0 до 5,4. Для более высокой оценки в отчёте нужно обосновать более серьёзные последствия.

Возможна и другая ситуация. Если сохранённое содержимое видит только сам автор, например на странице собственного профиля, то другие пользователи не затронуты. Такой случай называют self-XSS, и многие программы указывают его в списке исключений.

Отчёт Б. IDOR на чужие заказы

Просмотр чужих заказов

Описание. API заказов не проверяет, что заказ принадлежит текущему пользователю.

Что показано. Пользователь с обычными правами видит ФИО, телефон и адрес доставки другого клиента.

Заявленный импакт. Автор отчёта считает, что доступ к персональным данным ограничен необходимостью знать номер заказа.

Критичность. CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N — 3.5 Low

Что не так

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

В этом примере особых условий вне контроля атакующего нет, поэтому AC — L.

Scope указан как изменённый, хотя данные читаются внутри того же приложения.

И конфиденциальность оценена как L, хотя раскрываются ФИО, телефон и адрес любого клиента магазина, а это уже солидный набор персональных данных (ПДн), то есть H.

В результате оценка вырастает с 3,5 до 6,5, то есть с уровня Low до Medium. Автор отчёта сам недооценил свою находку, и если триаж/вендор не станет пересчитывать вектор, то выплата может оказаться ниже заслуженной.

Шпаргалка

Для удобства собрал типовые векторы из этой статьи в одну шпаргалку:

Итоги

Подведём итоги. Оценка по CVSS — полноценная часть отчёта, от которой зачастую зависит результат. Обосновывайте последствия, объясняйте спорные метрики и проверяйте, не ошиблись ли вы в большую или меньшую сторону.

Всё сказанное относится к версии 3.1. Уже существует CVSS 4.0, и некоторые программы дают выбор между версиями. Во второй части мы пересчитаем те же самые уязвимости по новой версии и посмотрим, как изменятся их оценки.