cisco-talos/mutiny-fuzzerСетевой протокольный фаззер, который воспроизводит PCAP-трафик через мутационный движок (Radamsa) для быстрого обнаружения уязвимостей на целевых хостах с помощью настраиваемых процессоров сообщений и мониторов.
Статья в блоге:
Ссылки на демонстрационное видео на YouTube:
Для дополнительных функций, ориентированных на кампании фаззинга/обратную связь/обвязки:
Фреймворк фаззинга Mutiny — это сетевой фаззер, который работает путем повторного воспроизведения PCAP-файлов через мутационный фаззер. Цель — начать сетевой фаззинг как можно быстрее, в ущерб тщательности.
Общий рабочий процесс Mutiny заключается в том, чтобы взять образец легитимного трафика, например запрос браузера, и передать его в подготовительный скрипт для создания файла .fuzzer. Затем Mutiny может быть запущен с этим файлом .fuzzer для генерации трафика на целевой хост, мутируя те пакеты, которые хочет пользователь.
Существуют расширения, позволяющие изменять поведение Mutiny, включая изменение сообщений на основе ввода/вывода, изменение реакции Mutiny на сетевые ошибки и мониторинг цели в отдельном потоке.
Mutiny использует Radamsa для выполнения мутаций.
Прокси Decept — это многоцелевой сетевой прокси, который может перенаправлять трафик из обычного или TLS TCP/UDP/доменного сокетного соединения в обычное или TLS TCP/UDP/доменное сокетное соединение, среди прочих функций. Он является хорошим дополнением к Mutiny, так как может как напрямую генерировать файлы .fuzzer (что особенно полезно при фаззинге TLS-соединений), так и позволять Mutiny взаимодействовать с TLS-хостами.
sample_apps дают базовое представление о том, что можно сделать с фаззером, с несколькими различными приложениями/клиентами для тестирования.
Авторы: Джеймс Спадаро ([email protected]) и Лилит Уайетт ([email protected])
Убедитесь, что установлены python и scapy.
Распакуйте tar-архив Radamsa и выполните make (не обязательно выполнять make install, если вы не хотите иметь его в /usr/bin — будет использоваться локальный Radamsa). Обновите mutiny.py, указав путь к Radamsa, если вы его изменили.
Сохраните pcap-файл в папку. Запустите mutiny_prep.py для <XYZ>.pcap (также можно указать директорию пользовательского процессора, если он есть, подробнее ниже). Ответьте на вопросы, в итоге получите файл <XYZ>.fuzzer в той же папке, что и pcap.
Запустите mutiny.py <XYZ>.fuzzer <targetIP>. Это запустит фаззинг. Логи будут сохранены в той же папке, в директории <XYZ>_logs/<время_сессии>/<номер_сида>
Файлы .fuzzer читаемы и содержат комментарии. Они позволяют изменять различные опции для каждого файла фаззера, включая то, какое сообщение или его часть фаззируются.
В файле .fuzzer содержатся сообщения. Это просто строки, начинающиеся с 'inbound' или 'outbound', указывающие направление сообщения. Они имеют формат строк Python, где '\xYY' используется для непечатаемых символов. Они автоматически генерируются 'mutiny_prep.py' и Decept, но иногда требуют ручного редактирования.
Если сообщение содержит ключевое слово 'fuzz' после 'outbound', это означает, что оно будет фаззировано через Radamsa. Сообщение может иметь продолжение строки: просто поместите дополнительные данные в кавычки на новой строке. В этом случае вторая строка будет объединена с первой.
Альтернативно, ключевое слово 'sub' может использоваться для обозначения подкомпонента. Это позволяет указать отдельную часть сообщения, чтобы фаззировать только определенные части, а также для удобства в Message Processor.
Вот пример произвольного набора данных сообщения:
outbound 'say'
' hi'
sub fuzz ' and fuzz'
' this'
sub ' but not this\xde\xad\xbe\xef'
inbound 'this is the server's'
' expected response'
Это приведет к тому, что Mutiny передаст say hi and fuzz this but not this(0xdeadbeef). 0xdeadbeef будет передан как 4 шестнадцатеричных байта. and fuzz this будет пропущен через Radamsa для фаззинга, а say hi и but not this(0xdeadbeef) останутся неизменными.
Mutiny будет ждать ответа от сервера после передачи указанного выше сообщения из-за строки 'inbound'. Ожидаемый ответ сервера: this is the server's expected response. Mutiny не будет много делать с этими данными, кроме проверки, совпадает ли фактический ответ сервера с этой строкой. Если произойдет сбой, Mutiny запишет как ожидаемый вывод сервера, так и то, что сервер на самом деле ответил.
mutiny_classes/ содержит базовые классы для Message Processor, Monitor и Exception Processor. Любой из этих файлов можно скопировать в ту же папку, что и .fuzzer (по умолчанию), или в отдельную подпапку, указанную как 'processor_dir' в файле .fuzzer.
Эти три класса позволяют сохранять ответы сервера и изменять исходящие сообщения, мониторить цель в отдельном потоке и изменять способ обработки исключений Mutiny.
Message Processor определяет различные обратные вызовы, которые вызываются во время сеанса фаззинга. Внутри этих обратных вызовов может выполняться любой код Python. По опыту, они в основном используются тремя способами.
Наиболее распространенный случай — когда сервер отправляет токены, которые нужно добавить в будущие исходящие сообщения. Например, если первое сообщение Mutiny выполняет вход, и сервер отвечает идентификатором сессии, обратный вызов postReceiveProcess() можно использовать для сохранения этого идентификатора. Затем в preSendProcess() можно исправить исходящие данные, добавив этот идентификатор сессии. Пример этого есть в sample_apps/session_server.
Другое распространенное использование Message Processor — ограничение или изменение фаззированного сообщения. Например, если сервер всегда отбрасывает сообщения длиннее 1000 байт, возможно, не стоит отправлять большие сообщения. preSendProcess() можно использовать для сокращения сообщений после фаззинга, но до их отправки, или для вызова исключения.
Вызов исключения — это последний способ, которым обычно используются Message Processor. Внутри обратного вызова можно вызывать любые пользовательские исключения, определенные в mutiny_classes/mutiny_exceptions.py. Существует несколько исключений, все с комментариями, которые вызывают различные поведения Mutiny. Обычно это включает логирование, повторную попытку или прерывание текущего запуска.
Monitor имеет функцию monitorTarget(), которая выполняется в отдельном потоке от основного фаззера Mutiny. Цель — позволить реализовать долго работающий процесс, который может отслеживать хост каким-либо образом. Это может быть что угодно, что можно сделать на Python, например общение с демоном мониторинга на целевом хосте, чтение длинного файла или даже просто повторный пинг хоста, в зависимости от требований сеанса фаззинга.
Если Monitor обнаруживает сбой, он может в любой момент вызвать signalMain(). Это просигнализирует основному потоку Mutiny о возникновении сбоя, и он запишет сбой. Эта функция обычно должна работать в бесконечном цикле, так как возврат приведет к завершению потока, и он не будет перезапущен.
Exception Processor определяет, что Mutiny должен делать с данным исключением во время сеанса фаззинга. В самом общем смысле функция processException() будет по возможности преобразовывать исключения Python и OS в действия обработки ошибок Mutiny.
Например, если Mutiny получает 'Connection Refused', ответ по умолчанию — предположить, что целевой сервер невосстановимо умер, поэтому Mutiny запишет предыдущий запуск и остановится. Это верно в большинстве случаев, но это поведение можно изменить на любое из исключений в mutiny_classes/mutiny_exceptions.py по мере необходимости, что позволяет настроить обнаружение сбоев и коррекцию ошибок.