Разработка распределенной системы автоматизированного обнаружения уязвимостей в программном обеспечении (стр. 4 )

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

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

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

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

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

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

Методы фаззинга. Полностью случайное тестирование.

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

Несмотря на свою примитивность, подобный метод в прошлом позволял выявлять уязвимости в популярных приложениях.

Мутирующее тестирование.

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

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

Порождающее тестирование.

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

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

Типы фаззеров.

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

Локальные фаззеры.

Первые два типа обязаны своему появлению среде UNIX и механизму setuid. Благодаря этому механизму пользователь может выполнять некоторые приложения с повышенными привилегиями, следовательно, уязвимость в таком приложении позволит выполнить произвольный код от имени суперпользователя. Поэтому, setuid-программы часто становятся объектом фаззинга.

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

Фаззеры переменных окружения. Аналогичный тип, за исключением того, что вместо параметров командной строки используются переменные окружения. Процесс фаззинга предельно прост, примером служит программа Sharefuzz.

Фаззеры файловых форматов. Большинство приложений в процессе работы взаимодействуют с различными файлами. С точки зрения фаззинга файл – это один из видов входных данных. Сложность формата файла может быть очень высокой, если это, например, формат документа современного офисного редактора или видеозаписи, соответственно возрастает сложность самих фаззеров. В качестве примера можно рассмотреть программу FileFuzz.

Удаленные фаззеры.

Фаззеры сетевых протоколов. Учитывая степень распространения сети Интернет в настоящий момент, естественно, что сетевые приложения являются наиболее вероятными объектами тестирования. Технология фаззинга при этом значительно отличается в зависимости от сложности исследуемого протокола. Простейшие случаи – это текстовые протоколы без какой-либо проверки целостности. Наиболее сложные – бинарные протоколы с использованием аутентификации, шифрования и контрольных сумм. Мощный инструмент данного типа – фреймворк Peach.[10]

Фаззеры веб-приложений. Инструменты данного типа заточены на выявление узявимостей, специфичных для веб приложений, таких как SQL-инъекции или межсайтовый скриптинг. Фаззеры веб-приложений используют протокол передачи гипертекста (HTTP) в качестве канала связи с исследуемым веб-сервером. Один из примеров – Powerfuzzer.

Фаззеры интернет-браузеров. Современный интернет-браузер реализует огромное количество технологий: это сетевые протоколы, языки разметки HTML и XML, CSS, объектная модель документа (DOM), графические, аудио - и видео-форматы т. д. Кроме того, браузер – самая популярная прикладная программа. Эти факторы послужили причиной появления целого класса фаззеров, заточенных для тестирования интернет-браузеров. К данному типу относятся инструменты mangleme и ref_fuzz.[11]

РАЗРАБОТКА РАСПРЕДЕЛЕННОЙ СИСТЕМЫ ПОИСКА УЯЗВИМОСТЕЙ. Обоснование выбора технологии.

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

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

Требования к системе.

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

Автоматизация работы. Практически каждое исследование на тему фаззинга содержит указание о необходимости максимально автоматизировать процесс.[12] В данном случае это означает контроль за состоянием исследуемого процесса (с его перезапуском в случае сбоя) и автоматическая регистрация результатов работы фаззера (включая отладочную информацию). Горизонтальное масштабирование. Фаззинг является ресурсоемкой задачей. Необходимо реализовать возможность масштабирования системы хотя бы в рамках аппаратной базы аналитика. Централизованное управление. Централизованное хранение результатов работы. Два этих требования необходимы, чтобы обеспечить эффективную работу в рамках масштабируемой системы.

Модель системы.

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

Рисунок 3. Модель системы.

Рассмотрим каждый компонент индивидуально.

Реализация сервера. Общие сведения.

Серверная составляющая системы представлена следующими элементами:

база данных веб-интерфейс управления прикладной интерфейс (API) для взаимодействия с клиентами

Веб-интерфейс и API реализованы на платформе Node. js[13]. Данная платформа предоставляет возможность использовать язык JavaScript для разработки серверных приложений. В качестве СУБД была выбрана SQLite[14] – компактная встраиваемая реляционная база данных. Преимущество такой конфигурации заключается в кроссплатформенности и удобстве развертывания системы.

Структура базы данных.

На данный момент база данных содержит 7 таблиц.

Описание таблиц:

Fuzzers

Содержит информацию о доступных системе фаззерах.

Clients

Содержит информацию о клиентах, выполняющих тестирование.

Targets

Cодержит информацию о приложениях, проходящих тестирование.

Tasks

Содержит информацию заданиях, сформированных системой.

Results

Содержит информацию об успешных результатах (т. е. сбоях исследуемой программы).

TaskClients

Содержит информацию о связанных заданиях и клиентах.

ClientTargets

Содержит информацию о связанных клиентах и доступных им приложениях.

Веб-интерфейс управления системой.

Все функции веб-интерфейса сгруппированы по разделам.

Фаззеры.

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

Клиенты.

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

Цели.

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

Задания.

Основной раздел системы.

фаззер тестируемое приложение список клиентов, используемых в данном задании начальный и конечный номер теста

Рисунок 4. Раздел "Задания".

Результаты.

Данный раздел содержит информацию о случаях, когда в процессе фаззинга произошел сбой тестируемой программы, т. е. информацию о потенциальных уязвимостях (см. рисунок 5).

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