Ловушка аудитора и недостаток валидации

Хочу поделиться с вами небольшими результатами своего "переобучения" в качестве аудитора за последние пару месяцев.

Как вы знаете, я решил научиться аудировать протоколы заново и с конца ноября экспериментировал с заметками. Основной целью я ставил перед собой - в короткое время научиться разбирать протокол и понимать, что за что отвечает.

В январе-начале февраля была немного другая цель - быстро генерировать потенциальные проблемы в контракте и отправлять максимум репортов. "Максимум" складывался за счет поиска паттернов, на основе прочитанных репортов и догадок, в ущерб валидации.

Что же можно сказать по итогам этого периода?

В общем плане, за два-три месяца скорость понимания кода значительно повысилась. Если раньше на 1000 строк могло уходить до 4-5 дней, то сейчас уже 1-2 дня. Когда я говорю про "понимание", то имею ввиду, что я могу, смотря на функцию, хорошо знать:

- что она делает;
- какие служебные вызывает;
- какие состояния контракта изменяет;
- куда и откуда переводятся токены;
- какие проверки есть или нет;
- есть ли зеркальные функции;

и т.д.

Заниматься по 3-4 часа в день, вполне адекватная нагрузка.

С репортами и поиском багов стало немного хуже.

За 4 недели (с 13.01 по 05.02) я посмотрел 5 конкурсных аудитов и написал 28 отчетов. Результатов еще официальный нет, но предварительные не особо радуют. Примерно 10 штук - это "дизайн протокола" - когда протокол понимает, что этот код может привести к проблемам, но берет ответственность за свои действия и не будет ничего менять в коде, около 6 репортов - уже известные проблемы, около 4 - из Med в Low/Info, еще 4 - валидные и остальные - не валидные.

Другими словами, из 28 отчетов будут приняты около 3-4.

Когда я провожу реальный аудит, я читаю документацию, повторяю EIP, которые используются в протоколе, смотрю тесты и комментарии, построчно иду по коду и часто пишу заказчикам, чтобы удостовериться в каком-либо моменте. Если не могу доказать баг тестами, то в репорте веду отдельный блок с комментариями по коду, на что нужно обратить внимание.

В конкурсных же аудитах я "забил" на валидацию в пользу количества репортов и затраченного времени.

Как вы сами можете видеть, это не окупается ни по работе, ни по оплате.

Короче - не делайте так. Репорты с недостаточной валидацией - отстой!

На ближайшее время хочу попробовать другой подход: вместо поиска паттернов и максимума отчетов, генерировать возможные пути атаки и валидировать их. Это сложно объяснить, но, например, вместо поиска слабых мест в контракте и его логике, искать способы атаки на эти места. Если не могу на 100% доказать такой факт, то репорт - мимо.

⚡️ И небольшое предложение для всех:

Если тоже учитесь аудитам и уже пробовали себя в конкурсах, то предлагаю "поковырять" один небольшой баг баунти с Immunefi. Создадим закрытый чат, скину репо и каждый день будем в чате обмениваться ходом аудита.

Что скажете, кто-нибудь хочет поучаствовать?

#audit