Отчет по уязвимостям

Общая информация

Начало - договор об оказании услуги. В нем указываются юридические, технические, временнЫе, ... рамки и ограничения, ответственность сторон. Часть вышеуказанной информации попадает в отчет.

Основа хорошего отчета закладывается перед началом тестирования. 

Тестирование бывает White box (Организация предоставляет все данные) и Black box (тестирование вслепую). 

Оценка уязвимостей и составление отчета

Перед постановкой задачи устранения уязвимости необходимо:

  1. Пересчитать критичность уязвимости с учетом "веса" активов и исключений. Добавление исключений должен быть формализован, и включать в себя согласование исключений и регулярный пересмотр. Для пересчета критичности может использоваться фреймворк CVSS.
  2. Убедиться, что уязвимость присутствует на самом деле. 
  3. Определить владельца актива, который будет ответственным за устранение проблемы.

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

Типы отчетов

Внутренние требования

Шаг 1. Выбор стандарта оценки уязвимостей. Стандарт CVSS v3 используется для оценки технической серьезности уязвимости. Стандарт OWASP Risk Rating Methodology используется для оценки рисков web приложения для бизнеса. Иногда рекомендуют использовать оба стандарта.

Шаг 2. Используемая среда / правила оформления / способ хранения информации о найденных уязвимостях. Упоминаются Dradis, CherryTree, OneNote. В правилах оформления определяется набор данных для каждой уязвимости (например дата и время проведения, скриншоты, формат описания последовательности действий). 

Вариант структуры.

1 Всту­питель­ная часть
1.1 Клас­сифика­тор най­ден­ных уяз­вимос­тей
2. Общее опи­сание про­делан­ной работы
3. Тех­ничес­кий отчет
4. Рекомен­дации по устра­нению уяз­вимос­тей

Вступительная часть
Фак­ты, извес­тные исполнителю и заказ­чику до начала работ. К ним отно­сят­ся: дата про­веде­ния пен­теста, методи­ка, которая применя­лась (очень крат­ко), основные эта­пы тес­тирова­ния, перечень сис­тем для тес­тирова­ния и исклю­чения из объ­ема работ, перечень узлов, а так­же методи­ки, которые исполнитель обя­зуется не при­менять (соци­аль­ную инже­нерию или ата­ки на отказ в обслу­жива­нии).

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

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

Общее описание проделанной работы
Этот раз­дел дол­жен содер­жать зна­чимую для руково­дите­лей ком­пании‑заказ­чика информа­цию о про­делан­ной работе и ее резуль­татах. Глав­ные тре­бова­ния, предъ­явля­емые к нему, — понят­ность и крат­кость. Сам отчет может рас­тянуть­ся на десят­ки, если не сот­ни стра­ниц. Руково­дитель не всег­да готов читать докумен­тацию такого объ­ема, и зачас­тую в этом нет необ­ходимос­ти. Глав­ное — понять кри­тичес­ки важ­ные резуль­таты для при­нятия даль­нейших решений. Наша задача в этом раз­деле — зав­ладеть вни­мани­ем читате­ля с любым уров­нем под­готов­ки, опи­сать общую ситу­ацию и сооб­щить о наибо­лее зна­чимых выводах.

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

Вариант - отчет в виде кар­точек по най­ден­ным уяз­вимос­тям с раз­делами:

Крат­кое опи­сание най­ден­ного. Прос­то и дос­тупно опи­сыва­ем, что уда­лось най­ти, что прив­лекло наше вни­мание.
Уро­вень рис­ка. Прос­тавля­ем бал­лы по той шка­ле, о которой говори­лось ранее.
Ука­зание мес­тонахож­дения в сис­теме. Ука­зыва­ем IP-адрес, DNS-имя или что‑то, что однознач­но иден­тифици­рует сис­тему.
Опи­сание инс­тру­мен­тария. Это необя­затель­ный пункт, но он может очень помочь инже­нерам со сто­роны заказ­чика, ког­да они решат вос­про­извести твои дей­ствия.
Ссыл­ка на опи­сание уяз­вимос­ти. Что­бы чрез­мерно не уве­личи­вать раз­меры отче­та, рекомен­дуем сде­лать внеш­ние ссыл­ки на опи­сания уяз­вимос­тей из откры­тых баз зна­ний. Выб­рать мож­но любую,  нап­ример cve.mitre.org, cvedetails.com, snyk.io или rapid7.com.
Скрин­шоты и дру­гие под­твержде­ния. Скрин­шоты нуж­но добав­лять толь­ко при усло­вии, что они наг­лядно что‑то объ­ясня­ют.
Ре­комен­дации, как испра­вить уяз­вимость. В этом раз­деле нуж­но при­вес­ти рекомен­дации про­изво­дите­ля уяз­вимого прог­рам­мно­го обес­печения или свои собс­твен­ные. В любом слу­чае ответс­твен­ность за устра­нение уяз­вимос­тей лежит на заказ­чике и толь­ко ему решать, как они будут устра­нены и будут ли.

СVSS (Common Vulnerability Scoring System)

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

AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

CVSS состоит из трех групп метрик, которые описывают уязвимость:

Базовая группа

В версии CVSS 3.0 сюда входят следующие метрики:

Метрика Описание
AV (Attack Vector)

вектор атаки. Варианты:

  • N сетевой (Network)
  • A локальная сеть (Adjacent)
  • L локальный (Local)
  • P физический (Physical).
AC (Attack Complexity)

сложность атаки. Варианты:

  • H высокая. необходимо выполнение доп. условий для эксплуатации уязвимости
  • M средняя
  • L низкая 
PR (Privileges Required)

привилегии для эксплуатации уязвимости. Варианты:

  • N (None, привилегии не нужны), 
  • L (Low, нужны низкие привилегии, например права пользователя)
  • H (High нужны высокие привилегии) 
UI (User Interaction)

необходимость пользовательского взаимодействия. Варианты:

  • N (None, взаимодействие не требуется)
  • R (Required, требуется)
S (Scope)

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

  • U (Unchanged, граница не меняется)
  • C (Changed, меняется)

Например, уязвимость побега из контейнера, позволяющая выполнить код на хосте будет иметь свойство S:C.
C (Confidentiality)

затрагивает ли уязвимость конфиденциальность информации. Варианты:

  • H высокий
  • M средний
  • L низкий
I (Integrity) затрагивает ли уязвимость целостность информации. Варианты:
  • H высокий
  • M средний
  • L низкий
A (Availability) затрагивает ли уязвимость доступность информации. Варианты:
  • H высокий
  • M средний
  • L низкий

Временная группа

Метрика Описание
E (Exploit Code Maturity)

доступность средств эксплуатации. Варианты:

  • ND/X (Not Defined не определено)
  • H (High средства доступны или не требуются) 
  • F (Functional средства доступны)
  • POC/P (Proof-of-Concept есть пример эксплуатации, но он может не работать)
  • U (Unproven средства недоступны или уязвимость теоретическая)
RL (Remediation Level)

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

  • ND/X (Not Defined информация отсутствует)
  • U (Unavailable исправление недоступно)
  • W (Workaround есть неофициальное исправление)
  • FT/T (Temporary Fix есть официальное, но временное решение)
  •  OF/O (Official Fix официальное исправление уязвимости)
RC (Report Confidence)

достоверность отчета.

  • X (Not Defined не определена)
  • U (Unknown нет информации)
  • R (Reasonable известны некоторые детали об уязвимости)
  • C (Confirmed отчет подтвержден)

Переменные среды

Данные параметры проставляются аналитиком для корректировки оценки уязвимости. Например, если для компании важна доступность какого-либо актива, то специалист может выставить параметр Availability Requirement (AR) в значение High(H).

Метрика Описание
CR (Confidentiality Requirement) требования к конфиденциальности. Варианты:
  • H высокий
  • M средний
  • L низкий
  • ND/X не определены
IR (Integrity Requirement) требования к целостности. Варианты:
  • H высокий
  • M средний
  • L низкий
  • ND/X не определены
AR (Availability Requirement) требования к доступности. Варианты:
  • H высокий
  • M средний
  • L низкий
  • ND/X не определены

Итоговая оценка

После определения метрик по стандарту CVSS рассчитывается итоговая оценка уязвимости, которая считается по шкале от 0 до 10, где 0 — отсутствие уязвимости, а 10 — максимально критичный приоритет. Формула расчета достаточно сложная, проще библиотеками python или калькулятором. 

Источники:

Статья на Хакере

CVSS V 3.1 Calculator

Система хранения информации

После пробных не-лабораторных задач пришел к выводу о необходимости хранения информации о процессе. Вот вроде все просто и должно было уже давно быть отработано - но не тут-то было. Оказалось несколько иначе. Редакторов крайне много, и выбор сильно усложняется. А если добавить требования например к API - вылетают почти все)

Начнем с разделения на удобство создания отчета и удобство хранения технической информации. Потом попробую объединить эти аспекты. 

Список редакторов после общего поиска

Рекомендация из статьи по документации:

Совместная работа

Еще CryptPad https://cryptpad.org/ для безопасности.

Также хранение данных в msf или burp enterprize edition.

Требования

Общие или особенности

Название Описание Приоритет
Начальный уровень подготовки Высокий. Иначе в хакеры не идут.
Многопользовательский режим Вариант локального хранения файлов + git вполне может сработать. 
Одновременное редактирование Хз. Для блока не встречал необходимость.
Динамическое обновление

Время запуска и настройки Серьезная проблема.
Время изучения Основная проблема. Должно быть минимизировано.
Процент выполнения блока При большом объеме данных может быть критично. 
Дополнительное ПО На примере msf необходим гибридный подход. Локальное использование должно быть из коробки.
Локальное / браузер Портирование затратная процедура. Но скорость должна быть высокой.
Визуализация отчета online Возможно для корпоративных версий.

Редактор

Название Описание Приоритет
Шаблоны Шаблоны в целом для документа и для блоков. 0
Модификация символов Мне хватает жирного шрифта и 3 вариантов размера.
Цвета текста и выделения

Списки

Ссылки

Таблицы

Рисунки

Выравнивание текста 4 варианта

Интеграции, импорт / экспорт

Название Описание Приоритет
Текстовые файлы Самое логичное - одна строка в блок данных (столбец таблицы). Но только данных. Экспорт оформления в txt бессмысленно. 0
JSON / XML / ... Сохранение проекта. 1
msf Важно, однако здесь есть вопросы. 2
Остальные приложения По возможности. Однако чем больше - тем выше скорость работы. Хотя небольшой скрипт решит вопрос преобразования данных в нужный формат. 2
API Крайне желательно. Инструменты разные.
Импорт шаблона из word Звучит круто, но практически может и не нужно.

Сначала пришел к выводу, что для локальных данных вполне подойдет cherrytree. Однако после целого дня попыток подключить python скрипты выяснилось - уже нельзя.

Затем пришел к выводу: возможно, хватит и простого редактора, как в VSC, и скриптов для шаблонизации. Хранить данные в текстовом виде, git через консоль, отчет по стандартным файлам из шаблона при помощи скрипта. Интеграция в этом случае простейшая, В качестве развития - что-то типа msfconsole, но для создания отчета. С одной стороны, сохраняется гибкость в хранении данных (всегда можно добавить отсутствующие блоки в данные). Прямой доступ к данным, txt читаются всеми. Интеграция с любым инструментом, было бы желание. Будут проблемы с общим доступом, однако и это можно обойти за счет периодических коммитов. Красивый отчет из известных путей через скрипт - без проблем, поэтому хватит хранения в виде дерева, итоговые данные в текстовом виде, одна строка - один элемент. Остается вопрос стандартизации хранения. 

Сравнив ряд редакторов (Kate, Zed, Notepadqq, gedit) пришел к выводу: gedit. Легкий, без проблем в Kali, тестируем!

Gedit

sudo apt install gedit gedit-plugins

Настройка.

В меню Вид нужно включить отображение боковой панели и нижней панели.

В разделе Параметры - Модули устанавливаем "Встроенный терминал". После этого появляется возможность быстрого исполнения скриптов или запуска консоли (план на будущее). Из минусов - терминал открывается в домашней папке, в нем тоже нужно перейти в папку проекта.

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

 

Структура информации при пентесте

Общие мысли

DNS

Задача Для списка доменов сохранить поддомены.
Критерии качества

Различные ip адреса для поддоменов.
Входные данные Список доменных имен. Формат: в каждой строке отдельное доменное имя.
Промежуточные данные Логи из разных инструментов.
Результат Список для передачи следующим инструментам. Дополнительные параметры - ip адреса, нужен ли в отчете, комментарии

Структура папок:

dns/ Корневая папка для хранения dns.
dns/list.txt Файл списка доменных имен для поиска.
dns/subdomains_*.txt Список поддоменов.
dns/template.doc Шаблон отчета.
dns/raw/ Папка хранения результатов внешних инструментов. Все *.txt файлы считаются результатами.

Задачи консоли:

dns create Создать структуру директории и файлы
dns delete Удалить раздел

Сформировать из сырых файлов непересекающийся список

Скопировать поддомены в список доменов для поиска доменов следующего уровня
dns report Сформировать раздел отчета на основании шаблона

IP