otsmr/blackbox-fuzzingФаззинг IoT-устройств на примере маршрутизатора TL-WR902AC
Это HTML-версия моей курсовой работы, которую можно скачать в формате PDF здесь.
Фаззинг стал «одним из наиболее эффективных способов» поиска ошибок в программном обеспечении. С этого или подобных утверждений начинаются многие современные статьи, посвящённые фаззингу, [google-scholar]. Основной целью нашей предыдущей курсовой работы на тему «Internet of Vulnerable Things» было найти ошибку, связанную с памятью, и затем написать эксплойт для этой уязвимости. Нам удалось найти уязвимость путём реверс-инжиниринга прошивки, но ошибок, связанных с памятью, найдено не было. Поиск переполнения буфера путём ручного реверс-инжиниринга бинарного файла не только отнимает много времени, но и требует большого опыта. При этом фаззинг нацелен на то, чтобы быть «наиболее эффективным способом» поиска таких уязвимостей, связанных с памятью. Google, например, представил OSS-Fuzz, который непрерывно фаззит программное обеспечение с открытым исходным кодом и уже нашёл более 10 000 уязвимостей в 1 000 проектах [oss-fuzz].
Цель этой курсовой работы — снова найти уязвимость, связанную с памятью, но на этот раз с использованием фаззинга. Целевая уязвимость должна быть эксплуатируемой по сети без знания учётных данных администратора. В этой работе описывается способ достижения этой цели. Для этого работа разделена на две части. Первая часть посвящена тому, как найти подходящую цель, какие инструменты можно использовать и каким требованиям должна удовлетворять хорошая цель для фаззинга. Вторая часть описывает, как разработать и отладить харнесс, способный фаззить конкретную функцию в бинарном файле. Затем разработанный харнесс используется AFL++ для фаззинга целевой функции. Далее даётся краткий обзор и описывается текущее состояние дел в области фаззинга IoT-устройств.
Все файлы, созданные в рамках этой курсовой работы, также полностью опубликованы на GitHub и доступны по следующему URL: otsmr/blackbox-fuzzing.
Фаззинг IoT-устройств не так прост, как фаззинг проекта с открытым исходным кодом. Часто исходный код является проприетарным, что делает невозможным фаззинг серого ящика, который инструментирует исходный код для достижения наилучшей производительности фаззинга, [afl-persistent]. Кроме того, архитектура ЦП часто не поддерживается фаззерами нативно, что требует эмулятора такого как QEMU [qemu], что также снижает скорость фаззинга [afl-persistent]. Ещё одной проблемой являются аппаратные периферийные устройства, что усложняет разработку общего подхода. В статье «Embedded Fuzzing: A Review of Challenges, Tools, and Solutions» [embedded-fuzzing] даётся обзор различных стратегий фаззинга, таких как аппаратный фаззинг встраиваемых систем. Большинство из этих стратегий требуют исходный код целевой программы, например, при портировании исходного кода фаззеров, таких как AFL, на IoT-устройства на базе ARM для запуска фаззера на аппаратном обеспечении IoT. Запуск фаззера на аппаратном обеспечении устройства также создаёт проблемы с производительностью, поскольку такие устройства часто имеют маломощные ЦП, которые медленнее обычных настольных ЦП. Другой подход, представленный в этой статье, — это фаззинг встраиваемых систем на основе эмуляции, при котором в эмуляторе выполняется либо одна целевая программа для проведения фаззинга на основе покрытия кода, либо вся система целиком.
Все вышеупомянутые подходы нацелены непосредственно на бинарный файл с использованием эмулятора или инструментирования
исходного кода. Эти подходы требуют настройки фаззинга, которая часто должна быть специально разработана
для конкретного IoT-устройства, и их трудно обобщить. Для этого исследователи создали программу
IoTFuzzer, которая представляет собой автоматизированный фреймворк для фаззинга, нацеленный на «поиск уязвимостей
повреждения памяти без доступа к образам их прошивки
[iotfuzzer]». IoTFuzzers
основан на наблюдении, что большинство IoT-устройств имеют мобильное приложение для управления ими, и такие приложения
содержат информацию о протоколе, используемом для связи с устройством. Затем программа
определяет и повторно использует специфичную для программы логику для мутации тестовых примеров с целью эффективного тестирования
IoT-устройств [iotfuzzer].
Харнесс описывает последовательность вызовов API, обрабатывающих входные данные, предоставленные фаззером. В отличие от обычного приложения, которому часто не нужен харнесс, библиотека, реализующая переиспользуемые функции, должна вызываться с правильными параметрами и в правильной последовательности, чтобы состояние между несколькими совместно используемыми вызовами функций можно было сохранить. Случайный фаззинг библиотеки без построения конечного автомата вряд ли будет успешным и, напротив, приведёт к множеству ложноположительных сбоев, если зависимости библиотеки не соблюдаются. Это может произойти, например, когда фаззер пропускает проверку размера буфера, что приводит к ложному переполнению буфера.
В этой работе будут фаззиться обычные приложения, но из-за аппаратных зависимостей, связанных с использованием сокетов и многопоточности, нам также необходимо создать для них харнесс. Харнесс загружается в контексте бинарного файла и может вызывать внутренние функции целевой программы, как показано в Код 10.
Термин «корпус» описывает допустимые входные образцы или тестовые примеры и служит базовым ориентиром для генерации новых входных данных в процессе фаззинга. В Код 10 это был бы, например, HTTP-запрос. Затем фаззеры используют этот корпус для создания мутированных или разнообразных тестовых примеров, что способствует обнаружению уязвимостей программного обеспечения путём исследования различных сценариев ввода.
Самая трудоёмкая часть фаззинга чёрного ящика — поиск потенциально
уязвимой функции в прошивке. Первый шаг — найти
интересные бинарные файлы, которые, например, доступны по сети,
используют небезопасные функции или не имеют таких функций безопасности, как стековая
канарейка, которая является защитой от переполнения буфера. В нашей предыдущей работе
([iovt]) уже было описано, как извлечь прошивку
из целевого роутера и как найти потенциально опасный бинарный файл.
Для этого использовался инструмент EMBA [emba]. EMBA ранжирует все
бинарные файлы, найденные в прошивке, по количеству небезопасных функций, таких как
strcpy, наличию сетевого доступа и таких средств защиты, как стековая канарейка или
NX-бит, которые становятся интересными при эксплуатации переполнения буфера;
результат можно увидеть в Код 1.
