Как читать аудиторские отчеты

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

Есть несколько видов отчетов, которые я разделяю для себя:

1) Отчеты от конкурсных площадок, типа с4 или Шерлок;
2) Отчеты от компаний, типа trail of bits;
3) Отчеты от соло-аудиторов, типа trust;
4) Отчеты по взломам, типа блога Immunefi;

Для каждого из них у меня слегка различный подход цели изучения. Но сначала об общих чертах.

1. Самое главное - не весь отчет (не все баги) иногда можно понять и разобрать. Это абсолютно нормально, если вы не понимаете какой-либо момент или описание уязвимости. Особенно в High Risk разделе.

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

Смело пропускайте такие описания.

2. Для меня в чтении отчетов важно понимать суть уязвимости. Для этого вы можете завести свою небольшую таблицу, куда записывать баги по разделам: Access control, reentrancy, division, и т.д. И потом добавлять записи туда, например, "забыли поставить модификатор", "из-за того, что деление идет раньше умножения теряется точность" и все в этом духе.

Вы даже можете завести свой канал в Телеграме и скидывать туда пример кода и краткое описание. Для вашего личного обучение - это будет очень хорошо.

3. 99% всех проблем с газом и около 80% low-level популярных уязвимостей можно уместить в список из 50 пунктов. Звучит странно, но так и есть. Вы вполне можете составить свой из отчетов на code4rena и просто выучить его. Это проще, чем кажется. Зато в отчетах вы сможете бегло просматривать эти разделы и обращать внимание только на что-то уникальное.

4. High и Med уязвимости нужно изучать, открывая ссылки с кодом или примером в описании бага. Здесь важно получить "насмотренность" в коде, чтобы научиться определять такие же моменты в других проектах.

5. Обращайте внимание на то, как именно составлены описания уязвимостей, в смысле формат текста: что пишут в "impact", что в "PoC", что в "Recommendation". Это будет важно, когда вам потребуется самим отправлять отчеты. На эту темы позже будет еще один пост.

Теперь пройдемся по различиям в аудиторских отчетах.

1. На конкурсных площадках я обращаю внимание на формат описания уязвимостей, на их подачу. Это сложно объяснить словами, но, прочитав хотя бы по 20 отчетов с code4rena и Шерлока, вы сможете увидеть некоторую разницу. То, что на одной площадке может проходить как Med, на другой пойдет, как High.

2. В "соло" отчетах мне всегда было интересно следить за ходом мысли аудитора. Прочитав отчеты trust, можно начать понимать, на что он обращает внимание и как ведет свой процесс аудита.

3. В разборах уязвимостей от Immunefi мне было интересно те нюансы, из-за которых происходили взломы. Более того, очень часто они выставляют код для теста взлома. Будет очень хорошо, если вы повторите его у себя в Ремиксе или другом ide. Тесты крайне важны в аудите! А Immunefi дают прекрасные примеры!

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

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

Надеюсь, этот длиннопост поможет вам наладить свой процесс с обучением.

#audit #report