litefuzz

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

Он находил ошибки в 50+ приложениях и библиотеках от ведущих компаний и open source.

Простая настройка для начала фаззинга на Linux, Mac и Windows.

litefuzz

Это простой локальный целевой объект, с которым AFL++ прекрасно справляется, и приведённый здесь лишь для примера. Litefuzz был разработан для гораздо более широких возможностей в области сетевого фаззинга и фаззинга графического интерфейса, что вы увидите, когда погрузитесь в изучение. ## зачем Да, ещё один фаззер, и притом не очень хорошо соответствующий современным тенденциям и соглашениям. Были сделаны компромиссы для удовлетворения определённых требований. Эти требования включают фаззер, который работает по умолчанию на нескольких платформах, фаззит как локальные, так и сетевые цели и очень прост в использовании. Я не пытаюсь никого ни в чём убедить, но позвольте предоставить некоторый контекст. Некоторые цели требуют больших усилий для интеграции таких фаззеров, как AFL, в сборочную цепочку. Это не проблема, поскольку данный фаззер не требует инструментирования, жертвуя точным покрытием, достигаемым инструментированием, ради простоты и портативности. AFL также не поддерживает сетевой фаззинг «из коробки», и хотя существуют проекты на его основе, которые это умеют, они далеко не просты в использовании и обычно требуют дополнительных модификаций кода и обвязок для работы (аналогичная история с [Libfuzzer](https://llvm.org/docs/LibFuzzer.html)). Он не поддерживает параллельный фаззинг, а также не предоставляет ничего похожего на огромное ускорение, которое может дать [persistent mode](https://lcamtuf.blogspot.com/2015/06/new-in-afl-persistent-mode.html), поэтому он не может масштабироваться так, как фаззеры с такими возможностями. Повторюсь, это не самый современный фаззер. Но ему не нужен исходный код, настройка сборки или определённые функции ОС. Он даже может фаззить некоторые графические интерфейсы сетевых клиентов и интерактивные приложения. Он во многом использует то, что уже есть в системе, и многие функции, такие как мутаторы и минимизация, были написаны с нуля. Он был спроектирован так, чтобы «просто работать», и были приложены усилия для автоматизации настройки и установки тех немногих зависимостей, которые ему нужны. Этот фаззер был написан для определённой цели: приносить пользу в самых разных сценариях и средах, и, что самое важное, по чему в конечном счёте следует оценивать все фаззеры — способность находить ошибки. И **он находит** [ошибки](https://github.com/sec-tools/beta/blob/main/README.md#trophies). Он не предполагает наличия исходного кода цели, поэтому может довольно хорошо покрывать закрытое программное обеспечение. Он может работать как часть автоматизации с небольшими изменениями, но ориентирован на то, чтобы быть интересным в использовании для исследователей уязвимостей. Однако его полезнее рассматривать как исследовательский проект, а не полноценный продукт. Кроме того, здесь нет сложной настройки, когда он «из коробки» слегка сломан или требует дополнительной работы для запуска на современных операционных системах. Он протестирован и работает на Ubuntu Linux, Mac и Windows и поставляется с полностью функциональными скриптами, которые делают почти всё за вас, чтобы настроить готовую к фаззингу среду. **После завершения скрипта настройки требуется всего несколько минут, чтобы начать фаззить множество различных целей.** ## как это работает **Litefuzz поддерживает три различных режима: локальный, клиентский и серверный.** Локальный означает фаззинг локальных бинарных файлов, которые на Linux/Mac запускаются через подпроцесс с автоматической поддержкой триажа через GDB и LLDB соответственно при авариях и через [WinAppDbg](https://github.com/MarioVilas/winappdbg) на Windows. Аварии записываются в локальный каталог аварий и сортируются по типу ошибки, например, чтение/запись AV или SIGABRT/SIGSEGV вместе с хешами файлов. Все уникальные аварии триажируются по мере фаззинга, и эти данные вместе с выводом цели (если доступны) также захватываются и помещаются в качестве артефактов в тот же каталог. Также возможно воспроизвести аварии с помощью `--replay` и указания аварийного файла. В `local` клиентском режиме входной каталог должен содержать приветствие сервера, ответ или другие данные, которые клиент ожидает при подключении к серверу. На данный момент реализован только один «выстрел» для сетевого фаззинга без поддержки сложных сессий. Клиент запускается через командную строку и отлаживается так же, как и при файловом фаззинге. Для поддержки этого сценария настраивается слушатель; да, это медленно и граничит с ручным трудом, но это работает. Если обнаружена авария, она воспроизводится в gdb для получения деталей триажа. В `remote` клиентском режиме это работает так же, за исключением отсутствия локальной отладки/триажа аварий. В *local* серверном режиме это похоже на локальный клиентский режим, а для `remote` серверного режима он просто подключается к указанной цели и отправляет мутированные образцы данных клиента, которые пользователь указывает в качестве входных данных, но предоставляется только простой триаж: «можем ли мы всё ещё подключиться; если нет, то, вероятно, предыдущий образец вызвал аварию». Существует несколько функций мутации, написанных с нуля, которые в основном выполняют случайные мутации со случайным выбором входных данных, указанных флагом `-i`. Для файлового фаззинга просто выберите локальный режим и передайте целевую командную строку, где FUZZ обозначает, где приложение ожидает имя файла для разбора, например, `tcpdump -r FUZZ`, вместе с входным каталогом «хороших файлов» для мутации. Для фаззинга сетевых клиентов это похоже на локальный фаззинг, но также укажите параметры подключения через `-a`. А если вы хотите фаззить серверы, используйте серверный режим и укажите `protocol://address:port` так же, как для клиентов. Он фаззит так же быстро, как цель может потреблять данные и завершать работу, как в случае с большинством приложений командной строки, или столько, сколько вы определили, прежде чем истечёт время ожидания локального выполнения или сетевого подключения, что может быть намного медленнее. Никаких хитрых exec или трюков с ядром здесь нет. Но, конечно, если вы напишете обвязку, которая быстро разбирает входные данные и завершает работу, покрывая определённую часть цели, это тоже помогает. Но если вы можете так близко подобраться к цели, вам, вероятно, лучше использовать [persistant mode](https://lcamtuf.blogspot.com/2015/06/new-in-afl-persistent-mode.html) или аналогичные возможности, которые могут предложить другие фаззеры. Короче говоря... ### что он делает - работает на linux, windows и mac и поддерживает py2/py3 - фаззит бинарные файлы CLI/GUI, которые читают из файлов/stdin - фаззит сетевые клиенты и серверы, открытые или проприетарные, доступные для локальной или удаленной отладки - диффы, минимизация, воспроизведение, сортировка и автотриаж аварий - различные функции, такие как поддержка TLS, фаззинг бинарных файлов golang и некоторые дополнения для Mac - мутирует входные данные с помощью различных встроенных мутаторов + pyradamsa (Linux) ### что он не делает - нативное инструментирование - масштабирование с параллельными заданиями - сложный сессионный фаззинг - мониторинг удалённых клиентов и серверов (только базовые проверки, например, подключение) ## поддержка В основном тестировался на **Ubuntu Linux 20.04** (22.04 и 21.04 — легко), **Windows 10** и **Mac OS 11** (12 — легко). Фаззер и скрипты настройки могут также работать на немного более старых или новых версиях этих операционных систем, но основная часть исследований, тестирования и разработки проводилась в этих средах. Поддерживается Python3, и были предприняты усилия, чтобы код был совместим с Python2, так как он необходим для фаззинга на Windows через [WinAppDbg](https://github.com/MarioVilas/winappdbg). Тестирование платформ в основном проводилось на оборудовании Intel, но всё, похоже, в основном работает и на платформе M1 от Apple (заметные исключения: на Linux плагин exploitable для GDB, вероятно, не поддерживается, как и Pyradamsa). Также есть скрипты настройки в setup/, которые автоматизируют большинство или все задачи и установку зависимостей. В целом он может фаззить нативные бинарные файлы на каждой платформе, которые часто скомпилированы на C/C++, но также может отлавливать аварии в бинарных файлах Golang (экспериментально). ### версии python Python3 поддерживается для Linux и Mac, а Python2 требуется для Windows. Почему Py3 для Linux и Mac? Pyautogui, Pyradamsa (только Linux), лучшая поддержка сокетов на Mac. Почему Py2 для Windows? Winappdbg требует Py2. ### linux GDB для отладки и [exploitable](https://github.com/jfoote/exploitable) для триажа аварий. Если это OSS, вы можете собрать и инструментировать цель с помощью [санитайзеров](https://fuzzing-project.org/tutorial2.html) и т.п., в противном случае есть [отладчики памяти](https://en.wikibooks.org/wiki/Linux_Applications_Debugging_Techniques/Heap_corruption), которые можно загрузить во время выполнения. Эта установка вместе с зависимостями Python и другими полезными вещами автоматизирована с помощью [setup/linux.sh](https://github.com/sec-tools/litefuzz/blob/main/setup/linux.sh). Рекомендуемая ОС — Ubuntu 20.04, так как на ней проводилось большинство тестов. ### mac Вместо gdb мы используем lldb для отладки на OS X, так как он входит в состав инструментов командной строки XCode. Будучи администратором или в группе разработчиков, вы должны иметь возможность использовать lldb, но это поведение может отличаться в разных средах и версиях, и в крайнем случае вам может потребоваться запускать его с привилегиями sudo. Единственное, что вам нужно сделать вручную, — отключить SIP (в режиме восстановления, через cmd+R или используйте хаки vmware fusion). В противном случае автотриаж не сработает при фаззинге в ОС Тима Кука. Почти вся настройка автоматизирована с помощью скрипта [setup/mac.sh](https://github.com/sec-tools/litefuzz/blob/main/setup/mac.sh), так что вы можете просто запустить его для быстрого старта. ### windows [WinAppDbg](https://github.com/MarioVilas/winappdbg) используется для отладки на Windows с небольшим ограничением: фаззинг stdin не поддерживается. Как и в случае с автоматическими настройками для других операционных систем, chocolatey помогает автоматизировать установку пакетов на windows. Запустите [setup/windows.bat](https://github.com/sec-tools/litefuzz/blob/main/setup/windows.bat) в корневом каталоге litefuzz от имени Администратора, чтобы автоматизировать установки. Он установит средства отладки и другие зависимости для бесперебойной работы. ### цели Это список типов целей, которые были протестированы и в целом поддерживаются. * Локальные CLI/GUI приложения, разбирающие файловые форматы или stdin - поддержка отладки * Локальные CLI/GUI сетевые клиенты, разбирающие ответы сервера - поддержка отладки для CLI - ограниченная поддержка отладки для GUI * Локальные CLI сетевые серверы, разбирающие запросы клиентов - поддержка отладки (оговорка: должен быть возможность запустить как отдельный исполняемый файл, иначе можно рассматривать как *удалённый*) * Локальные GUI сетевые серверы, разбирающие запросы клиентов - теоретически поддерживается, не тестировалось * Удалённые CLI/GUI сетевые клиенты, разбирающие ответы сервера - без поддержки отладки * Удалённые CLI/GUI сетевые серверы, разбирающие запросы клиентов - без поддержки отладки - исключение: на Mac с использованием функций `attach` или `reportcrash` Опять же, фаззер может работать с локальными приложениями, клиентами и серверами на Linux, Mac и Windows и, конечно, может фаззить удалённые объекты независимо от платформы цели. ### триаж * Локальные CLI/GUI приложения, разбирающие файловые форматы или stdin - запустить приложение, перехватить сигналы, воспроизвести, запустив его снова внутри отладчика с файлом-аварийщиком * Локальные CLI/GUI сетевые клиенты, разбирающие ответы сервера - запустить приложение, перехватить сигналы, воспроизвести, запустив его снова внутри отладчика с файлом-аварийщиком * Локальные GUI/CLI сетевые серверы, разбирающие запросы клиентов - запустить приложение в отладчике, перехватить сигналы, воспроизвести, запустив его снова внутри отладчика с файлом-аварийщиком * Удалённые CLI/GUI сетевые клиенты, разбирающие ответы сервера - нет видимости, собирать аварии на удалённой стороне - можно вручную написать вспомогательные скрипты для помощи в триаже * Удалённые CLI/GUI сетевые серверы, разбирающие запросы клиентов - нет видимости, собирать аварии на удалённой стороне - можно вручную написать вспомогательные скрипты для помощи в триаже - исключение на Mac: опции `attach` и `reportcrash`, которые можно использовать для включения некоторых возможностей триажа ## начало работы Большая часть настройки на всех платформах автоматизирована с помощью скриптов в каталоге [setup](https://github.com/sec-tools/litefuzz/blob/main/README.md#setup). Просто запустите их из корня litefuzz, и это сэкономит вам много времени и поможет включить кое-что необходимое для автоматизированных развёртываний. Полезно использовать ВМ для настройки чистой ОС и среды фаззинга, так как среди прочего возможности создания снимков состояния пригодятся. См. [INSTALL.md](https://github.com/sec-tools/litefuzz/blob/main/INSTALL.md) для подробностей. **После установки обратитесь к примеру фаззинга latex2rtf в начальном разделе для быстрого запуска или погрузитесь во все параметры командной строки и дополнительные примеры, подробно описанные в этом README.** ### docker Вы можете запустить litefuzz с помощью Docker, используя `Dockerfile`, без установки зависимостей локально. Это особенно полезно для быстрого тестирования или если вы хотите избежать установки зависимостей в вашей системе. Dockerfile работает как: - **Изнутри репозитория** - использует локальные файлы (быстрее, включает локальные изменения) - **Автономно** - может быть собран из любого каталога (клонирует из GitHub)```bash # Build the Docker image (from any directory with Dockerfile) docker build -t litefuzz:latest . # Run litefuzz docker run --rm litefuzz:latest python3 litefuzz.py --help

Это запустит pytest для `test_litefuzz.py` в главном каталоге и выдаст результаты PASS/FAIL после завершения тестового запуска. #### тесты аварийных приложений Несколько примеров приложений с ошибками для тестирования возможностей обнаружения сбоев и триажа на разных платформах можно найти в папке `test`. - (a) разыменование нулевого указателя - (b) деление на ноль - (c) переполнение кучи - (d-gui) ошибка форматной строки в графическом интерфейсе - (e) переполнение буфера в клиенте - (f) переполнение буфера в сервере Они автоматически собираются во время установки, и вы можете запускать их в командной строке, в отладчике или использовать для тестирования в качестве целей фаззинга. **Если запускаете из командной строки Windows, проверьте `Просмотр событий -> Журналы Windows -> Приложение`, чтобы увидеть сбои.** ## опции Существует множество различных опций и функций для использования в различных сценариях целевых приложений. Ниже приводится краткое объяснение и несколько примеров, чтобы помочь понять, как их использовать. ### каталог сбоев `-o` позволяет указать каталог сбоев, отличный от стандартного, который находится в crashes/ в локальном пути. Это можно использовать для управления папками сбоев для нескольких одновременных сеансов фаззинга разных приложений. ### изолированный режим `-u` изолирует целевое приложение от обычного процесса фаззинга, например, от выполнения или многократной отправки пакетов и проверки на сбои. Вместо этого этот режим предназначен для интерактивных клиентских приложений, например Postman, где можно писать сценарии внутри приложения для повторения подключений для фаззинга клиента. Целевое приложение запускается внутри отладчика, фаззер приостанавливается, чтобы дать пользователю время нажать несколько кнопок или настроить конфигурацию целевого приложения для автоматического запуска, пользователь возобновляет работу, и теперь вы фаззите интерактивные сетевые клиенты. `litefuzz -lk -c "/snap/postman/140/usr/share/Postman/_Postman" -i input/http_responses -a tcp://localhost:8080 -u -n 100000 -z` Изолированный режим + обновление можно использовать для интерактивных клиентов, например, запустить FileZilla в отладчике, но постоянно нажимать F5, чтобы он переподключался к серверу для каждой новой итерации. Кроме того, фаззинг локальных CLI/GUI серверов запускается и выполняется только один раз внутри отладчика, чтобы сделать процесс немного более эффективным. `--key` также позволяет отправлять нажатия клавиш во время фаззинга интерактивных целей, например, фаззинг разбора ответов FTP-сервера в FileZilla путем отправки "обновить соединение" с помощью F5. `litefuzz -lk -c "filezilla" -a tcp://localhost:2121 -i input/ftp/filezilla -u -pp --key "F5" -n 100 -z glibc` примечание: изолированный режим был протестирован только на Linux и не поддерживается в Windows. ### тайм-аут `-x secs` позволяет указать тайм-аут. На практике это больше похоже на "примерное время между итерациями" для CLI-целей и фактический тайм-аут для GUI. ### мутаторы `--mutator N` указывает, какой мутатор использовать для фаззинга. Если опция не указана, для каждой итерации фаззинга случайным образом выбирается мутатор из списка доступных. Эти мутаторы были написаны с нуля (за исключением, конечно, Radamsa). И хотя они были тщательно протестированы и хорошо работали в течение миллионов итераций, время от времени в них могут быть скрытые ошибки, но в целом это не должно влиять на функциональность.``` FLIP_MUTATOR = 1 HIGHLOW_MUTATOR = 2 INSERT_MUTATOR = 3 REMOVE_MUTATOR = 4 CARVE_MUTATOR = 5 OVERWRITE_MUTATOR = 6 RADAMSA_MUTATOR = 7

### пауза Нажмите ctrl+c, чтобы приостановить процесс фаззинга. Если хотите продолжить, выберите `y` или `n` для остановки. Эта функция работает нормально на разных платформах, но может быть менее надежной при фаззинге GUI-приложений. ### повторное использование сбоев для поиска вариантов `-e` включает режим повторного использования. Это означает, что если во время сеанса фаззинга были найдены сбои, они будут использованы в качестве входных данных для второго раунда фаззинга, что может помочь выявить ещё больше ошибок. Комбинируйте с `-z` для `-ez` ошибок! Да-дуф. Следующий пример демонстрирует фаззинг antiword с 100000 итераций, а затем запуск другого прогона с тем же количеством итераций и опциями для повторного использования сбоев в качестве входных данных, чтобы попытаться выявить ещё больше ошибок. `litefuzz -l -c "antiword FUZZ" -i docs -n 100000 -ez` (или можно вручную скопировать сбои в каталог входных данных, чтобы напрямую управлять итерациями для повторного прогона) `litefuzz -l -c "antiword FUZZ" -i docs-crashes -n 500000 -z` примечание: этот режим поддерживается только для локальных приложений. ### помощники отладки памяти `-z` включает Electric Fence (или отладку malloc glibc в качестве запасного варианта) на Linux, Guard Malloc на Mac и PageHeap на Windows. Также `-zz` можно использовать для отключения PageHeap после его включения для приложения. Если вы хотите просто включить/выключить его без запуска фаззера, просто опустите флаг `-i`. Во время установки Windows устанавливается [gsudo](https://github.com/gerardog/gsudo), который можно использовать для выполнения команд с повышенными привилегиями в командной строке, например, для включения PageHeap для целей. `sudo litefuzz -l -c "notepad FUZZ" -i texts/files -z` `sudo litefuzz -l -c "notepad FUZZ" -zz` На Linux можно выбрать конкретных помощников. Например, вместо использования glib malloc в качестве запасного варианта, его можно выбрать явно. `litefuzz -l -c "geany FUZZ" -i texts/codes -z glibc` Отладчик malloc Electric Fence по умолчанию отличный, но он работает не со всеми целями. Вы можете протестировать цель с EF, и если она упадёт, выберите помощник glibc вместо него. ### проверка вывода работающей цели Если вы проводите фаззинг локальных приложений на Linux или Mac, вы можете выполнить `cat /tmp/litefuzz/RUN_ID/fuzz.out`, чтобы проверить последний stdout цели. `RUN_ID` отображается в области информации STATS при запуске фаззинга. В случае возникновения сбоя stdout также сохраняется в каталоге сбоев как файл `.out`. Глобальный stdout/stderr также записывается в `/tmp/litefuzz/out` для целей отладки для всех целей фаззинга, за исключением изолированного или локального серверного режимов, где вывод отладчика идет в `/tmp/litefuzz/RUN_ID/out`. Winappdbg изначально не поддерживает захват stdout целей (насколько мне известно), поэтому этот артефакт недоступен на Windows. ### режимы клиента и сервера Если сервер может быть запущен локально простым выполнением бинарного файла (с некоторыми флагами и конфигурацией или без них), вы можете передать его командную строку с помощью `-c`, и он будет запущен, подвергнут фаззингу и завершен с новым запуском на каждой итерации. Идея здесь в том, чтобы обменять скорость на возможность избежать тех надоедливых ошибок, которые проявляются только после того, как память цели находится в "определенном состоянии", что может приводить к ложным срабатываниям. То же самое касается локального фаззинга сетевых клиентов. Он даже поддерживает TLS-соединения, генерируя сертификаты на лету (предоставление пользователем клиентского сертификата при фаззинге сервера, который этого требует, и фаззинг самих сертификатов — другие идеи здесь). Поддержка отладки не предоставляется Litefuzz при фаззинге удаленных клиентов и серверов, поэтому настройка на удаленном конце остается на усмотрение пользователя. Для серверов мы просто проверяем, перестал ли сервер отвечать, и отмечаем предыдущую полезную нагрузку как причину сбоя. Это хорошо работает для TCP-соединений, но для UDP-сервисов такой роскоши у нас нет, поэтому мониторинг удаленного сервера остается на усмотрение функции ReportCrash (доступна на Mac), запуска цели в отладчике (через локальный серверный режим или вручную) или создания пользовательских вспомогательных скриптов. Кроме того, некоторые серверы могут автоматически перезапускаться или иным образом восстанавливаться после сбоя, но могут быть признаки этого в журналах или других артефактах файловой системы, которые могут быть проанализированы вспомогательными скриптами, написанными для конкретной цели. ### примеры локальной сети `litefuzz -lk -c "wget http://localhost:8080" -a tcp://localhost:8080 -i input/http -z` `litefuzz -lk -c "curl -k https://localhost:8080" -a tcp://localhost:8080 -i input/http -z` `litefuzz -lk -c "curl -k https://localhost:8080" -a tcp://localhost:8080 -i input/http -o crashes/curl --tls -n 100000 -z` (откройте Wireshark и захватите ответ от d, щелкните правой кнопкой мыши Simple Network Management Protocol -> Export Packet Bytes -> resp.bin) `litefuzz -lk -c "snmpwalk -v 2c -c public localhost:1616 1.3.6.1.2.1.1.1" -a udp://localhost:1616 -i input/snmp/resp.bin -n 1 -d -x 3` `litefuzz -ls -c "./sc_serv shoutcast.conf" -a localhost:8000 -i input/shouts -z` `litefuzz -ls -c "snmpd" -i input/snmp -a udp://localhost:161 -z` **краткие замечания** - UDP-сокеты могут вести себя немного странно на Mac + Py2, поэтому протестирован и поддерживается только Mac + Py3 - Фаззинг клиентов локальной сети на Windows может быть глючным и на данный момент считается экспериментальным ### примеры удаленной сети Фаззинг удаленных клиентов и серверов немного сложнее: у нас нет локальной отладки, и мы полагаемся на обнаружение остановки взаимодействия между двумя сторонами по сети, чтобы зафиксировать сбои. Кроме того, поскольку мы предположительно не видим, что происходит на другом конце, фаззинг заканчивается, когда клиент или сервер перестает отвечать, и его необходимо перезапустить вручную после восстановления клиента или сервера до нормального (нерабочего) состояния, если только у пользователя нет скриптов на удаленной стороне для управления этим процессом. UDP еще больше усложняет ситуацию. Даже отправка тестового пакета, чтобы проверить, есть ли на UDP-порту прослушивающий сервис, не гарантирует ответа. Таким образом, можно удаленно фаззить сетевые клиенты и серверы, но приходится жертвовать видимостью. #### клиент `while :; do echo "user test\rpass test\rls\rbye\r" | ftp localhost 2121; sleep 1; done` `litefuzz -k -i input/ftp/test -a tcp://localhost:2121 -pp -n 100` Режим клиента здесь более капризный, потому что трудно определить, действительно ли клиент упал, поэтому он не переподключается, или же танец отправки/приема просто нарушен, поскольку разные клиенты могут обрабатывать соединения как им угодно. Также обратите внимание, что это всего лишь пример, и удаленный фаззинг клиентов по своей сути сложен и должен считаться несколько экспериментальным. #### сервер Плюсы и минусы фаззинга сервера локально или удаленно могут помочь вам принять решение о том, как подойти к цели, когда доступны оба варианта. В основном, фаззинг с сервером в отладчике будет медленнее, но вы сможете получить журналы сбоев с автоматической сортировкой, тогда как фаззинг сервера в удаленном режиме (даже с указанием на localhost) будет в среднем намного быстрее, но вы теряете высокую видимость и возможности сортировки на основе отладчика, но это даст вам время вручную перезапускать сервер после каждого сбоя, чтобы продолжать, пока он не завершится (только для TCP-серверов, функция не поддерживает UDP-серверы). **Shoutcast** `./sc_serv ...` `litefuzz -s -a localhost:8000 -i input/shouts -n 10000` **SSHesame** `sshesame` `litefuzz -s -a tcp://target:2022 -i input/ssh-server -p -n 1000000 -x 0.05` **FTP** `litefuzz -s -a tcp://target:21 -i input/ftp/req.txt -pp -n 1000` **DNS** `coredns -dns.port 10000` `litefuzz -ls -c "coredns -dns.port 10000" -a udp://localhost:10000 -i dns-req/1.bin -o crashes/coredns -n 10000` или `litefuzz -s -a udp://localhost:10000 -i dns-req/1.bin -o crashes/coredns -n 10000` ##### TLS `litefuzz -s -a tcp://hostname:8080 -i input/http --tls -n 10000```` ... @ 48/10000 (1 crashes, 0 duplicates, ~7:13:18 remaining) [!] check target, sleeping for 60 seconds before attempting to continue fuzzing...

Фаззер разбивает каждую строку на собственный FTP-ответ, чтобы попытаться фаззить обработку сессии клиентом. Однако нет гарантии, что клиент будет «вести себя» или действовать так, чтобы сессия завершилась корректно, поэтому некоторые пробы и настройка тестовых сценариев сессии с одновременным запуском Wireshark могут помочь понять различия во взаимодействии между целями. `litefuzz -lk -c "ftp localhost 2121" -a tcp://localhost:2121 -i input/ftp -o crashes/ftp -n 100000 -pp -z` Это также можно комбинировать с *-u* для изоляции GUI-сетевых целей, таких как FileZilla. `litefuzz -lk -c "filezilla" -a tcp://localhost:2121 -i input/ftp.resp -n 100000 -u -pp -z glibc` ### прикрепление к процессу Если цель порождает новый процесс при подключении, можно указать имя процесса (или PID) для прикрепления после того, как соединение с сервером было установлено. Это удобно в случаях, когда, например, launchd прослушивает порт и запускает обрабатывающий процесс только после подключения клиента. Это одна из функций, которая несколько размывает границу между локальным и удалённым фаззингом, так как технически фаззер находится в удалённом режиме, но мы указываем целевой адрес как localhost и просим его прикрепиться к процессу. `./litefuzz.py -s -a tcp://localhost:8080 -i input/shareserv -p --attach ShareServ -x 1 -n 100000` примечание: в настоящее время эта функция поддерживается только на Mac (LLDB) и для сетевого фаззинга, хотя, если её реализовать, она должна работать и на Linux (GDB). ### артефакты краша Когда во время фаззинга происходит краш, он воспроизводится в отладчике для создания отладочных артефактов и информации для группировки. Информация варьируется от платформы к платформе, но в целом создаётся текстовый файл с бэктрейсом, информацией о регистрах, данными типа `!exploitable` (где доступно) и другой базовой информацией. **Дампы памяти** можно включить в Windows, передав `--memdump`, или отключить с помощью `--nomemdump` аналогично тому, как отладчиками malloc управляют через `-z` и `-zz` соответственно. Если включено, дамп также будет загружен в консольный отладчик (cdbg), а результат анализа краша `!analyze -v` будет захвачен в дополнительном логе анализа краша с дампом памяти. Winappdbg уже содержит анализ типа !exploitable, который мы получаем при первоначальном анализе краша, поэтому здесь мы выполняем только !analyze. `litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --memdump` или чтобы отключить дампы памяти для приложения `litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --nomemdump` В дополнение к автоматической сортировке крашей также создаются бинарные/строковые diffs (по необходимости) и stdout цели (зависит от платформы/цели), а также, конечно, repro-файлы. Для локального фаззинга артефакты обычно включают diffs, stdout (только linux/mac), repro-файл и лог краша с файлом информации.``` $ ls crashes/latex PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.diff PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.diffs PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.out PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.tex PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.txt

# трофеи Litefuzz выявил сбои в различных программных пакетах, таких как... * antiword * AppleScript (OS X) * ArangoDB VelocyPack * Avast authenticode-parser * Avast RetDec * BBC Audio Waveform * ColorSync (OS X) * Dynamsoft BarcodeReader * eot2ttf * evernote2md * faad2 * Facebook's Origami Studio * FontForge * ForestDB * Gifsicle * GPUJPEG * GPAC Multimedia Framework * Google Draco * Google Quipper * GoPro GPR * GtkRadiant * IIPImage Server * John The Ripper * Kyoto Cabinet * latex2rtf * libMeshb * libembroidery * libsndfile * Lion Vector Graphics (lvg) * L-SMASH * mp3-decoder * MindNode * minimp4 * MiniWeb Server * MLpack * Nvidia Data Center GPU Manager * Numbers (OS X) * OpenJPEG * OpenOrienteering Mapper * OSM Express * Pages (OS X) * PBRT-Parser * Pixar USD * Remote Apple Events (OS X) * Samsung rlottie * Samsung ThorVG * Shoutcast Server * Silo * syslog (OS X) * Tencent NCNN * TinyXML2 * UEFITool * Ulfius Web Framework * zlib # Часто задаваемые вопросы ## Как возник этот проект? Фаззинг — это весело! И приятно делать проекты, которые придерживаются контрарного взгляда: фаззеры не всегда обязаны следовать современным или популярным подходам для достижения конечной цели — поиска ошибок. Будь вы близки к «железу», получаете покрытие кода по всем путям или просто оптимизируете под быстроту и гибкость, используя фундаментальный метод «опровержения предположений» и т.д. Как бы это ни проявлялось, получайте удовольствие. ## Активно ли поддерживается этот проект? Пожалуйста, не ожидайте активной поддержки или сопровождения проекта. Смело форкайте его, чтобы добавлять новые функции или исправлять ошибки и т.п. Возможно, даже делайте PR для небольших изменений, хотя не ждите ответов или помощи в устранении неполадок. Разработка в этом репозитории не предполагается активной. ## Как узнать, что фаззер работает хорошо, и проводили ли вы его сравнение с другими? Цель Litefuzz — находить ошибки на разных платформах. И он это делает. Честно говоря, возможность сравнивать его с фаззером X или фаззером Y просто не попала в приоритеты. Определённые компромиссы были приняты и осознаны с самого начала; подробнее см. в [#intro](https://github.com/sec-tools/litefuzz/blob/main/README.md#intro). ## Что бы вы изменили, если бы переписывали его сегодня? Он работает достаточно хорошо в текущем виде и был протестирован на множестве различных целей и сценариев. Тем не менее, он мог бы выиграть от стандартизации на более модульной и плагинной системе, где переключение между целями и платформами не требовало бы стольких дополнительных проверок в операционной части кода и т.п. Конечно, наличие более формальных тестов и системы развёртывания, которая тестировала бы его на поддерживаемых ОС, создало бы среду, упрощающую работу при изменениях в основных функциях. Из небольшого, но амбициозного проекта он довольно быстро вырос во что-то большее. ## Насколько стабилен Litefuzz? Командная строка, графический интерфейс, сетевой фаззинг (в основном на Linux и Mac), минимизация и т.п. были протестированы довольно тщательно и в целом должны быть надёжными. Некоторые более экзотические функции, такие как изолированный сетевой фаззинг с GUI, поддержка ReportCrash для Mac и некоторые другие нишевые возможности, следует считать экспериментальными. ## Есть ли неподдерживаемые сценарии для Litefuzz? Да, некоторые. Но большинство из них — либо редкие сценарии, которые глючат, требуют больше времени и исследований для «правильной» реализации, либо просто не работают по причинам, связанным с платформой. Многие из них явно завершаются сообщением «не поддерживается», когда вы пытаетесь запустить их с такими опциями, и некоторые оговорки были упомянуты в разделах выше при описании различных функций. К более тонким моментам относится режим воспроизведения для *изолированных* приложений — не поддерживается, а также ограниченное тестирование приложений Mac с использованием функции изоляции. Pyautogui, похоже, хорошо работает на Linux и Windows, но на Mac он оказался не очень надёжным, поэтому считайте его функционально неподдерживаемым. Фаззинг клиентской части Windows может быть немного менее надёжным, чем другие режимы на других платформах. Возможны некоторые пограничные случаи, но наиболее распространённые сценарии локального и сетевого фаззинга протестированы и работают. А, это прелести написания кроссплатформенных инструментов: приятно, но трудно заставить всё работать отлично всё время. В целом фаззинг на Linux/Mac кажется более стабильным и поддерживает больше функций, особенно в плане сетевого фаззинга, который тестировался гораздо больше, чем на платформе Windows, но были предприняты усилия, чтобы на Win32 были доступны хотя бы основы и пара дополнительных возможностей. Не стесняйтесь форкать этот фаззер и вносить улучшения, добавлять поддержку того, что пока не поддерживается, и т.п., или делать PR для мелких, но полезных вещей. ## Какие гарантии предоставляются для этого проекта или его кода? Абсолютно никаких. Но это довольно весело — фаззить и наблюдать, как он выдаёт вам ошибки. # автор / ссылки - [Jeremy Brown](https://github.com/sec-tools/litefuzz/blob/main/jbrown3264%5BNOSPAM%5Dgmail) - [Слайды для macOS Fuzzing](https://www.slideshare.net/JeremyBrown37/summer-of-fuzz-macos)

litefuzz

Популярное

введение

пример docker

Create crashes directory

Run fuzzing with example input (1000 iterations with heap debugging)

примечания

тесты

модульные тесты

ReportCrash

режимы множественного обмена данными

golang

repros

remove file

minimization

команда

примеры

локальное приложение

быстрый просмотр```

перечисление обработчиков файлов в OS X

клиент

быстрый взгляд```

локальный сервер

удаленный сервер

командная строка```