Расширенный

Расширенный поиск

Автор

Статьи

Общий обзор систем оценки уязвимостей (CVSS 2.0/3.0)

21.08.2018
В статье представлен обзор систем оценки уязвимостей Common Vulnerability Scoring System (CVSS) версий 2.0 и 3.0.

Содержание:

Введение

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

Актив – это все, что имеет ценность для организации, то есть все, что нужно защитить – люди, информация, материальные ресурсы...

Угроза – это совокупность условий и факторов, создающих потенциальную или реально существующую опасность нарушения безопасности информации. Чаще всего рассматривают угрозы конфиденциальности, целостности и доступности информации.

Уязвимость – это недостаток программы, который может быть использован для реализации угроз безопасности информации.

Например, для приложения, оперирующего банковскими переводами пользователей, активом (защищаемой информацией) будет список транзакций, угрозой – возможность чтения этого списка другими пользователями, а уязвимостью может стать отсутствие проверки привилегий и возможность увидеть список транзакций другого пользователя, изменив URL. При этом эксплуатация уязвимостей может иметь разные последствия – тяжелые и не очень. Один из подходов ранжирования и приоритезации обработки уязвимостей – это оценка их опасности. Существует несколько систем такой оценки, у каждой есть свои плюсы и минусы, и на текущий момент индустриальным стандартом является Common Vulnerability Scoring System (CVSS), поддержкой которого занимается международная группа Forum of Incident Response and Security (FIRST), в которую входят более 400 членов.

23 февраля 2005 года был опубликован отчет исследовательской группы NIAC и обнародована первая версия CVSS - общей системы оценки уязвимостей. Эта рейтинговая система должна была обеспечить открытые и универсальные стандартизированные оценки опасности уязвимостей программного обеспечения. Развитию этого стандарта способствовали крупные ИТ-компании, однако, поскольку первая версия изначально не подвергалась тщательному анализу со стороны множества организаций из разных отраслей, в ней были обнаружены значительные недостатки. Основным недостатком CVSS было признано малое число оценочных критериев – существовало много уязвимостей с одинаковой оценкой. Поэтому была собрана международная открытая группа CVSS-SIG, задачей которой было выявить и исправить все подобные недостатки.

1 июня 2007 года была опубликована вторая версия CVSS, получившая широкое распространение. Уже в сентябре эта версия была закреплена в стандарте безопасности данных платежных карт PCI DSS. Чтобы соответствовать требованиям PCI DSS, операторы платежных систем, обрабатывающие кредитные карты, должны продемонстрировать, что ни одна из их вычислительных систем не имеет уязвимости с общей оценкой CVSS, большей или равной 4.0. В 2007 году Национальный институт стандартов и технологий США (NIST) включил CVSS v2.0 в свой протокол автоматизации безопасности SCAP. В апреле 2011 года CVSS 2.0 был официально принят в качестве международного стандарта для оценки уязвимостей (ITU-T X.1521)

CVSS 2.0

Оценка уязвимостей по системе CVSS 2.0 производится на основе трех метрик: базовой, временной и контекстной. Каждая метрика представляет из себя оценку от 0 до 10 баллов и короткое текстовое описание, содержащее всю необходимую информацию для вывода этой оценки.


Рисунок 1: Общая система оценки уязвимостей CVSS

В стандарте CVSS группы метрик определяются следующим образом:

  1. Базовая группа метрик отражает «неотъемлемые и фундаментальные характеристики уязвимости, которые являются постоянными с течением времени и пользовательскими средами».
  2. Временная группа метрик отражает «характеристики уязвимости, которые меняются со временем, но не среди пользовательских сред».
  3. Контекстная группа метрик отражает «характеристики уязвимости, которые являются релевантными и уникальными для конкретной среды пользователя».

Базовая группа метрик включает в себя шесть метрик. Первые три – способ получения доступа (Access Vector), сложность получения доступа (Access Complexity), показатель аутентификации (Authentication) – призваны помочь получить представление о трудностях, связанных с атакой.

  • Способ получения доступа может быть локальным (Local) и удаленным через смежную (Adjacent) или глобальную (Network) сеть, при этом чем более удаленным от атакуемой цели может быть злоумышленник, тем выше будет базовая оценка.
  • Сложность атаки может быть высокой (High), средней (Mid) и низкой (Low). Предполагается, что у атакующего уже есть готовый эксплойт, и под «сложностью» подразумевается сложность его использования. Если для успешной эксплуатации требуется лишь запустить программу, то очевидно, что сложность будет низкая. Однако иногда злоумышленнику приходится прибегать к дополнительным действиям. Например, если он намерен провести фишинг-атаку (атаку, при которой жертва переходит по ложной ссылке и самостоятельно вводит конфиденциальную информацию на ресурсе злоумышленника, визуально похожем на основной ресурс), то он может использовать метод социальной инженерии, и в таком случае сложность эксплуатации считается средней. Однако социальная инженерия не всегда приводит к успеху, поэтому злоумышленник может прибегнуть к перехвату DNS, атаковав DNS-сервер. Тогда сложность эксплуатации будет высокой. Чем ниже сложность, тем выше числовая оценка базовой группы.
  • Показатель аутентификации отражает сложности для атаки, связанные с необходимостью предоставления злоумышленником учетных данных. В модели CVSS аутентификация может вовсе не требоваться (None), требоваться один (Single) или множество (Multiple) раз. При этом, если уязвимость обнаружена в самой системе аутентификации, то считается, что аутентификация не требуется. Если требуется аутентификация для доступа в локальную сеть, из которой доступно уязвимое приложение, а в самом приложении аутентификация не требуется, то считается, что для эксплуатации уязвимости аутентификация не требуется.

Следующие три метрики базовой группы – влияние на конфиденциальность, влияние на целостность и влияние на доступность – определяют возможные последствия эксплуатации уязвимости. В каждой из этих метрик влияние может не оказываться (None), оказываться частично (Partial) и быть полным (Complete). Влияние на актив считается частичным, если оно может быть ограничено (например, нарушена конфиденциальность/целостность только определенной части файлов или прерывается доступность лишь некоторых компонент системы). Если к системе есть физический доступ или доступ с root-правами, то она считается полностью скомпрометированной.

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

На примере уязвимости Heartbleed (CVE-2014-0160) проведем оценку базовой группы метрик. Эта уязвимость является следствием ошибки в пакете OpenSSL (ошибка чтения за пределы аллоцированной памяти) и позволяет извлечь произвольные данные из оперативной памяти сервера. Для проведения атаки злоумышленнику нужно отправить специальным образом сформированный запрос на атакуемый сервер. То есть, злоумышленнику достаточно доступа из глобальной сети (Access Vector: Network). Сложность атаки сводится к запуску готового эксплойта (Access Complexity: Low). Аутентификация при этом не требуется (Authentication: None). Получение приватного ключа сервера означает частичную потерю конфиденциальности (Confidentiality Impact: Partial). Так как прочитать не загруженные в оперативную память данные не получится, на целостности и доступности потеря конфиденциальности никак не скажется (Integrity Impact: None, Availability Impact: None). Такой результат публикуется в виде сокращенного вектора (AV: N/AC: L/Au: N/C: P/I: N/A: N). Подставив значения из этого вектора в базовое уравнение, получаем числовую оценку 5.0 для исследуемой уязвимости.

Второй пример – уязвимость Shellshock, позволяющая удаленно производить выполнение команд при определенных значения переменных окружения вопреки задекларированным возможностям. В данном случае доступ также возможен по сети и для эксплуатации требуется лишь запуск эксплойта без аутентификации. Однако выполнение команд дает возможность нарушить не только конфиденциальность данных (прочитать файлы), но и их целостность (перезаписать файлы) и доступность (например, выключить сервер). Тогда мы получим итоговый вектор (AV: N/AC: L/Au: N/C: P/I: C/A: C) и оценку 10.0, ведь все показатели принимают наихудшие значения. Очевидно, что если в системе существуют обе уязвимости, то важнее сначала исправить вторую уязвимость, и базовая оценка позволяет это понять.

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

Временная группа включает три метрики:

  • Возможность использования (Exploitability) уязвимости отражает состояние методов эксплуатации и доступность кода. Различают стадию теоретического существования эксплойта (Unproven), стадию существования концепции эксплуатации (Proof Of Concept) – когда можно провести демонстрацию, но на большинстве реальных приложений она не сработает, стадию существования сценария (Functional) – когда доступен код эксплойта и он работает в большинстве случаев без изменений, и стадию высокой (High) опасности, если эксплойт доступен и работает автономно на множестве устройств. Итоговая числовая оценка временной группы тем выше, чем проще использовать уязвимость.
  • Уровень исправления (Remediation Level) отражает состояние обработки уязвимости. При этом различают стадию, когда никакое решение недоступно (Unavailable), а также стадии существования рекомендаций (Workaround), временного решения (Temporary) и официального исправления (Official Fix).
  • Степень достоверности источника (Report Confidence), сообщившего об уязвимости – она может быть не подтверждена (Unconfirmed), не доказана (Uncorroborated) и подтверждена (Confirmed) вендором ПО.

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

В качестве примера проведем оценку временной группы для Heartbleed: на текущий момент доступны соответствующий эксплойт и официальный патч для уязвимой библиотеки, также известно, что уязвимость подтверждена. Тогда получаем вектор (E: H/RL: OF/RC: C) и оценку 4.4. Отметим, что оценка отлична от нуля даже после выпуска официального исправления, поскольку многие пользователи могли не применить его.

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

  • Вероятность нанесения косвенного ущерба (Collateral Damage Potential) отражает насколько сильно могут пострадать активы, не связанные с уязвимым приложением. Эта вероятность может быть низкой (Low), средне-низкой (Low-Medium), средне-высокой (Medium-High) и высокой (High).
  • Плотность целей (Target Distribution) отражает насколько сильно пострадает система в целом от эксплуатации уязвимости. Плотность целей может быть низкой, средней или высокой.
  • Требования к конфиденциальности (Confidentiality requirements), требования к целостности (Integrity requirements) и требования к доступности (Availability requirements) - могут быть низкими, средними или высокими. Это определяется требованиями, предъявляемыми к уязвимой системе.


Рисунок 2: Оценка по CVSS

CVSS 3.0

К сожалению, версия CVSS 2.0 тоже оказалась не идеальной, в ней осталась проблема недостаточной информативности оценки, в данном стандарте также появлялись уязвимости с одинаковыми векторами, но с разной оценкой опасности. В FIRST (организацию, поддерживающую стандарт) было отправлено открытое письмо из Open Security Foundation, в котором дополнительно отмечались следующие проблемы:

  • некоторые показатели CVSS трактуются неоднозначно – на разных ресурсах в базах уязвимостей, предоставляющих оценки CVSS 2.0, можно найти идентичные уязвимости, для которых указаны различные сложности эксплуатации;
  • многие компании (Oracle, IBM, HP, Cisco) вместе с оценкой CVSS 2.0 начали использовать свои более информативные оценки или выставлять числовую оценку не в соответствии со стандартом;
  • отсутствие качественной шкалы оценки и, как следствие, разная трактовка числовой оценки разными пользователями.

Рабочая группа CVSS-SIG начала работу над третьей версией стандарта, и в июне 2015 года она была опубликована. В нее были внесены следующие изменения:

  1. Добавлен физический уровень доступа, подразумевающий доступ к аппаратному обеспечению системы.
  2. Исключен средний уровень сложности эксплуатации – если для эксплуатации требуется выполнение специальных условий, неподконтрольных атакующему, или для выполнения которых потребуются проводить дополнительные атаки, то сложность эксплуатации считается высокой. В остальных случаях – низкой. Отдельным показателем вынесено взаимодействие с пользователем (User Interaction: None/Required).
  3. Аутентификация заменена на оценку уровня привилегий (показатель Privileges Required) – этот уровень может быть высоким, низким или отсутствовать. Последнее значение эквивалентно отсутствию аутентификации, низкий уровень соответствует аутентификации с правами обычного пользователя, а высокий – с правами администратора. Данное изменение обусловлено тем, что число аутентификаций отражает сложность эксплуатации менее выразительно, чем качественная сложность каждой аутентификации (получить права администратора сложно, аутентифицироваться десять раз с правами обычного пользователя обычно не сложнее, чем сделать это один раз).
  4. Скорректированы коэффициенты в уравнениях – оценка стала меньше зависеть от сложности эксплуатации и больше от причиняемого воздействия.
  5. Введено понятие цепочки уязвимостей. Иногда эксплуатация нескольких уязвимостей единовременно несет гораздо большую опасность, чем каждая из уязвимостей отдельно.
  6. Метрики воздействия из количественных перешли в качественные. Вместо частичного и полного влияния на конфиденциальность, целостность и доступность оценивается еше и критичность той части системы, на которую было проведено воздействие, в терминах среднего (Medium) и сильного (High) воздействия.
  7. Введены понятия атакуемого и уязвимого компонента, границ эксплуатации. Иногда уязвимость, найденная в одной системе, влияет на другую, не связанную с ней. В CVSS 3.0 предлагается учитывать максимальное воздействие в каждом показателе и дополнительно повышать оценку опасности, если область действия атаки была изменена. Для этого добавлен показатель смены границы эксплуатации (Scope: Changed/Unchanged).

Два последних пункта из списка изменений заслуживают отдельного внимания. Чтобы продемонстрировать актуальность положений пункта 6, рассчитаем базовую метрику для уязвимости CVE-2018-4871. Уязвимость заключается в чтении за границами буфера в Adobe Flash Player и позволяет прочитать приватную информацию с ПК пользователя, доступную уязвимому приложению (по умолчанию – недоступно ничего). С позиций CVSS 2.0 эта уязвимость имеет точно такие же характеристики, как и Heartbleed. Однако утечка приватного ключа сервера позволяет расшифровать весь трафик, который когда-либо приходил на сервер от кого угодно. Поэтому сохранение конфиденциальности приватного ключа сервера гораздо важнее защиты информации на ПК. В CVSS 3.0 показатель конфиденциальности у Heartbleed признается высоким, а у только что описанной уязвимости – средним, итоговые оценки 7.3 и 5.3 соответственно.

Важность седьмого пункта можно продемонстрировать на примере CVE-2012-1516. Для эксплуатации этой уязвимости достаточно лишь запустить эксплойт (AC: L) на удаленной машине (AV: N), один раз авторизовавшись с правами обычного пользователя (AU: S – в CVSS v2.0 или PR: L в CVSS v3.0) в гостевой операционной системе. Взаимодействие с пользователем в процессе эксплуатации не требуется (UI: N). Уязвимым компонентом являются средства виртуализации, обеспечивающие работу гостевой операционной системы, однако эксплуатация данной уязвимости приводит к выполнению кода на основной, хостовой ОС, то есть, в итоге атакуется другой компонент (S: C). Выполнение кода на основной ОС потенциально открывает злоумышленнику намного больше возможностей, например, доступ к приложениям хостовой ОС, недоступным по сети. Возможность исполнения произвольного кода приводит к полной компрометации, потере целостности и доступности (C: C/I: C/A: C или C: H/I: H/A) основной ОС. Подставив CVSS 2.0 вектор (AV: N/AC: L/Au: S/C: C/I: C/A: C) в уравнение из стандарта получим оценку 9.0. В CVSS 3.0 вектор данной уязвимости (AV: N/AC: L/Pr: L/UI: N/S: C/C: H/I: H/A: H) и после подстановки получаем оценку 9.9. При этом похожий вектор уязвимости (AV: N/AC: L/Pr: L/UI: N/S: U/C: H/I: H/A: H) после подстановки получает оценку лишь 8.8. У этих векторов отличается лишь показатель смены границы эксплуатации – благодаря нему CVSS 3.0 позволяет адекватно отразить резкое увеличение опасности именно за счет атаки других компонентов.

Выводы

Идеальную систему оценки уязвимостей создать скорее всего невозможно. Даже в актуальной версии стандарта CVSS 3.0 могут быть неоднозначные трактовки, например, при определении важности приватной информации. Однако, использование любой версии CVSS в большинстве случаев позволяет правильно расставить приоритеты в обработке уязвимостей и оценить возможные риски. Самую детальную оценку позволяет проводить последняя версия стандарта. Но если в организации уже существует большая база с оценками, выполненными по предыдущей версии CVSS, то переход на более современную версию может оказаться слишком трудозатратным и не принести нужного результата.

Авторы:
Павел Ханин, разработчик систем безопасности ООО "СолидСофт",
Денис Гамаюнов, к.ф.-м.н., с.н.с. кафедры Информационной безопасности факультета ВМК МГУ.