Зачем заморачиваться и тратить деньги и ресурсы на 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 и о том, почему все больше людей используют его в тестировании программ и как это повышает уровень безопасности разработок.
Автор: d1g1
