Зачем заморачиваться и тратить деньги и ресурсы на security? Зачем утруждать себя постановкой Security Development Lifecycle (SDL)? Зачем заниматься интеграцией fuzzing’а в процесс разработки? Зачем занимать голову знаниями о различных фаззерах типа AFL, libfuzz и т.д.? Ведь можно “просто” превратить поиск уязвимостей в своих продуктах в сплошное мучение и устроить исследователям и злоумышленникам “сладкую” жизнь. Хотите знать, как это сделать? Тогда добро пожаловать под кат!

Disclaimer: Данную статью стоит воспринимать с определенной долей юмора и иронии!

В последнее время появляется все больше работ, посвящённых теме AntiFuzzing’а. AntiFuzzing — это действие, уменьшающее эффективность и пользу fuzzing’a для поиска уязвимостей в решении(ях) разработчика.

В статье речь пойдет о fuzzing'е бинарных приложений, написанных на С\С++, которые можно развернуть локально, и попытаться найти в них уязвимости, связанные с повреждением памяти.

Сегодня большое количество действий нацелены против AFL фаззера, как наиболее яркого, известного и зарекомендовавшего себя представителя подхода feedback based fuzzing.

Изучив проблему, мы выделили возможные техники AntiFuzzing’а:

Захламление результатов работы фаззера — самая чудаковатая техника, которую некоторые разработчики берут на вооружение, сами того не осознавая) Заключается она в том, что, чтобы сделать программу безопаснее, надо добавить туда побольше багов… Да, мы, к сожалению, не можем ответить на вопрос, сколько в программе уже есть наших багов и насколько они опасны, но зато мы можем разбавить их кучей бесполезных для атакующего ошибками!
Детектирование процесса fuzzing’a — это все из области jailbreak_detect, root_detect. Приложение самостоятельно определяет (а разработчик пишет ряд проверок), что оно не просто работает, а фазится и в результате чего отказывается работать. Индустрия ИБ проходила это уже миллион раз. Данный код ищется и исключается из приложения довольно легко, а техника лидирует в звании “самой бесполезной и бесхитростной”.
Замедление процесса fuzzing’a — внутри нашей компании мы такие вещи называем «спрятать баги в overhead'ах». Даже сейчас некоторый софт работает плохо не только под fuzzing’ом, поэтому искать в нем уязвимости становится психологически сложной задачей для исследователей)
Создание blindspot зон — наиболее интересное направление, которое, на наш взгляд, и будет двигать эволюцию фаззеров. Так, в работе, представленной на BlackHat 2018, поднимается проблема коллизий в shared_mem у AFL, который использует ее для определения покрытых участков кода. То есть создаются области куда фаззер не попадает при своей работе.

Таким образом, у AntiFuzzing’a есть как очевидные преимущества, так и недостатки:

"-" Возможно помутнение рассудка у разработчиков ПО, которые плохо разбираются в некоторых аспектах информационной безопасности и процесса fuzzing'a.
"+" Эволюционирование фаззеров, которые в будущем начнут преодолевать внедренные механизмы AntiFuzzing’a и будут давать большее покрытие во-первых, при наличии внедренных механизмов AntiFuzzing’a; во-вторых, при существовании в ПО элементов, которые симулируют функции AntiFuzzing’a.

Почему использовать данный подход для обеспечения безопасности глупо и вредно? Разработка качественного AntiFuzzing подхода и его применения к реальному ПО по сложности сопоставима с разработкой самого алгоритма для увеличения покрытия кода при feedback based fuzzing. Сложность в том, что помимо того, чтобы вставить в нужные места затрудняющие фазинг конструкции, необходимо сделать так, чтобы у них не было четкого паттерна, который можно выделить, а дальше — просто исключить. AntiFuzzing не повышает безопасность самого приложения… Хорошо, что пока исследованиями AntiFuzzing’a занимаются только в академической среде. При этом, существуют компании, которые наоборот ориентированы на упрощение поиска багов. Например, Mozilla предоставляют для этого специальную сборку своего браузера blog.mozilla.org/security/2018/07/19/introducing-the-asan-nightly-project!

Всплеск интереса к AntiFuzzing’у вызван в первую очередь DARPA Cyber Grand Challenge 2016. Это соревнование, где компьютеры без помощи человека искали уязвимости, эксплуатировали и патчили их. В основе большинства систем для поиска, как вы могли догадаться, лежал AFL фаззер, а все цели на соревновании были бинарными приложениями. Всё это может быть направлено на противодействие автоматическим системам, а не людям.

Данная статья базируется на работах, которые вы можете изучить самостоятельно:

«Escaping the Fuzz Evaluating Fuzzing Techniques and Fooling them with AntiFuzzing», Master’s thesis in Computer Systems and Networks
2016
«Chaff Bugs: Deterring Attackers by Making Software Buggier», 2018
«AFL's Blindspot and How to Resist AFL Fuzzing for Arbitrary ELF Binaries», BlackHat USA 2018
Также советуем ознакомиться со статьей ребят из NCC Group «Introduction to Anti-Fuzzing: A Defence in Depth Aid» от 2014 года (первый релиз AFL только появился и еще не завоевал огромной любви сообщества, а до финала DARPA CGC еще 2 года).

P.S.: Мы часто работаем с AFL (+libfuzz) и его модификациями при исследовании ПО и внедрении SDL нашим клиентам. Поэтому в одной из следующих статей мы подробнее поговорим на тему fuzzing’a с помощью AFL и о том, почему все больше людей используют его в тестировании программ и как это повышает уровень безопасности разработок.

AntiFuzzing: Security through obscurity!?