Что такое уязвимость: слабое место, угроза, риск и эксплойт

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

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

Лаборатория здесь не нужна. Практическая часть делается на бумаге. Если сначала прочитать статью о триаде CIA, шаг про последствия покажется знакомым.

#Четыре слова, четыре роли

Начнём с официального определения. Глоссарий NIST Computer Security Resource Center определяет уязвимость как слабое место в информационной системе, её процедурах безопасности, внутренних механизмах контроля или реализации, которое может быть использовано или задействовано источником угрозы. Главное слово здесь «слабое место». Уязвимость — это свойство системы. Она существует независимо от того, ищет её кто-нибудь или нет.

#Уязвимость

Уязвимость — это слабое место, через которое можно причинить вред. Несколько примеров:

• Веб-форма, которая вставляет пользовательский ввод прямо в запрос к базе данных. Этот тип слабого места хорошо известен, и в CWE для него есть запись (подробнее ниже).
• Файловый сервер, который всё ещё принимает старый слабый протокол шифрования.
• Хранилище (bucket), содержимое которого может просмотреть любой желающий.
• Версия программной библиотеки с публично задокументированной ошибкой повреждения памяти.

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

#Угроза

Угроза — это обстоятельство, действующее лицо или событие, которое может воспользоваться слабым местом и причинить вред. NIST использует термин «источник угрозы» (threat source) для стороны или события: преступная группа, злонамеренный инсайдер, наводнение или администратор, допустивший ошибку в конфигурационном файле.

Отличие от уязвимости в направлении. Уязвимость описывает то, на что можно воздействовать. Угроза описывает то, что может воздействовать. Угроза потенциальна. Чтобы она имела значение, ей не обязательно быть направленной против вас прямо сейчас.

#Риск

Риск сочетает вероятность вредного события и тяжесть его последствий. NIST SP 800-30 Revision 1, руководство по оценке рисков, рассматривает риск как функцию вероятности и воздействия. Проще говоря, риск показывает, насколько вероятно событие и какой ущерб оно нанесёт, если случится. Это суждение, точным расчётом его не назовёшь.

Многие команды рисуют матрицу: вероятность по одной оси, воздействие по другой. Матрица помогает думать, но ничего не измеряет. Две находки с одинаковой оценкой критичности могут нести очень разный риск, потому что оценка описывает дефект, а риск описывает вашу среду.

#Эксплойт

Эксплойт — это метод, фрагмент кода или последовательность шагов, которые используют уязвимость и получают результат, не предусмотренный разработчиками. Этим словом называют и сам приём, и инструмент, который его выполняет.

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

#Как связаны эти четыре понятия

Эти четыре слова описывают одну цепочку. Вот она по порядку на примере обычной формы входа:

1. Слабое место. Форма входа принимает неограниченное число попыток угадать пароль. Нет ни блокировки, ни лимита запросов. Это уязвимость.
2. Источник угрозы. У кого-то есть список паролей из старой утечки, и он пробует их на множестве аккаунтов. Это угроза.
3. Эксплойт. Короткий скрипт отправляет тысячи попыток входа и записывает удачные. Этот скрипт и есть эксплойт.
4. Воздействие. Подходящий аккаунт захвачен. Атакующий читает данные этого пользователя (потеря конфиденциальности) и может изменить настройки (потеря целостности).
5. Риск. Насколько это важно, зависит от двух вещей: насколько вероятны шаги 2 и 3 в ваших условиях и насколько тяжёлым будет шаг 4 для затронутых аккаунтов. Доступна ли форма из интернета? Используют ли аккаунты многофакторную аутентификацию? К чему имеет доступ каждый аккаунт?

Цепочку можно разорвать в нескольких местах. Лимит запросов убирает слабое место. Многофакторная аутентификация сильно снижает пользу от удачно подобранного пароля. Если ограничить форму частной сетью, угрозе будет труднее до неё дотянуться. Каждая мера защиты разрывает своё звено, поэтому нужно понимать, с каким звеном вы работаете.

#Как CWE и CVE называют дефекты

Два идентификатора постоянно встречаются в новостях по безопасности, advisories и отчётах сканеров. Они отвечают на разные вопросы, и путать их — одна из самых частых ошибок новичков.

#CWE: тип слабого места

На сайте CWE он описан как составляемый сообществом список распространённых слабых мест в программном и аппаратном обеспечении. Слабое место там определено как условие в программном, микропрограммном, аппаратном или сервисном компоненте, которое при определённых обстоятельствах может способствовать появлению уязвимостей. CWE отвечает на вопрос: что это за ошибка по своему типу?

У каждой записи CWE есть номер. SQL-инъекции соответствует запись CWE-89, она описывает неправильную нейтрализацию специальных элементов в SQL-команде. Межсайтовому скриптингу соответствует CWE-79. Эти записи не называют никаких продуктов. Они описывают шаблон, который встречается во множестве продуктов, и помогают разработчикам распознать его до выпуска.

#CVE: конкретный дефект

CVE — это список публично раскрытых уязвимостей. Каждая запись описывает один дефект в одном продукте, обычно с указанием затронутых версий и ссылками на advisories. Идентификатор выглядит так:

CVE-YEAR-NUMBER

Реальный пример: CVE-2021-44228, дефект в Apache Log4j 2, получивший известность как Log4Shell. Идентификатор говорит, какой это дефект. Запись сообщает, какой продукт и какие версии затронуты и где найти исправление от производителя.

CVE отвечает на другой вопрос: какой конкретно дефект и в каком продукте? Одному типу CWE может соответствовать множество записей CVE в разных продуктах, потому что одну и ту же ошибку допускают снова и снова.

#Как читать их вместе

Читая запись CVE, ищите тип слабого места, с которым она связана. Запись, связанная с CWE-89, говорит, что перед вами SQL-инъекция, даже если продукт вам незнаком. Так то, что вы знаете о категории, можно применить к новому случаю. Работает и обратное: если у продукта есть история ошибок одного типа, вы знаете, что проверять первым.

#Почему уязвимость без достижимого пути обычно несёт низкий риск

Допустим, сервис с известным дефектом слушает только loopback-адрес вашего ноутбука. Ни одна другая машина к нему не подключится. Уязвимость ли это? Да. Высок ли риск? Обычно нет, потому что вероятность очень мала. Снаружи ноутбука до дефекта никто не дотянется, так что источник угрозы не сможет использовать его по сети.

Здесь и работает понятие риска. Меньшая вероятность означает меньший риск, даже когда воздействие было бы тяжёлым. Одна только критичность не определяет, что чинить первым.

Но будьте осторожны. «Сегодня достижимого пути нет» — утверждение об одном моменте времени. Картину могут изменить разные вещи:

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

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

#Почему неверная конфигурация считается уязвимостью

Многие новички думают, что уязвимость обязательно будет ошибкой в коде. Это слишком узкое понимание. Определение из глоссария NIST включает «реализацию» и «внутренние механизмы контроля» системы, а CWE охватывает и слабые места конфигурации. Настройка, которая открывает доступ к данным или системе, будет слабым местом, даже если ни одна строка кода не содержит ошибки.

Простой пример. Этот блок nginx включает вывод содержимого каталога для пути:

location /backup/ {
    autoindex on;
}

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

Другие частые ошибки конфигурации устроены так же:

• Облачное хранилище с публичным чтением, которое должно быть закрытым.
• Пароль администратора по умолчанию, который так и не сменили.
• Режим отладки, оставленный включённым в рабочем приложении: он может показывать посетителям трассировки стека.
• Админ-панель, открытая в публичный интернет, хотя ей место в частной сети.

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

#Практика: классифицируйте пять находок на бумаге

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

1. Веб-приложение использует версию библиотеки с публично задокументированным дефектом. Приложение доступно из интернета.
2. Для пути с резервными копиями включён вывод содержимого каталога. Сервер доступен только из офисной сети.
3. Сервис с известным дефектом слушает только loopback-адрес ноутбука.
4. У формы входа нет лимита запросов, но каждый аккаунт требует второй фактор.
5. Облачное хранилище открыто для публичного чтения и сейчас пустует.

Для каждого случая напишите одно предложение, которое начинается со слов «Риск здесь» и называет причину. Сравните ответы с рассуждениями выше. Самые полезные формулировки риска получатся в случаях 1 и 4, потому что достижимость и второй фактор меняют вероятность вреда. Случай 5 — это ошибка конфигурации, которая остаётся уязвимостью, даже если в хранилище сегодня ничего нет: данные могут появиться завтра.

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

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

• Использовать «уязвимость» и «эксплойт» как синонимы. Уязвимость — это слабое место. Эксплойт — это метод, который его использует.
• Принимать оценку критичности от сканера за свой риск. Оценка описывает дефект в целом. Ваш риск зависит от достижимости, ваших данных и мер защиты.
• Игнорировать ошибки конфигурации, потому что в коде нет бага. Настройки тоже могут быть уязвимостями.
• Считать, что «нет известного эксплойта» значит «безопасно». Это значит, что сегодня неизвестно о публичном эксплойте. О существовании закрытого это ничего не говорит.
• Считать недостижимое недостижимым навсегда. Изменения в сети и скомпрометированные машины могут изменить путь.
• Путать идентификатор CVE с типом слабого места. CVE называет один дефект в одном продукте. CWE называет категорию ошибки.

#Что изучать дальше

Прочитайте запись глоссария NIST об уязвимости и разделы об оценке рисков в NIST SP 800-30 Revision 1. Затем откройте любую интересную вам запись CVE и найдите три вещи: затронутый продукт и версии, описание дефекта и сопоставление с CWE, если оно указано. Эта привычка превращает список идентификаторов в понятную картину, и на ней держится умение читать advisories.

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

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

#Источники

• NIST CSRC glossary: vulnerability
• CWE: About CWE
• CVE: Overview
• NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments