Борис Рютин, Яндекс: Безопасники популяризировали фаззинг, но теперь его активно используют и разработчики, и QA

Борис Рютин, руководитель группы безопасности Алисы и Автономного транспорта «Яндекс», а также автор блога «О Fuzzing-тестировании», рассказал порталу Cyber Media, как работает фаззинг, какие виды фаззинг-тестов существуют, и какие преимущества он предоставляет. А также о инструментах и подходах, которые используются для эффективного фаззинг-тестирования.

Cyber Media: В чем разница между фаззингом и нагрузочным тестированием?

Борис Рютин: Хороший вопрос. Фаззинг, я бы сказал, больше про то, чтобы попытаться вызвать нестандартное поведение софта или сервиса, точнее - незапланированное разработчиком, хотя и согласен, что вряд ли обычно разработчик планирует, что сервис не выдержит нагрузки. Чаще всего считается, что результатом успешного фаззинга (для исследователя безопасности конечно успешного) это крэш, то есть явное падение приложения, но это и утечки памяти и получение доступа к данным к которым не планировался изначально доступ и прочее.

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

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

Для наглядности советую зайти на вики популярного инструментария для фаззинга - AFL. Логотипом ПО является кролик, поэтому в качестве демонстрации как изменяются данные во время фаззинга было взято изображения с кроликом из одной из редакций книги “Алиса в стране чудес”. В какие-то моменты фаззинга вы будете наблюдать эффект как в старом телевизоре, когда на экране появляется тестовая таблица с разными цветными полосками, а иногда это вообще не кролик, а что-то из Лавкрафта. Или можно за стартовый файл для фаззинга взять картинку с белым фоном любого размера, к примеру открыть новый файл в Paint и сразу сохранить, а далее начать мутировать данные. Чаще всего в ходе тестирования это будут всякие кляксы, которые временами похожи на те, из того самого теста Роршаха, или другие сюрреалистичные картинки.

Cyber Media: Для каких задач информационной безопасности чаще всего применяется фаззинг-тестирование?

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

Cyber Media: Какие инструменты вы считаете наиболее эффективными для проведения фаззинг тестирования?

Борис Рютин: Есть несколько популярных инструментов. Вот AFL, который я упомянул сегодня уже не раз, но сейчас чаще используется его наиболее популярный форк - AFL++, но и у него есть форки, чаще узкоспециализированные. К примеру, один из них используется для поиска ошибок в SSL библиотеках. То есть берется AFL и дополняется или изменяется кардинально один из функционалов. Сам AFL++ так и появился: Оригинальный AFL прекратили поддерживать, а у отдельных разработчиков копились разные патчи, пока не собралась группа энтузиастов, которые решили сделать единый форк. Они собрали все подходящие форки и объединили в один большой - AFL++.

Второй инструмент — это libFuzzer, который в свою очередь сделал фаззинг-тестирование более доступным для разработчиков. Он позволяет написать фаззинг-тест для одной функции библиотеки. AFL же проще всего использовать, когда компилируешь всю программу с какими-нибудь дополнительными механизмами и отправляешь туда данные на вход, а далее мониторится поведение, упала программа или нет или может что-то нестандартное вывелось. А благодаря libFuzzer можно написать фаззинг-тест для конкретной функции, что намного удобнее: не нужно компилировать всю программу, а например, только функцию, которая проверяет поле прозрачности в изображении.

Это далеко не все фаззинг-движки. Есть еще множество инструментов с разным количеством возможностей и под разные цели. Я бы отметил следующие: очень простой и легковесный radamsa, его даже часто встраивают в другие инструменты ИБ, в тот же Burp, в некотором роде альтернатива libfuzzer от Google - Honggfuzz, syzkaller - фаззер ядра Linux и не только.

Ну и нельзя забывать про Web - API фаззеры, например, RESTler от Microsoft, CATS или Shelob, который не могу не упомянуть, так как сам в нем участвовал. Он является частью другого большего проекта Bondifuzz. Это так называемая фаззинг-ферма, суть которых, если вкратце, оркестрация фаззинг-движками и их находками, в общем continuous fuzzing. Про него и альтернативы я рассказывал в прошлом году на конференции OFFZONE.

Может ли такое случится, что сервис упадёт под нагрузкой такого api-фаззера? Конечно, можно сказать, что вы заодно проводите нагрузочное тестирование. Но наша цель именно найти нестандартное поведение, поэтому в правилах различных багбаунти программ написано, что не сканьте / фаззьте больше какого-то rps или вообще не используйте такие инструменты.

Cyber Media: Вы рассказывали о фаззинге больше с точки зрения разработчиков, или внутренней службы ИБ, а используют ли фаззинг, как метод атаки, например, в рамках redteam-проектов?

Борис Рютин: Конечно, но напомню, что изначально такие инструменты и использовали в основном безопасники. Но те же, OpenAPI-фаззеры как раз и используют при редтиминге, конечно же в разрешенных случаях. Потому что можно повалить сервис своими запросами или что самое страшное — можно дернуть такие ручки, что путь останется один путь - восстановиться из бэкапа. Так что фаззинг-тестирование — это и про ИБ, и про разработчиков, и про QA.

Cyber Media: Как развитие технологий, в том числе ИИ/ML, повлияло на фаззинг-тестирование?

Борис Рютин: Появление облаков позволило делать кластеры, то есть масштабировать фаззинг-тестирование, раньше твои возможности чаще всего были ограничены CPU одной машины. Тут конечно впереди планеты всей Google: их проект ClusterFuzz, та самая фаззинг-ферма, позволяет на их облаках развернуть собственный инстанс и начать фаззинг-тестирование выбранных таргетов. Помимо этого у них есть oss-fuzz, который проводит постоянно фаззинг-тестирование множества проектов с открытым исходным кодом. Разработчики, если их продукт более-менее популярен, могут написать фаззинг-тест, положить в специальный репозиторий и Google на всех своих мощностях будут его фаззить.

В общем, облака позволили масштабировать и не проводить фаззинг-тестирование на своей локальной машине. Это самое любимое у всех, независимо от специальности: редтимер, разработчик или тестировщик. То есть, фаззинг-тестирование — это больше автоматическое тестирование: человек пишет фаззинг-тест, отправляет его и дальше может фаззить сколько угодно, пока сам не захочешь остановить или по каким-то параметрам решит, что дальше фаззинг-тестирование проводить бесполезно. Например, покрытие – позволяет увидеть, в какие функции доходит ваш фаззинг-тест. Если видите, что уже условные две недели, этот параметр каждый для себя сам выбирает, фаззинг тест до новых функций не доходит, то наверное, смысла фаззить больше нет. А если постоянно до новых мест библиотеке доходит, то есть смысл продолжать тестирование.

Теперь об ИИ. У него есть известная проблема — галлюцинирование. Когда генеративная сеть придумывает какой-нибудь выхлоп, но ведь это то же самое фаззинг-тестирование в некотором роде. Поэтому уже из коробки можно попытаться использовать ИИ для фаззинга и есть успешные попытки. Google выпустил проект, который называется oss-fuzz-gen. У Гугла уже есть репозиторий с готовыми фаззинг-тестами, его и использовали для обучения, остается указать только кодовую базу и конкретную функцию. Далее он находит конкретную функцию, генерирует под нее фаззинг-тесты и пытается скомпилировать. Если видит ошибку, отправляет ее снова в запрос и повторяет эту итерацию, пока не сгенерируется валидный фаззинг-тест без ошибки. И потом пробует его выполнить, то есть запустить непосредственно полноценное фаззинг-тестирование. Благодаря этому инженеры Google нашли баги, не все из них их опубликовали, но достаточное количество. Более того, некоторые фаззинг-тесты достаточно простые.

Есть еще концепт, который в принципе сам искусственный интеллект использует для фаззинг-тестирования. Человек дает задание генерировать что угодно и что ожидает программа и результат отправляется в программу пока она не упадет или что-то нестандартное не появится. Про это я рассказывал на Defcon Нижний Новгород.

Cyber Media: Если смотреть с точки зрения атакующих, то какими инструментами можно дополнить фаззинг-тестирование?

Борис Рютин: Его можно использовать с тем же статическим тестированием: SAST и DAST. В принципе фаззинг — это часть DAST, но некоторые для популяризации назвали его FAST. Плюс фаззинга в том, что все ошибки, которые ты найдешь — это реально ошибки. Они не обязательно связаны с ИБ, но это ошибка, потому что программа на нее как-то среагировала, например, зависла. Это кстати тоже один из валидных кейсов. В моей практике было, что фаззинг вроде не приметил, что программа упала, она зависла. А потом проверили и оказалась реальная уязвимость - была проблема с памятью.

А с SAST наоборот очень много фолсов, нет уверенности, что это баг. Соответственно, как можно объединить? Благодаря SAST вы находите определенные области исходного кода, места и пишете конкретно под эту область фаззинг-тест. Например, возьмем прозрачность картинки. Вы видите, что что-то не так с этим кодом, генерируете фаззинг-тест под эту функцию и запускаете фаззинг-тестирование. Если условно две недели ничего дальше не проходит и никаких проблем не замечено, то значит это скорее всего фолс.

Есть еще разные вариации тестирования вроде IAST, но их примеров не так много, но они по факту объединяют эти принципы. То, про что я рассказывал — это гибридное тестирование, когда вы используете несколько разных инструментов, а IAST — это полноценный инструмент.

Cyber Media: Исходя из вашего опыта, какие наиболее частые ошибки совершают специалисты при проведении фаззинг-тестирования? Что важно учесть и на что обратить внимание, чтобы минимизировать риски?

Борис Рютин: Частую ошибку я бы назвал - как раз отсутствие фаззинг-тестирования. В качестве минимизации я бы назвал — не фаззить прод, не зря упомянул, что нужно фаззить тестовое окружение, потому что вы не контролируете, что вы сгенерируете. Есть же притча, что если посадить миллион обезьянок, то они могут написать «Войну и мир» (в некоторых источниках это называют теоремой о бесконечных обезьянах). Может ли случиться такое, что вы сгенерируете такой запрос, который к примеру удалит данные? Почему бы и нет. Если взять тот же api-фаззер и вы тестируете админку от пользователя с правами администратора, то это довольно опасно. Потому что вы по умолчанию не контролируете что и как будет изменять фаззер, для него условно ручки add_data и delete_data будут равнозначны. Забавно, но иногда предком фаззинг-тестирования называют monkey testing.