На четвертом этапе мой подход стал в значительной степени основан на интуиции. Я больше не чувствовал необходимости начинать с самого начала контракта или следовать строгому порядку строк. Вместо этого я начинал с произвольного места в архитектуре и первые несколько дней изучал кодовую базу в свободном порядке:
1. Lead-Based Auditing: Вместо того чтобы систематически прорабатывать функции, я составлял список потенциальных зацепок, следуя своей интуиции в тех областях, которые, как я подозревал, могли иметь уязвимости. Интересно, что к тому времени интуиция была уже настолько развита, что я мог найти множество зацепок/потенциальных зацепок в течение первых нескольких минут.
2. Глубокое понимание архитектуры: Такой свободный подход дал мне отличное понимание архитектуры контракта. Я начал раскрывать теоретико-игровые сценарии и сложные уязвимости, которые могли быть скрыты при обычном аудите.
3. Высокая степень успешности интуиции: На этом этапе моя интуиция стала важнейшим инструментом. Благодаря многолетнему опыту я мог чувствовать, какие области кода могут содержать уязвимости. Часто я обнаруживал серьезные проблемы, основываясь исключительно на этом ощущении.
Эта эволюция моего подхода означала, что я мог оценивать не только безопасность отдельных функций, но и безопасность всей структуры и замысла протокола, включая очень сложные проблемы, которые трудно было объяснить, «как я их нашел».
Я достиг того момента, когда стал достаточно уверенным, чтобы сказать, что при достаточной тщательности и затрате времени я способен обнаружить около 95 % всех проблем. Это подтверждалось снова и снова при участии в командных аудитах.
Это не означает, что мой подход к аудиту в наши дни основан исключительно на интуиции. Это лишь одна из многих составляющих моей методологии полного аудита.
Размышления: Как опыт формирует подходы к аудиту
С годами мой подход к аудиту трансформировался из детального, построчного процесса в тот, который был обусловлен интуицией и пониманием архитектуры. По мере накопления опыта я понял, что, хотя базовые навыки и систематические подходы имеют решающее значение на начальном этапе, интуиция и глубокое понимание динамики контрактов становятся бесценными инструментами для обнаружения самых сложных уязвимостей.
По мере накопления знаний и опыта интуиция аудитора становится одним из самых надежных ресурсов. Эта интуиция позволяет нам видеть дальше синтаксиса и погружаться в логику и стратегию кода, обнаруживая уязвимости, которые практически незаметны при стандартном аудите. Есть некоторые действительно важные проблемы, которые другие члены команды не могли воспроизвести даже тогда, когда я говорил им, где и что искать, просто потому, что для воспроизведения ошибки требовалось несколько различных последовательных переходов состояния, прежде чем она становилась видимой.
#audit
1. Lead-Based Auditing: Вместо того чтобы систематически прорабатывать функции, я составлял список потенциальных зацепок, следуя своей интуиции в тех областях, которые, как я подозревал, могли иметь уязвимости. Интересно, что к тому времени интуиция была уже настолько развита, что я мог найти множество зацепок/потенциальных зацепок в течение первых нескольких минут.
2. Глубокое понимание архитектуры: Такой свободный подход дал мне отличное понимание архитектуры контракта. Я начал раскрывать теоретико-игровые сценарии и сложные уязвимости, которые могли быть скрыты при обычном аудите.
3. Высокая степень успешности интуиции: На этом этапе моя интуиция стала важнейшим инструментом. Благодаря многолетнему опыту я мог чувствовать, какие области кода могут содержать уязвимости. Часто я обнаруживал серьезные проблемы, основываясь исключительно на этом ощущении.
Эта эволюция моего подхода означала, что я мог оценивать не только безопасность отдельных функций, но и безопасность всей структуры и замысла протокола, включая очень сложные проблемы, которые трудно было объяснить, «как я их нашел».
Я достиг того момента, когда стал достаточно уверенным, чтобы сказать, что при достаточной тщательности и затрате времени я способен обнаружить около 95 % всех проблем. Это подтверждалось снова и снова при участии в командных аудитах.
Это не означает, что мой подход к аудиту в наши дни основан исключительно на интуиции. Это лишь одна из многих составляющих моей методологии полного аудита.
Размышления: Как опыт формирует подходы к аудиту
С годами мой подход к аудиту трансформировался из детального, построчного процесса в тот, который был обусловлен интуицией и пониманием архитектуры. По мере накопления опыта я понял, что, хотя базовые навыки и систематические подходы имеют решающее значение на начальном этапе, интуиция и глубокое понимание динамики контрактов становятся бесценными инструментами для обнаружения самых сложных уязвимостей.
По мере накопления знаний и опыта интуиция аудитора становится одним из самых надежных ресурсов. Эта интуиция позволяет нам видеть дальше синтаксиса и погружаться в логику и стратегию кода, обнаруживая уязвимости, которые практически незаметны при стандартном аудите. Есть некоторые действительно важные проблемы, которые другие члены команды не могли воспроизвести даже тогда, когда я говорил им, где и что искать, просто потому, что для воспроизведения ошибки требовалось несколько различных последовательных переходов состояния, прежде чем она становилась видимой.
#audit
🔥4🤔2👍1
Выводы и заметки по аудиту One World
Буквально вчера закончился еще один небольшой аудит на платформе Codehawks и я делаю небольшой обзор и выводы после него.
В этот раз размер протокола был немного меньше, чем в прошлый раз - 541 строка кода против 699 в Sablier Flow, однако его качество было в разы хуже предыдущего. В итоге я потратил около 9-10 часов, понял примерно 98% кода и отправил 7 репортов. Ожидаю, что примут 2-3, а остальные будут в разряде "так запланировано протоколом". Я отправил все, так как указал бы те же самые проблемы, если бы делал соло аудит. Ждем предварительных результатов.
А пока небольшая подсказка для начинающих аудиторов, которые еще только учатся безопасности и аудиту.
Много протоколов, которые выходят на конкурсные площадки, уже ранее проводили аудит и делают дополнительный шаг с той же кодовой базой. Это хорошая практика, которая может помочь и вам.
Дело в том, что некоторые баги остаются "Acknowledged" - т.е. разработчики как бы приняли к сведению эту проблему, но пока не собираются исправлять ее. Более того, такие находки уже будут не валидны на конкурсе.
Другими словами это баги, которые остались в текущих контрактах.
Вы можете делать даже "тихий" аудит - без подачи репортов, если не уверены в своих силах - и искать проблемы в контрактах. После того, как вы поняли на достаточном уровне код, то открываете отчет и сверяетесь со своими заметками. Если найдете хотя бы пару Acknowledged багов сами - то вы уже готовы к полноценному участию в конкурсе.
В целом, написание заметок по аудиту и последующее прочтение отчета, помогло мне не только понять, что некоторые баги не нужно подавать, так как они не будут засчитаны, но и понять новые направления, где можно найти другие проблемы.
Я не стараюсь писать красиво (хотя бы потому что на столе мало место рядом с клавиатурой, мышью, саундбаром, планшетом и другой техникой (да кого я обманываю, у меня просто корявый почерк...)), главное что бы я мог быстро понять по ключевым словам, что имелось ввиду.
В этот раз мне помогло некоторое разделение заметок по контрактам. Я писал название контракта, и затем то, что считал важным. Когда закончил уже со всеми контрактами, то делал общие заметки - кросс-функций и кросс-контрактов.
Красным цветом отмечал места, где полагал есть уязвимости. Как вы можете увидеть, многие баги не подтвердились.
Будет интересно почитать другие находки, так как их будет куда больше, чем я предполагаю. У меня уже сегодня перед написанием этого поста пришла мысль по багу, но репорт отправить уже нельзя...
Ну, что же, ждем результатов.
P.S. Заметки очень сильно помогают быстрее понять контракт! Прям рекомендую делать их!
А можем вы хотите небольшое видео или стрим, по прошедшим аудитом с разбором и тем, как я это сам проходил?
#audit
Буквально вчера закончился еще один небольшой аудит на платформе Codehawks и я делаю небольшой обзор и выводы после него.
В этот раз размер протокола был немного меньше, чем в прошлый раз - 541 строка кода против 699 в Sablier Flow, однако его качество было в разы хуже предыдущего. В итоге я потратил около 9-10 часов, понял примерно 98% кода и отправил 7 репортов. Ожидаю, что примут 2-3, а остальные будут в разряде "так запланировано протоколом". Я отправил все, так как указал бы те же самые проблемы, если бы делал соло аудит. Ждем предварительных результатов.
А пока небольшая подсказка для начинающих аудиторов, которые еще только учатся безопасности и аудиту.
Много протоколов, которые выходят на конкурсные площадки, уже ранее проводили аудит и делают дополнительный шаг с той же кодовой базой. Это хорошая практика, которая может помочь и вам.
Дело в том, что некоторые баги остаются "Acknowledged" - т.е. разработчики как бы приняли к сведению эту проблему, но пока не собираются исправлять ее. Более того, такие находки уже будут не валидны на конкурсе.
Другими словами это баги, которые остались в текущих контрактах.
Вы можете делать даже "тихий" аудит - без подачи репортов, если не уверены в своих силах - и искать проблемы в контрактах. После того, как вы поняли на достаточном уровне код, то открываете отчет и сверяетесь со своими заметками. Если найдете хотя бы пару Acknowledged багов сами - то вы уже готовы к полноценному участию в конкурсе.
В целом, написание заметок по аудиту и последующее прочтение отчета, помогло мне не только понять, что некоторые баги не нужно подавать, так как они не будут засчитаны, но и понять новые направления, где можно найти другие проблемы.
Я не стараюсь писать красиво (хотя бы потому что на столе мало место рядом с клавиатурой, мышью, саундбаром, планшетом и другой техникой (да кого я обманываю, у меня просто корявый почерк...)), главное что бы я мог быстро понять по ключевым словам, что имелось ввиду.
В этот раз мне помогло некоторое разделение заметок по контрактам. Я писал название контракта, и затем то, что считал важным. Когда закончил уже со всеми контрактами, то делал общие заметки - кросс-функций и кросс-контрактов.
Красным цветом отмечал места, где полагал есть уязвимости. Как вы можете увидеть, многие баги не подтвердились.
Будет интересно почитать другие находки, так как их будет куда больше, чем я предполагаю. У меня уже сегодня перед написанием этого поста пришла мысль по багу, но репорт отправить уже нельзя...
Ну, что же, ждем результатов.
P.S. Заметки очень сильно помогают быстрее понять контракт! Прям рекомендую делать их!
А можем вы хотите небольшое видео или стрим, по прошедшим аудитом с разбором и тем, как я это сам проходил?
#audit
🔥11👍5❤2
Заметки по аудиту vVv Launchpad
На прошлой неделе увидел, что на Шерлоке будет небольшой конкурс с четверга по воскресенье, всего 279 строк кода, и решил "залететь" на него.
К слову сказать, я не участвовал в аудитах на этой платформе около двух лет! Меня всегда сильно смущало разделение пула (когда его львиная доля уходит назначенному топу) и некоторые проблемы с судейством. Но это только мое мнение и мой выбор игнорирования этой площадки.
Но сейчас у меня другая цель - быстрое понимание протокола, и, по сути, мне не важны ни судейство, ни размер выигрыша. Поэтому решил попробовать и там.
Также стоит отметить, что Шерлок недавно изменил систему судейства, а также форму подачи самого репорта. Поэтому, если вы соберетесь участвовать в их конкурсе, оставьте время, чтобы разобраться, как правильно подавать отчет по багу. Оставив все на последний момент, можно не успеть добавить все репорты.
P.S. Документации с описанием подачи репортов я не нашел. Если скинете ссылку в комментах, буду признателен.
Из-за моего некоторого предубеждения к этой платформе, я потратил всего 3 часа на аудит и отправил 5 репортов. Один пометил как Low, и он не попал в список на судейство. Вообще не понял почему, и как это исправить, ведь теги к отчету нельзя менять после завершение конкурса. При этом я также не увидел никаких пунктов о том, что Low не попадают в общую базу для судейства...
Также другие 2 репорта отправил, чтобы узнать больше о правилах судейства на платформе. Есть некоторые виды уязвимостей, которые могут быть валидны на одной платформе и нет - на другой. Посмотрим, как будет тут.
Обидно, что когда писал этот пост, увидел еще один очень простой и очевидный баг, но время уже прошло...
Что я могу сказать по этому протоколу?
Если вы знаете самые распространенные проблемы с подписями и EIP712, то у вас могли бы быть первые зачтенные баги на этой платформе.
Вы можете и сейчас попрактиковаться с этим аудитом, зайдя на страницу:
https://audits.sherlock.xyz/contests/647?filter=scope
и изучив эти два контракта. Вот прям открывайте solodit и EIP712, и сверяйте код.
Еще одна подсказка по работе со сложными структурами.
В контракте был такой struct:
Потратив некоторое время, конечно, можно и разобраться и понять каждую переменную. Но нам нужно запоминать все быстрее. Поэтому можно в заметках делать простые таблицы, как у меня на скрине, и разбивать их по логическим блокам:
- что относится к инвестиционному раунду;
- что к пользователю;
- что к подписи (так как это структура для ser signature).
В итоге у меня получилось:
1. Round: limit, start/end, token;
2. User: address, max amount limit;
3. Token: fee, exchange;
4. Signature: deadline, sign;
Скажите же, что так проще ориентироваться?
Я часто встречал большие структуры в протоколах, но никогда ранее не пробовал их упрощать у себя в заметках. Теперь буду так делать всегда.
Ну, что же, ждем результаты и движемся дальше!
Приятной рабочей недели и легкого обучения!
#audit
На прошлой неделе увидел, что на Шерлоке будет небольшой конкурс с четверга по воскресенье, всего 279 строк кода, и решил "залететь" на него.
К слову сказать, я не участвовал в аудитах на этой платформе около двух лет! Меня всегда сильно смущало разделение пула (когда его львиная доля уходит назначенному топу) и некоторые проблемы с судейством. Но это только мое мнение и мой выбор игнорирования этой площадки.
Но сейчас у меня другая цель - быстрое понимание протокола, и, по сути, мне не важны ни судейство, ни размер выигрыша. Поэтому решил попробовать и там.
Также стоит отметить, что Шерлок недавно изменил систему судейства, а также форму подачи самого репорта. Поэтому, если вы соберетесь участвовать в их конкурсе, оставьте время, чтобы разобраться, как правильно подавать отчет по багу. Оставив все на последний момент, можно не успеть добавить все репорты.
P.S. Документации с описанием подачи репортов я не нашел. Если скинете ссылку в комментах, буду признателен.
Из-за моего некоторого предубеждения к этой платформе, я потратил всего 3 часа на аудит и отправил 5 репортов. Один пометил как Low, и он не попал в список на судейство. Вообще не понял почему, и как это исправить, ведь теги к отчету нельзя менять после завершение конкурса. При этом я также не увидел никаких пунктов о том, что Low не попадают в общую базу для судейства...
Также другие 2 репорта отправил, чтобы узнать больше о правилах судейства на платформе. Есть некоторые виды уязвимостей, которые могут быть валидны на одной платформе и нет - на другой. Посмотрим, как будет тут.
Обидно, что когда писал этот пост, увидел еще один очень простой и очевидный баг, но время уже прошло...
Что я могу сказать по этому протоколу?
Если вы знаете самые распространенные проблемы с подписями и EIP712, то у вас могли бы быть первые зачтенные баги на этой платформе.
Вы можете и сейчас попрактиковаться с этим аудитом, зайдя на страницу:
https://audits.sherlock.xyz/contests/647?filter=scope
и изучив эти два контракта. Вот прям открывайте solodit и EIP712, и сверяйте код.
Еще одна подсказка по работе со сложными структурами.
В контракте был такой struct:
struct InvestParams {
uint256 investmentRound;
uint256 investmentRoundLimit;
uint256 investmentRoundStartTimestamp;
uint256 investmentRoundEndTimestamp;
address paymentTokenAddress;
address kycAddress;
uint256 kycAddressAllocation;
uint256 amountToInvest;
uint256 exchangeRateNumerator;
uint256 feeNumerator;
uint256 deadline;
bytes signature;
}Потратив некоторое время, конечно, можно и разобраться и понять каждую переменную. Но нам нужно запоминать все быстрее. Поэтому можно в заметках делать простые таблицы, как у меня на скрине, и разбивать их по логическим блокам:
- что относится к инвестиционному раунду;
- что к пользователю;
- что к подписи (так как это структура для ser signature).
В итоге у меня получилось:
1. Round: limit, start/end, token;
2. User: address, max amount limit;
3. Token: fee, exchange;
4. Signature: deadline, sign;
Скажите же, что так проще ориентироваться?
Я часто встречал большие структуры в протоколах, но никогда ранее не пробовал их упрощать у себя в заметках. Теперь буду так делать всегда.
Ну, что же, ждем результаты и движемся дальше!
Приятной рабочей недели и легкого обучения!
#audit
1👍5❤1
Челлендж: 50 не валидных репортов
Здорово, что многие тоже решили начать свой путь в аудитах и web3 безопасности, и пробуют свои силы в первых конкурсах. Я знаю, что порой может быть очень сложно сделать первый шаг, и поэтому хочу придать вам больше уверенности и мотивации в этом решении.
Более 5 лет назад мне очень нравилось смотреть различные видео от TED, где люди делились своими идеями и историями. Некоторым из выступающих действительно удавалось "перевернуть мировоззрение" на какую-либо тему, после чего ты вдруг решал что-то делать по другому... К одним из таких прекрасных видео можно отнести "Что я выучил за 100 дней отказов".
В этом видео выступающий поставил для себя цель получать отказы на свои просьбы, которые он побоялся бы спросить при обычных условиях. Это прекрасное видео про мотивацию и боязнь, что мы не получим, чего хотим. Крайне рекомендую его к просмотру.
И вот сейчас я предлагаю вам свой небольшой челлендж: "Получите 50 не валидных репортов".
Именно "получите", а не "напишите", так как в первом случае вы не должны знать, примут ли его или пропустят. Не нужно писать нарочно "плохие репорты", чтобы побыстрее набрать это количество.
Регистрируйтесь на любом приглянувшемся конкурсе, благо сейчас, в течение двух следующих недель, проходят аудиты протоколов с кодом менее 1000 строк. Изучайте его, солодите баги и пишите репорты, даже если не можете доказать уязвимость, но чувствуете ее наличие.
Ваша цель получить именно 50 не валидных репортов после судейства протокола. Вам не нужно ни перед кем отчитываться. Вы даже сможете изменить свой ник на конкурсной платформе в самом конце челленджа, если захотите!
С этим заданием я хочу показать, что не валидные репорты - это ок для аудитора. Не всегда "не валидный" означает "в корне не правильный", иногда он просто не подходит по правилам площадки.
И уверяю вас, если взять любого топового аудитора, то вы удивитесь тому, сколько не валидных отчетов у него было! Через это мы учимся и растем! И вовсе не нужно становиться новым MiloTruck, чтобы получить хорошо оплачиваемую работу или даже зарабатывать на конкурсах.
Просто попробуйте!
#challenge
Здорово, что многие тоже решили начать свой путь в аудитах и web3 безопасности, и пробуют свои силы в первых конкурсах. Я знаю, что порой может быть очень сложно сделать первый шаг, и поэтому хочу придать вам больше уверенности и мотивации в этом решении.
Более 5 лет назад мне очень нравилось смотреть различные видео от TED, где люди делились своими идеями и историями. Некоторым из выступающих действительно удавалось "перевернуть мировоззрение" на какую-либо тему, после чего ты вдруг решал что-то делать по другому... К одним из таких прекрасных видео можно отнести "Что я выучил за 100 дней отказов".
В этом видео выступающий поставил для себя цель получать отказы на свои просьбы, которые он побоялся бы спросить при обычных условиях. Это прекрасное видео про мотивацию и боязнь, что мы не получим, чего хотим. Крайне рекомендую его к просмотру.
И вот сейчас я предлагаю вам свой небольшой челлендж: "Получите 50 не валидных репортов".
Именно "получите", а не "напишите", так как в первом случае вы не должны знать, примут ли его или пропустят. Не нужно писать нарочно "плохие репорты", чтобы побыстрее набрать это количество.
Регистрируйтесь на любом приглянувшемся конкурсе, благо сейчас, в течение двух следующих недель, проходят аудиты протоколов с кодом менее 1000 строк. Изучайте его, солодите баги и пишите репорты, даже если не можете доказать уязвимость, но чувствуете ее наличие.
Ваша цель получить именно 50 не валидных репортов после судейства протокола. Вам не нужно ни перед кем отчитываться. Вы даже сможете изменить свой ник на конкурсной платформе в самом конце челленджа, если захотите!
С этим заданием я хочу показать, что не валидные репорты - это ок для аудитора. Не всегда "не валидный" означает "в корне не правильный", иногда он просто не подходит по правилам площадки.
И уверяю вас, если взять любого топового аудитора, то вы удивитесь тому, сколько не валидных отчетов у него было! Через это мы учимся и растем! И вовсе не нужно становиться новым MiloTruck, чтобы получить хорошо оплачиваемую работу или даже зарабатывать на конкурсах.
Просто попробуйте!
#challenge
👍4❤3🔥2💯1
Есть ли на канале участники, которые уже принимали участие в конкурсных аудитах и имеют подтвержденные находки?
Anonymous Poll
12%
Да, это я!
9%
Только начал принимать участие в конкурсах
79%
Нет, но хочу вскоре начать
👍3
Нужно ли доводить аудит до конца?
Думал, нужно ли рассказывать о такой теме или лучше не поднимать на канале, но решил, что начинающим аудиторам все равно может быть немного полезно и интересно.
В общем, продолжая тему своих разборов и вникании в аудиты, я зашел на конкурс HatsSignerGate, проходящим на платформе Шерлока, и насчитывающему всего 701 строку. Вроде как и мало, но есть свои нюансы.
Посмотрите на скрин. При наличии всего 2 контрактов на экране, количество пересекающихся вызовов на одну функцию просто невероятное! Я потратил на него около 5 часов и дальше просто не захотел разбираться в этом. Не потому что сложно, а потому что не посчитал приложенные усилия хоть как-нибудь окупятся.
Размер пула $20 250, из этой сумма сразу некоторая часть уйдет LSW, которому еще и потом, исходя из статистики предыдущих конкурсов, отдадут львиную часть. В итоге останется менее половины пула на всех участников конкурса. Кроме того, я пока не понял, как проходит судейство.
В итоге я подумал, что не хочу тратить свое время на длительный разбор function flow, расписывая все изменения в памяти контракта и изучая возможные проблемы.
Этим я хочу сказать, что это тоже ок - уходить с конкурса, который тебе не нравится, или не идет, или не согласны с условиями. Вы можете спокойно посмотреть инфо аудита, пул, репо и сложность кода и уйти, если что-то вас начнет смущать.
Не нужно сидеть и пыхтеть над тем, что не получается. Лучше потратьте свое время на изучение нового паттерна или поиск нового конкурса. Ну, или в крайнем случае - просто поиграйте в компьютерную игру.
Во время аудита голова должна работать, а не болеть!
Надеюсь этот пост поможет вам проще относиться к конкурсным аудитам.
А я все еще собираю группу на кооперативный аудит! Пишите, кто уже имеет результаты в конкурсах!
#audit
Думал, нужно ли рассказывать о такой теме или лучше не поднимать на канале, но решил, что начинающим аудиторам все равно может быть немного полезно и интересно.
В общем, продолжая тему своих разборов и вникании в аудиты, я зашел на конкурс HatsSignerGate, проходящим на платформе Шерлока, и насчитывающему всего 701 строку. Вроде как и мало, но есть свои нюансы.
Посмотрите на скрин. При наличии всего 2 контрактов на экране, количество пересекающихся вызовов на одну функцию просто невероятное! Я потратил на него около 5 часов и дальше просто не захотел разбираться в этом. Не потому что сложно, а потому что не посчитал приложенные усилия хоть как-нибудь окупятся.
Размер пула $20 250, из этой сумма сразу некоторая часть уйдет LSW, которому еще и потом, исходя из статистики предыдущих конкурсов, отдадут львиную часть. В итоге останется менее половины пула на всех участников конкурса. Кроме того, я пока не понял, как проходит судейство.
В итоге я подумал, что не хочу тратить свое время на длительный разбор function flow, расписывая все изменения в памяти контракта и изучая возможные проблемы.
Этим я хочу сказать, что это тоже ок - уходить с конкурса, который тебе не нравится, или не идет, или не согласны с условиями. Вы можете спокойно посмотреть инфо аудита, пул, репо и сложность кода и уйти, если что-то вас начнет смущать.
Не нужно сидеть и пыхтеть над тем, что не получается. Лучше потратьте свое время на изучение нового паттерна или поиск нового конкурса. Ну, или в крайнем случае - просто поиграйте в компьютерную игру.
Во время аудита голова должна работать, а не болеть!
Надеюсь этот пост поможет вам проще относиться к конкурсным аудитам.
А я все еще собираю группу на кооперативный аудит! Пишите, кто уже имеет результаты в конкурсах!
#audit
🤔8👍5👌1
Коротко о двойных стандартах в конкурсных аудитах
При том, что мне нравится принимать участие в конкурсах, читать отчеты и следить за новыми уязвимостями, я никогда не планировал на 100% посвящать свое время этому. Постараюсь раскрыть свою току зрения на эту сферу.
Очень часто на конкурсы выходят не подготовленные протоколы, которые максимум взяли один аудит у частника или компании, где проверка безопасности поставлена на поток. Они получают свой первый репорт и, в лучших побуждениях, идут на конкурсные площадки, где порой начинается "цирк". Не на всех, не для каждого протокола, но все чаще.
Во-первых, каждая площадка в буквальном смысле воюет за своих топовых аудиторов. И, со стороны бизнеса, это правильно. Однако может вредить остальным участникам. Так, в одном случае площадка может отдавать львиную долю пула своему топу просто за его участие в конкурсе, и он получит выплату даже если ничего не нашел, другая - вводит обязательные POC для всех High/Med отчетов, но с условием, что если у вас более 80% валидных отчетов, то POC не нужен. А у кого этот процент? У своих топов. И так далее...
Во-вторых, правила площадки у каждого свои. И то, что на одной из них может быть Med, на другой - вообще не зачтется. Например, это может быть проблема со следованию стандартам EIP.
В-третьих, сейчас самый бесячий отказ в валидации - "Это такой дизайн протокола". Так и хочется порой ответить в комментариях: "Значит хреновый дизаин!"... В моем понимании безопасности протокола, пользователи должны быть защищены от неправомерных действий администраторов. Если админ может даже по случайности как-то навредить пользователям, то такая проблема должна быть указана в финальном отчете. Иначе получается, что аудиторы нашли уязвимости, протокол сказал, что все так и надо, и потом везде рассказывает, что прошел конкурсный аудит, и в нем не нашли никаких проблем... Это какая-то чушь.
В-четвертых, описание условий конкурса, валидности багов и указание известных и Acknowledged проблем с предыдущих отчетов. Несколько раз встречал конкурсы с крайне скудным описанием. Практически только название протокола и scope. Никаких тебе setup указаний по запуску тестов, никаких ссылок на документацию и уж тем более прошедшие конкурсы. Но зато есть плашка - "Проблемы с предыдущих отчетов не считаются валидными". Серьезно? Это как в Инстаграме, когда видишь товар и готов его заказать, спрашиваешь цену и тебе говорят: "Ответил в личку"... И почему сами платформы допускают не полное описание конкурсов?!
В-пятых, отчеты с бот программ и chatGPT. После долго изучения отчетов, я для себя понял, что все статические анализаторы, по своей сути, обычные копи-паста условий кода, где может быть проблема. Где-то больше этих условий, где-то меньше. Популярный нынче бот Light Chaser - лучший анализатор, который используется практически для каждого конкурса на каждой аудит платформе. Всегда там присутствуют более 100 Low, пара Med и крайне редок High багов. Сколько из них дальше исправляются? 1-2%! Если вы запустите этот анализатор до конкурса, после и через год - в нем будут присутствовать примерно теже пункты. И стоит такое удовольствие около $1000 за прогон по контрактам.
Такая услуга может быть полезна для больших компаний, типа Lido, у которых человеко-часов уйдет больше, чем на $1000. А если вы небольшой протокол, то, блин, скачайте Slither, Slitherin, 4nali3er, изучите репорты Light Chaser и получите такие же репорты!
Ну, и в-шестых, иногда хочется что бы существовала отдельная triage компаний, которая могла бы судить конкурсы с третьей стороны, независимо от представителей самой конкурсной площадки и ее участников. Хотим мы того или нет, но всегда будет даже небольшое подсуживание "своим". Это ок, когда процесс не заметен, но когда это идет внаглую - тут уж извините...
При том, что мне нравится принимать участие в конкурсах, читать отчеты и следить за новыми уязвимостями, я никогда не планировал на 100% посвящать свое время этому. Постараюсь раскрыть свою току зрения на эту сферу.
Очень часто на конкурсы выходят не подготовленные протоколы, которые максимум взяли один аудит у частника или компании, где проверка безопасности поставлена на поток. Они получают свой первый репорт и, в лучших побуждениях, идут на конкурсные площадки, где порой начинается "цирк". Не на всех, не для каждого протокола, но все чаще.
Во-первых, каждая площадка в буквальном смысле воюет за своих топовых аудиторов. И, со стороны бизнеса, это правильно. Однако может вредить остальным участникам. Так, в одном случае площадка может отдавать львиную долю пула своему топу просто за его участие в конкурсе, и он получит выплату даже если ничего не нашел, другая - вводит обязательные POC для всех High/Med отчетов, но с условием, что если у вас более 80% валидных отчетов, то POC не нужен. А у кого этот процент? У своих топов. И так далее...
Во-вторых, правила площадки у каждого свои. И то, что на одной из них может быть Med, на другой - вообще не зачтется. Например, это может быть проблема со следованию стандартам EIP.
В-третьих, сейчас самый бесячий отказ в валидации - "Это такой дизайн протокола". Так и хочется порой ответить в комментариях: "Значит хреновый дизаин!"... В моем понимании безопасности протокола, пользователи должны быть защищены от неправомерных действий администраторов. Если админ может даже по случайности как-то навредить пользователям, то такая проблема должна быть указана в финальном отчете. Иначе получается, что аудиторы нашли уязвимости, протокол сказал, что все так и надо, и потом везде рассказывает, что прошел конкурсный аудит, и в нем не нашли никаких проблем... Это какая-то чушь.
В-четвертых, описание условий конкурса, валидности багов и указание известных и Acknowledged проблем с предыдущих отчетов. Несколько раз встречал конкурсы с крайне скудным описанием. Практически только название протокола и scope. Никаких тебе setup указаний по запуску тестов, никаких ссылок на документацию и уж тем более прошедшие конкурсы. Но зато есть плашка - "Проблемы с предыдущих отчетов не считаются валидными". Серьезно? Это как в Инстаграме, когда видишь товар и готов его заказать, спрашиваешь цену и тебе говорят: "Ответил в личку"... И почему сами платформы допускают не полное описание конкурсов?!
В-пятых, отчеты с бот программ и chatGPT. После долго изучения отчетов, я для себя понял, что все статические анализаторы, по своей сути, обычные копи-паста условий кода, где может быть проблема. Где-то больше этих условий, где-то меньше. Популярный нынче бот Light Chaser - лучший анализатор, который используется практически для каждого конкурса на каждой аудит платформе. Всегда там присутствуют более 100 Low, пара Med и крайне редок High багов. Сколько из них дальше исправляются? 1-2%! Если вы запустите этот анализатор до конкурса, после и через год - в нем будут присутствовать примерно теже пункты. И стоит такое удовольствие около $1000 за прогон по контрактам.
Такая услуга может быть полезна для больших компаний, типа Lido, у которых человеко-часов уйдет больше, чем на $1000. А если вы небольшой протокол, то, блин, скачайте Slither, Slitherin, 4nali3er, изучите репорты Light Chaser и получите такие же репорты!
Ну, и в-шестых, иногда хочется что бы существовала отдельная triage компаний, которая могла бы судить конкурсы с третьей стороны, независимо от представителей самой конкурсной площадки и ее участников. Хотим мы того или нет, но всегда будет даже небольшое подсуживание "своим". Это ок, когда процесс не заметен, но когда это идет внаглую - тут уж извините...
❤4👍2
В целом, участие в конкурсных аудитах может сильно продвинуть ваши навыки работы с различными протоколами, архитектурами и их тестами, но если вы решите на 100% уйти в них, то желательно, на мой взгляд, работать с одной-двумя и топить за них, чтобы через некоторое время стать "своим". А дальше, уже уходить в соло или компанию, или на полноценные баг баунти.
#audit
#audit
1👍1
Роудмап: Как стать аудитором смарт контрактов. Часть 1. Минимальный объем знаний
Пробовал записать видео по этой теме, но понял, что постом будет лучше, так как все равно нужно будет отдельно добавлять ссылки и гайды к нему. Поэтому распишу на свой взгляд, как лучше подготовиться к становлению аудитором.
В начале хотел бы сказать, что не рекомендовал бы покупать отдельные курсы по безопасности смарт контрактов. Дело не в том, что информация там может быть плохой, не структурированном или с некачественной подачей, а, скорее, в том, что практически во всех уроках, что я встречал, были описаны самые простые и базовые темы. Такие уязвимости исправляются уже самими разработчиками на этапе создания и тестирования протокола, и вы вряд ли найдете их в таком чистом виде в реальных проектах.
Я уже неоднократно писал, что с каждым годом баги становятся все сложнее, и то, что год назад можно было найти просто взглянув на код, сейчас требует его понимания на достаточно хорошем уровне.
Так с чего же начать свой путь?
1. Изучение и понимание Solidity.
Как бы просто это не звучало, но вам потребуется хорошее понимание самого языка и работы EVM. Можно знать как работает delagatecall, а можно и ясно понимать, как идет вызов на базовом уровне, и чем грозит его незащищенность.
Это не то, что можно выучить по гайдам и документации. Тут поможет только самостоятельная практика и работа с кодом. Чаще задавайтесь вопросом: "А как это работает? А что будет, если сделать так...?" и другие. Невозможно понять язык, просто читая его документацию.
2. Изучение и понимание популярных EIP и Open Zeppelin контрактов.
Каждый хороший разработчик и, тем более, аудитор должен хорошо знать часто используемые EIP:
1. https://eips.ethereum.org/EIPS/eip-20
2. https://eips.ethereum.org/EIPS/eip-721
3. https://eips.ethereum.org/EIPS/eip-712
4. https://eips.ethereum.org/EIPS/eip-1155
5. https://eips.ethereum.org/EIPS/eip-4626
6. https://eips.ethereum.org/EIPS/eip-165
7. https://eips.ethereum.org/EIPS/eip-1967
При чтении этих Предложений необходимо уделять пристальное внимание всем "warning", "must", "should" и нюансам использования. Так, например, возникает очень много проблем с реализацией стандарта подписей (712): правильным хешированием данных, domain separator и составлению подписи.
Вам также необходимо знать часто используемые контракты от Open Zeppelin:
1. ECDSA,
2. MerkleProof,
3. Math,
4. SafeCast,
5. Address,
6. Context,
7. Create2,
8. ReentrancyGuard,
9. AccessControl,
10. Ownable,
11. Ownable2Step
Более того, обязательно знать реализации OZ контрактов из обозначенных выше EIP. Все их можно постепенно изучать в этом репо:
https://github.com/OpenZeppelin/openzeppelin-contracts
Также будет здорово, если вы будете понимать работу обновляемых контрактов от OZ:
https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable
И две другие библиотеки:
1. Solady - https://github.com/Vectorized/solady
2. Solmate - https://github.com/transmissions11/solmate
Эти две библиотеки реализуют популярные стандарты токенов и некоторых других контрактов, которые могут попадаться в аудитах. Они немного отличаются от обще используемых контрактов OZ.
Это та база, на которую опираются 90% протоколов в своей разработке.
При изучении каждого контракта желательно обращать внимание на его версию и поискать, какие проблемы были обнаружены в предыдущей реализации. Например, почему нельзя использовать ECDSA от OZ ниже 4.8.2 версии. И не просто знать рекомендуемую версию, а именно "что было не так в предыдущей".
3. Изучение и понимание DeFi
Большинство сегодняшних протоколов - это DeFi проекты. Многие из них берут свои идеи от других финансовых протоколов или просто копируют его код. На начальном этапе вам не нужно знать как работают деривативы и фьючерсы, но иметь представление о нескольких наиболее копируемых протоколов все же надо.
На мой взгляд, обязательными к пониманию и изучению являются следующие DeFi:
Пробовал записать видео по этой теме, но понял, что постом будет лучше, так как все равно нужно будет отдельно добавлять ссылки и гайды к нему. Поэтому распишу на свой взгляд, как лучше подготовиться к становлению аудитором.
В начале хотел бы сказать, что не рекомендовал бы покупать отдельные курсы по безопасности смарт контрактов. Дело не в том, что информация там может быть плохой, не структурированном или с некачественной подачей, а, скорее, в том, что практически во всех уроках, что я встречал, были описаны самые простые и базовые темы. Такие уязвимости исправляются уже самими разработчиками на этапе создания и тестирования протокола, и вы вряд ли найдете их в таком чистом виде в реальных проектах.
Я уже неоднократно писал, что с каждым годом баги становятся все сложнее, и то, что год назад можно было найти просто взглянув на код, сейчас требует его понимания на достаточно хорошем уровне.
Так с чего же начать свой путь?
1. Изучение и понимание Solidity.
Как бы просто это не звучало, но вам потребуется хорошее понимание самого языка и работы EVM. Можно знать как работает delagatecall, а можно и ясно понимать, как идет вызов на базовом уровне, и чем грозит его незащищенность.
Это не то, что можно выучить по гайдам и документации. Тут поможет только самостоятельная практика и работа с кодом. Чаще задавайтесь вопросом: "А как это работает? А что будет, если сделать так...?" и другие. Невозможно понять язык, просто читая его документацию.
2. Изучение и понимание популярных EIP и Open Zeppelin контрактов.
Каждый хороший разработчик и, тем более, аудитор должен хорошо знать часто используемые EIP:
1. https://eips.ethereum.org/EIPS/eip-20
2. https://eips.ethereum.org/EIPS/eip-721
3. https://eips.ethereum.org/EIPS/eip-712
4. https://eips.ethereum.org/EIPS/eip-1155
5. https://eips.ethereum.org/EIPS/eip-4626
6. https://eips.ethereum.org/EIPS/eip-165
7. https://eips.ethereum.org/EIPS/eip-1967
При чтении этих Предложений необходимо уделять пристальное внимание всем "warning", "must", "should" и нюансам использования. Так, например, возникает очень много проблем с реализацией стандарта подписей (712): правильным хешированием данных, domain separator и составлению подписи.
Вам также необходимо знать часто используемые контракты от Open Zeppelin:
1. ECDSA,
2. MerkleProof,
3. Math,
4. SafeCast,
5. Address,
6. Context,
7. Create2,
8. ReentrancyGuard,
9. AccessControl,
10. Ownable,
11. Ownable2Step
Более того, обязательно знать реализации OZ контрактов из обозначенных выше EIP. Все их можно постепенно изучать в этом репо:
https://github.com/OpenZeppelin/openzeppelin-contracts
Также будет здорово, если вы будете понимать работу обновляемых контрактов от OZ:
https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable
И две другие библиотеки:
1. Solady - https://github.com/Vectorized/solady
2. Solmate - https://github.com/transmissions11/solmate
Эти две библиотеки реализуют популярные стандарты токенов и некоторых других контрактов, которые могут попадаться в аудитах. Они немного отличаются от обще используемых контрактов OZ.
Это та база, на которую опираются 90% протоколов в своей разработке.
При изучении каждого контракта желательно обращать внимание на его версию и поискать, какие проблемы были обнаружены в предыдущей реализации. Например, почему нельзя использовать ECDSA от OZ ниже 4.8.2 версии. И не просто знать рекомендуемую версию, а именно "что было не так в предыдущей".
3. Изучение и понимание DeFi
Большинство сегодняшних протоколов - это DeFi проекты. Многие из них берут свои идеи от других финансовых протоколов или просто копируют его код. На начальном этапе вам не нужно знать как работают деривативы и фьючерсы, но иметь представление о нескольких наиболее копируемых протоколов все же надо.
На мой взгляд, обязательными к пониманию и изучению являются следующие DeFi:
👍3❤1
1. Uniswap V2/V3 - чаще всего проекты интегрируются с ним;
2. Balancer - многие взяли идею мультипула;
3. Aave - кредитование;
4. Lido - первый, кто сделал рестейкинг ETH;
В случае с изучением Uniswap лучше всего будет, если будете также сразу искать популярные уязвимости при интеграции с ним: slippage, slot0, currentSqrtPriceX96 и другие. Важно понимать не только, в чем тут был баг, но и как должно быть исправлено в самом контракте.
С остальными протоколами, в целом, хорошо быть знакомыми с их архитектурой и главной идеей: как происходят депозиты в пул, как рассчитывается обеспеченный займ, какие условия для ликвидаций, как работает рестейкинг и, желательно, немного погрузиться в математику DeFi.
Уже после этого вы можете рассмотреть и другие финансовые протоколы, типа dydx, Compound, MakerDAO, Curve...
Нужно добавить, что по Uniswap и Compound есть прекрасные разборы:
1. https://www.rareskills.io/uniswap-v2-book
2. https://uniswapv3book.com/
3. https://www.rareskills.io/compound-v3-book
По остальным популярным протоколам, таких "книг" нет, но достаточно разборов кода, в том числе и на Ютуб. Например, о том, как работает DAI стейблкоин:
https://www.youtube.com/watch?v=lsTouzJUsUk&list=PLO5VPQH6OWdW9b6GKJR4Dt9XZxQlJuVp_&ab_channel=SmartContractProgrammer
Я считаю, что это тот необходимый базовый минимум знаний, который нужен для старта пути в аудиторы. И это связано не с тем, что без этого нельзя начать принимать участие в конкурсных аудитах, а, скорее, что так вам будет гораздо легче разбираться в коде и понимать "откуда растут ноги" в очередном контракте.
В следующем посте мы поговорим, о первых шагах в проверке контрактов.
#audit #start
2. Balancer - многие взяли идею мультипула;
3. Aave - кредитование;
4. Lido - первый, кто сделал рестейкинг ETH;
В случае с изучением Uniswap лучше всего будет, если будете также сразу искать популярные уязвимости при интеграции с ним: slippage, slot0, currentSqrtPriceX96 и другие. Важно понимать не только, в чем тут был баг, но и как должно быть исправлено в самом контракте.
С остальными протоколами, в целом, хорошо быть знакомыми с их архитектурой и главной идеей: как происходят депозиты в пул, как рассчитывается обеспеченный займ, какие условия для ликвидаций, как работает рестейкинг и, желательно, немного погрузиться в математику DeFi.
Уже после этого вы можете рассмотреть и другие финансовые протоколы, типа dydx, Compound, MakerDAO, Curve...
Нужно добавить, что по Uniswap и Compound есть прекрасные разборы:
1. https://www.rareskills.io/uniswap-v2-book
2. https://uniswapv3book.com/
3. https://www.rareskills.io/compound-v3-book
По остальным популярным протоколам, таких "книг" нет, но достаточно разборов кода, в том числе и на Ютуб. Например, о том, как работает DAI стейблкоин:
https://www.youtube.com/watch?v=lsTouzJUsUk&list=PLO5VPQH6OWdW9b6GKJR4Dt9XZxQlJuVp_&ab_channel=SmartContractProgrammer
Я считаю, что это тот необходимый базовый минимум знаний, который нужен для старта пути в аудиторы. И это связано не с тем, что без этого нельзя начать принимать участие в конкурсных аудитах, а, скорее, что так вам будет гораздо легче разбираться в коде и понимать "откуда растут ноги" в очередном контракте.
В следующем посте мы поговорим, о первых шагах в проверке контрактов.
#audit #start
3👍9🔥2
Роудмап: Как стать аудитором смарт контрактов. Часть 2. Первичное знакомство с аудитом
Далее, после того, как мы изучили базовые контракты и стандарты, лучше всего будет продолжить свой путь с задач Capture The Flag - CTF.
4. Прохождение CTF
Открою вам маленький секрет: вовсе не обязательно самому решать эти задачи, можно просто сразу смотреть ответы на них.
В самом начале пути мы может не представлять себе, что такое "баг" или уязвимость вообще. Другими словами, решение таких задач будет как "ищу то, не знаю что, не знаю где и как". И с помощью разбора CTF задач нам важно получить два скилла:
1. Умение читать и понимать контракты;
2. Понимание базовых проблем в протоколах;
И в последнее время я все больше убеждаюсь, что понимание контрактов и протокола в целом, куда важнее для поиска багов, чем знание каких-либо паттернов.
Тут необходимо научиться изучать код контракта буквально на детали:
1. Отслеживать движение токенов;
2. Отслеживать, кто является msg.sender при вызовах функций;
3. Отслеживать несоответствия стандартам EIP;
4. Отслеживать изменения в памяти контракта, его переменных состояния;
Как понять для себя, что вы разобрались в контракте? Попробуйте на листке бумаги или в отдельном файле просто накидать его архитектуру и функции: что за что отвечает, что сохраняет и зачем это вообще надо. Справились? Супер, значит вы поняли суть контракта.
Подсматривая ответы и разбирая их, вы учитесь осознавать, что в любом контракте есть проблемы. И с каждой новой задачей вы будете учиться либо новому багу, либо их комбинации.
Правда, не старайтесь решать такие задачи с нулевыми знаниями. Смотрите ответы и учитесь. Так будет гораздо быстрее. А искать проблемы лучше уже на боевых конкурсных аудитах. Но об этом позже.
Буквально за один месяц, разбирая по одной-две задачи в день, можно научиться поиску многих базовых проблем. На данный момент я бы рекомендовал следующие CTF задачи:
1. https://capturetheether.com/
2. https://ethernaut.openzeppelin.com/
3. https://www.damnvulnerabledefi.xyz/
4. https://cryptozombies.io/
5. https://speedrunethereum.com/
6. https://ciphershastra.com/
7. https://mrstealyocrypto.xyz/
8. https://cryptohack.org/challenges/
9. https://www.defihack.xyz/
10. https://etherhack.positive.com/#/
11. https://www.ctfprotocol.com/
12. https://github.com/minaminao/ctf-blockchain/
В обязательно порядке я бы порекомендовал пройти первые три. Остальные - на ваше усмотрение и свободное время.
5. Решение задач из сниппетов кода
После того как мы научились базовым уязвимостям в смарт контрактах, можно переходить к упрощенным задачам, в которых показан только участок кода, а не весь контракт. Преимущества таких задач в том, что многие из них были взяты с реальных контрактов, которые проходили конкурсные или соло аудиты. Другими словами, это ваше первое столкновение с профессиональным кодом и подготовка к своему первому аудиту.
Достаточно много задач по уровням вы можете найти тут:
https://auditprofile.xyz/challenges.php
либо на Твиттер аккаунте Шерлока, которые на момент ноября-декабря этого года, практически каждую неделю выставляют новую задачу, например:
https://x.com/sherlockdefi/status/1860668335777775786
С такими задачами вы сможете научиться видеть в коде то, чего нет, а быть должно! Так, к слову, вы начнете понимать, какие проверки могут потребовать в данном случае, какое несоответствие стандарту, где забыли обновить память контракта, и т.д.
6. Понимание чеклистов и weird erc20
Weird ERC20 Tokens - это сборник описаний токенов одного стандарта, но с разными поведениями при вызовах. Одни могут брать комиссию за перевод, другие менять балансы пользователей, третьи не возвращать ответ после трансфера и много чего еще. Всего на данный момент описано около 20 не стандартных поведений. Все их можно и нужно прочитать тут:
https://github.com/d-xo/weird-erc20
Как лучше работать с ними, чтобы понять потенциальную проблему?
Далее, после того, как мы изучили базовые контракты и стандарты, лучше всего будет продолжить свой путь с задач Capture The Flag - CTF.
4. Прохождение CTF
Открою вам маленький секрет: вовсе не обязательно самому решать эти задачи, можно просто сразу смотреть ответы на них.
В самом начале пути мы может не представлять себе, что такое "баг" или уязвимость вообще. Другими словами, решение таких задач будет как "ищу то, не знаю что, не знаю где и как". И с помощью разбора CTF задач нам важно получить два скилла:
1. Умение читать и понимать контракты;
2. Понимание базовых проблем в протоколах;
И в последнее время я все больше убеждаюсь, что понимание контрактов и протокола в целом, куда важнее для поиска багов, чем знание каких-либо паттернов.
Тут необходимо научиться изучать код контракта буквально на детали:
1. Отслеживать движение токенов;
2. Отслеживать, кто является msg.sender при вызовах функций;
3. Отслеживать несоответствия стандартам EIP;
4. Отслеживать изменения в памяти контракта, его переменных состояния;
Как понять для себя, что вы разобрались в контракте? Попробуйте на листке бумаги или в отдельном файле просто накидать его архитектуру и функции: что за что отвечает, что сохраняет и зачем это вообще надо. Справились? Супер, значит вы поняли суть контракта.
Подсматривая ответы и разбирая их, вы учитесь осознавать, что в любом контракте есть проблемы. И с каждой новой задачей вы будете учиться либо новому багу, либо их комбинации.
Правда, не старайтесь решать такие задачи с нулевыми знаниями. Смотрите ответы и учитесь. Так будет гораздо быстрее. А искать проблемы лучше уже на боевых конкурсных аудитах. Но об этом позже.
Буквально за один месяц, разбирая по одной-две задачи в день, можно научиться поиску многих базовых проблем. На данный момент я бы рекомендовал следующие CTF задачи:
1. https://capturetheether.com/
2. https://ethernaut.openzeppelin.com/
3. https://www.damnvulnerabledefi.xyz/
4. https://cryptozombies.io/
5. https://speedrunethereum.com/
6. https://ciphershastra.com/
7. https://mrstealyocrypto.xyz/
8. https://cryptohack.org/challenges/
9. https://www.defihack.xyz/
10. https://etherhack.positive.com/#/
11. https://www.ctfprotocol.com/
12. https://github.com/minaminao/ctf-blockchain/
В обязательно порядке я бы порекомендовал пройти первые три. Остальные - на ваше усмотрение и свободное время.
5. Решение задач из сниппетов кода
После того как мы научились базовым уязвимостям в смарт контрактах, можно переходить к упрощенным задачам, в которых показан только участок кода, а не весь контракт. Преимущества таких задач в том, что многие из них были взяты с реальных контрактов, которые проходили конкурсные или соло аудиты. Другими словами, это ваше первое столкновение с профессиональным кодом и подготовка к своему первому аудиту.
Достаточно много задач по уровням вы можете найти тут:
https://auditprofile.xyz/challenges.php
либо на Твиттер аккаунте Шерлока, которые на момент ноября-декабря этого года, практически каждую неделю выставляют новую задачу, например:
https://x.com/sherlockdefi/status/1860668335777775786
С такими задачами вы сможете научиться видеть в коде то, чего нет, а быть должно! Так, к слову, вы начнете понимать, какие проверки могут потребовать в данном случае, какое несоответствие стандарту, где забыли обновить память контракта, и т.д.
6. Понимание чеклистов и weird erc20
Weird ERC20 Tokens - это сборник описаний токенов одного стандарта, но с разными поведениями при вызовах. Одни могут брать комиссию за перевод, другие менять балансы пользователей, третьи не возвращать ответ после трансфера и много чего еще. Всего на данный момент описано около 20 не стандартных поведений. Все их можно и нужно прочитать тут:
https://github.com/d-xo/weird-erc20
Как лучше работать с ними, чтобы понять потенциальную проблему?
🔥6👍1
Есть такой прекрасный сайт - Solodit.xyz - который собрал многие отчеты с конкурсных платформ и от частных аудиторов. Когда вы откроете его, в левой части экрана будет располагаться фильтр и поиск. С помощью него можно искать проблемы с различными токенами.
Например, вы вбиваете в поиск "fee-on-transfer" и медленно, вникая в проблему, начинаете изучать отчет. Так можно пройтись по всему списку Weird и научиться находить проблемы, связанные с разными токенами.
Вместе с токенами и Solodit можно начать потихоньку разбирать некоторые чеклисты с описанием багов и моментов, на которые стоит обращать внимание при аудите.
Вообще не переживайте, если что-то будет не понятно. Зачастую такие чеклисты пишутся разработчиками для разработчиков, или продвинутыми аудиторами для коллег. Там часто бывают недосказанности в пунктах. И их можно спокойно пропускать.
Для своего обучения можно пройтись по следующим чеклистам:
1. https://solodit.xyz/checklist
2. https://betterprogramming.pub/the-ultimate-100-point-checklist-before-sending-your-smart-contract-for-audit-af9a5b5d95d0
3. https://github.com/0xJuancito/multichain-auditor
4. https://github.com/spearbit/portfolio/blob/master/content/bridges/BridgeSecurityChecklist.md
5. https://x.com/sigp_io/status/1703363387592462633?s=20
6. https://officercia.mirror.xyz/d798TVQyA1ALq3qr1R9vvujdF7x-erXxK2wQWwbgRKY
7. https://github.com/Decurity/audit-checklists/blob/master/lsd.md
8. https://www.beirao.xyz/blog/Security-checklist
9. https://docs.layerzero.network/v1/developers/troubleshooting/integration-checklist
10. https://github.com/aviggiano/security/blob/main/audit-checklists/ERC-4337.md
11. https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/guidelines.md
Эти три пункта могут занять у вас месяц и более, но точно помогут лучше разобраться в уязвимостях и современных багах.
В следующей части мы поговорим, как продолжить свое обучение и начать принимать участие в конкурсах.
#audit
Например, вы вбиваете в поиск "fee-on-transfer" и медленно, вникая в проблему, начинаете изучать отчет. Так можно пройтись по всему списку Weird и научиться находить проблемы, связанные с разными токенами.
Вместе с токенами и Solodit можно начать потихоньку разбирать некоторые чеклисты с описанием багов и моментов, на которые стоит обращать внимание при аудите.
Вообще не переживайте, если что-то будет не понятно. Зачастую такие чеклисты пишутся разработчиками для разработчиков, или продвинутыми аудиторами для коллег. Там часто бывают недосказанности в пунктах. И их можно спокойно пропускать.
Для своего обучения можно пройтись по следующим чеклистам:
1. https://solodit.xyz/checklist
2. https://betterprogramming.pub/the-ultimate-100-point-checklist-before-sending-your-smart-contract-for-audit-af9a5b5d95d0
3. https://github.com/0xJuancito/multichain-auditor
4. https://github.com/spearbit/portfolio/blob/master/content/bridges/BridgeSecurityChecklist.md
5. https://x.com/sigp_io/status/1703363387592462633?s=20
6. https://officercia.mirror.xyz/d798TVQyA1ALq3qr1R9vvujdF7x-erXxK2wQWwbgRKY
7. https://github.com/Decurity/audit-checklists/blob/master/lsd.md
8. https://www.beirao.xyz/blog/Security-checklist
9. https://docs.layerzero.network/v1/developers/troubleshooting/integration-checklist
10. https://github.com/aviggiano/security/blob/main/audit-checklists/ERC-4337.md
11. https://github.com/crytic/building-secure-contracts/blob/master/development-guidelines/guidelines.md
Эти три пункта могут занять у вас месяц и более, но точно помогут лучше разобраться в уязвимостях и современных багах.
В следующей части мы поговорим, как продолжить свое обучение и начать принимать участие в конкурсах.
#audit
🔥13👍1
Роудмап: Как стать аудитором смарт контрактов. Часть 3. Боевое крещение
Ну, и завершаем наш роудмап для начинающего аудитора парой дополнительных пунктов.
7. Чтение отчетов прошедших конкурсных аудитов
Вообще читать отчеты по прошедшим аудитам я бы рекомендовал не только всем аудиторам, но и разработчикам, создающим уникальный протокол.
С помощью таких отчетов вы научитесь сразу нескольким вещам:
1. Понимать современные уязвимости;
2. Писать отчеты;
3. Разбирать доказательства багов (PoC);
Самый первый вопрос, который мне задавали: а как выбирать отчет для изучения, ведь я не знаю протокол и, скорее всего, не пойму проблему?
В это нет ничего страшного или сложного.
В отчетах бывают как простые примеры уязвимостей, которые вы сможете понять просто взглянув на код, так и уникальные для протокола. Баги из второго вида вы можете спокойно пропускать или же попытаться вникнуть, если планируете поучаствовать в следующем конкурсном аудите этого же проекта.
Будет также здорово, если заведете для себя файл/таблицу, куда будете записывать интересные для себя уязвимости. Вам будет намного проще вспоминать примеры или формулировки для своих бедующих конкурсов с помощью таких файлов.
Также, еще один отличный вариант практики для начинающего аудитора будет поиск похожих уязвимостей на Solodit. Например, вы встретили баг с темой некорректных подписей RC712, и тут же нашли еще 5 примеров, которые записали в свою таблицу.
Я бы назвал следующие темы багов популярными в современных аудитах:
1. Подписи;
2. Прокси и обновляемые контракты;
3. Интеграция с Uniswap v2/v3;
4. Различия l2 сетей, в частности zk synk и base;
5. Математические операции: потеря точности при делении, округление вверх/вниз;
6. Timelock и governance;
В целом, вы можете сразу зайти на Solodit и разобрать для себя по 10 багов каждого пункта. Так вы получите первый опыт чтения репортов и начнете вести файл.
8. Участие в конкурсах и разбор протоколов
А тут самый первый вопрос будет: "Какую платформу выбрать для новичка?".
В Твиттере был прекрасный пост от пользователя Flint, который написал небольшой обзор на современные платформу. И далее пойдет перевод этого поста.
1. Code4rena : «Нежный гигант»
Изначальная конкурсная платформа, которая зажгла искру для всей индустрии web3-аудита, @code4rena приняла на работу тысячи и тысячи новых аудиторов и остается известным всем именем. Под руководством всегда приветливого sockdrawermoney, C4 продолжает внедрять новые продукты и идеи почти ежемесячно.
Преимущества:
- Наиболее зрелая платформа с установленными правилами и процедурами.
- Постоянный поток новых конкурсов.
- Пригласительные аудиты и Про-лига для лучших аудиторов.
- Солидная судейская репутация и единственная платформа, позволяющая вызывать трибунал, чтобы оспорить решение судьи.
Недостатки:
- Крайне переполненная площадка, 1000+ заявок на один конкурс - очень частое явление.
- Единственная платформа, где вы можете иметь 3 высоких и 2 средних балла и все равно не заработать достаточно, чтобы купить бургер в McDonalds.
- Пока вы не получите доступ за кулисы, вы не сможете присоединиться к PJQA и убедиться, что ваши заявки не были признаны недействительными по ошибке.
2. CodeHawks: "Занятие в школе"
Нельзя говорить о CodeHawks, не обсуждая Cyfrin Audits. Основанная Патриком Коллинсом и Алексом Роаном, компания Cyfrin является одновременно аудиторской, конкурсной и образовательной платформой. Сочетание солидных курсов от Cyfrin Updraft с «Первыми полетами» не вызывает сомнений, что это лучшее место для обучения.
Преимущества:
- «Первые полеты», обучающие аудиты, которые CH предлагает на ежемесячной основе, - отличный способ начать участвовать в конкурсах.
- Более мягкая платформа с меньшей конкуренцией, поскольку у высококвалифицированных аудиторов нет стимула фокусироваться исключительно на CH.
Недостатки:
Ну, и завершаем наш роудмап для начинающего аудитора парой дополнительных пунктов.
7. Чтение отчетов прошедших конкурсных аудитов
Вообще читать отчеты по прошедшим аудитам я бы рекомендовал не только всем аудиторам, но и разработчикам, создающим уникальный протокол.
С помощью таких отчетов вы научитесь сразу нескольким вещам:
1. Понимать современные уязвимости;
2. Писать отчеты;
3. Разбирать доказательства багов (PoC);
Самый первый вопрос, который мне задавали: а как выбирать отчет для изучения, ведь я не знаю протокол и, скорее всего, не пойму проблему?
В это нет ничего страшного или сложного.
В отчетах бывают как простые примеры уязвимостей, которые вы сможете понять просто взглянув на код, так и уникальные для протокола. Баги из второго вида вы можете спокойно пропускать или же попытаться вникнуть, если планируете поучаствовать в следующем конкурсном аудите этого же проекта.
Будет также здорово, если заведете для себя файл/таблицу, куда будете записывать интересные для себя уязвимости. Вам будет намного проще вспоминать примеры или формулировки для своих бедующих конкурсов с помощью таких файлов.
Также, еще один отличный вариант практики для начинающего аудитора будет поиск похожих уязвимостей на Solodit. Например, вы встретили баг с темой некорректных подписей RC712, и тут же нашли еще 5 примеров, которые записали в свою таблицу.
Я бы назвал следующие темы багов популярными в современных аудитах:
1. Подписи;
2. Прокси и обновляемые контракты;
3. Интеграция с Uniswap v2/v3;
4. Различия l2 сетей, в частности zk synk и base;
5. Математические операции: потеря точности при делении, округление вверх/вниз;
6. Timelock и governance;
В целом, вы можете сразу зайти на Solodit и разобрать для себя по 10 багов каждого пункта. Так вы получите первый опыт чтения репортов и начнете вести файл.
8. Участие в конкурсах и разбор протоколов
А тут самый первый вопрос будет: "Какую платформу выбрать для новичка?".
В Твиттере был прекрасный пост от пользователя Flint, который написал небольшой обзор на современные платформу. И далее пойдет перевод этого поста.
1. Code4rena : «Нежный гигант»
Изначальная конкурсная платформа, которая зажгла искру для всей индустрии web3-аудита, @code4rena приняла на работу тысячи и тысячи новых аудиторов и остается известным всем именем. Под руководством всегда приветливого sockdrawermoney, C4 продолжает внедрять новые продукты и идеи почти ежемесячно.
Преимущества:
- Наиболее зрелая платформа с установленными правилами и процедурами.
- Постоянный поток новых конкурсов.
- Пригласительные аудиты и Про-лига для лучших аудиторов.
- Солидная судейская репутация и единственная платформа, позволяющая вызывать трибунал, чтобы оспорить решение судьи.
Недостатки:
- Крайне переполненная площадка, 1000+ заявок на один конкурс - очень частое явление.
- Единственная платформа, где вы можете иметь 3 высоких и 2 средних балла и все равно не заработать достаточно, чтобы купить бургер в McDonalds.
- Пока вы не получите доступ за кулисы, вы не сможете присоединиться к PJQA и убедиться, что ваши заявки не были признаны недействительными по ошибке.
2. CodeHawks: "Занятие в школе"
Нельзя говорить о CodeHawks, не обсуждая Cyfrin Audits. Основанная Патриком Коллинсом и Алексом Роаном, компания Cyfrin является одновременно аудиторской, конкурсной и образовательной платформой. Сочетание солидных курсов от Cyfrin Updraft с «Первыми полетами» не вызывает сомнений, что это лучшее место для обучения.
Преимущества:
- «Первые полеты», обучающие аудиты, которые CH предлагает на ежемесячной основе, - отличный способ начать участвовать в конкурсах.
- Более мягкая платформа с меньшей конкуренцией, поскольку у высококвалифицированных аудиторов нет стимула фокусироваться исключительно на CH.
Недостатки:
❤4👍1
- Становление лучшим аудитором в CH в настоящее время не имеет никаких преимуществ. Здесь нет пригласительных аудитов, нет ведущего старшего Ватсона или других возможностей для лучших аудиторов.
- Малое количество конкурсов по сравнению с C4 или Шерлоком.
- Cyfrin пытается делать все. Иногда непонятно, что это - образовательная платформа с конкурсами или платформа для конкурсов с образованием.
3. Шерлок: «Хардкорное PvP»
Примечание: Если вы читаете X, то вскоре узнаете, что у Sherlock ужасная репутация, когда речь идет о судействе и эскалации. Хотя они, безусловно, заслужили такую репутацию, важно также признать, что они - единственная платформа, которая полностью прозрачна во всем. У других платформ также есть некоторые из этих проблем, но они держат их в секрете. Поэтому при сравнении платформ не следует рассматривать их как черно-белые, а скорее как светло-серые/темно-серые.
Компания Шерлок предлагает клиентам гибридную модель между частными аудитами и публичными конкурсами. В каждом конкурсе есть ведущий старший Ватсон - эксперт, который получает фиксированный процент от конкурсного пула. Затем LSW соревнуется с каждым участвующим аудитором за оставшуюся часть банка.
Основная ценность «Шерлока» - меритократия. Хотите стать LSW? Тогда победите его и займите его место. Хотите стать ведущим судьей? Тогда победите нынешнего судью и станьте судьей. Все - это соревнование, в котором побеждает тот, кто стоит первым.
Преимущества:
- Если вы любите бесконечные споры и безжалостную конкуренцию, это место для вас.
- Это делают немногие, поэтому количество участников ниже, чем на других платформах.
- Постоянный поток небольших конкурсов с очень коротким циклом обратной связи.
- Если вы сможете стать LSW, вы будете в большом плюсе.
Недостатки:
- Судьи выбираются через соревновательную систему лидерборда, подобную LSW, где они соревнуются в судействе сообщества после каждого конкурса. Лучший участник может стать ведущим судьей конкурса. Однако вознаграждение судьи чрезвычайно мало по сравнению с другими платформами. В результате у тех, кто обладает необходимым опытом для правильного судейства, нет экономического стимула участвовать в конкурсе. Следовательно, зачастую ведущий судья не обладает необходимыми знаниями.
- Отсутствие объяснений, почему результат признан недействительным, и недоверие к ведущему судье приводят к неприличному количеству эскалаций в каждом конкурсе.
- Каждая эскалация быстро превращается в перепалку между участниками, которые экономически стимулированы делать все, чтобы победить. Если вам удастся подтвердить недействительный вывод, судья потеряет деньги. Если вы можете признать недействительным чужой вывод, вы получаете деньги. В сущности, предательство выгодно, а «твоя потеря - моя выгода», так что это становится нормой.
- Эскалация может затянуться на недели.
-Интерпретация правил судейства Шерлока может меняться в разных конкурсах, а также рамки конкурса могут меняться во время или даже после его завершения.
4. Hats: «Скорость - это любовь, скорость - это жизнь»
Уникальная платформа Hats Finance полностью основана на скорости. Каждый конкурс - это гонка, в которой вознаграждается только тот, кто первым представит находку. Заявка подается на цепочке с доказательством концепции, и временная метка решает, получите ли вы все или ничего.
Преимущества:
- Если вы любите адреналин, то вам обязательно понравится Hats.
- Банк не разбавляется дубликатами. Так что если вы попали в банк, то вы попали в него по-крупному.
Многим не нравится давление, поэтому конкуренция намного ниже, чем на других платформах.
Недостатки:
- Высокая дисперсия. Вы можете подать 10 правильных заявок и получить 0 долларов только потому, что опоздали на 1 секунду.
- Психический стресс. Мало того, что вы не знаете, будет ли ваша находка признана достоверной, так еще и дополнительный стресс от того, что вы не знаете, были ли вы первыми.
5. Cantina: «There Be Dragons»
- Малое количество конкурсов по сравнению с C4 или Шерлоком.
- Cyfrin пытается делать все. Иногда непонятно, что это - образовательная платформа с конкурсами или платформа для конкурсов с образованием.
3. Шерлок: «Хардкорное PvP»
Примечание: Если вы читаете X, то вскоре узнаете, что у Sherlock ужасная репутация, когда речь идет о судействе и эскалации. Хотя они, безусловно, заслужили такую репутацию, важно также признать, что они - единственная платформа, которая полностью прозрачна во всем. У других платформ также есть некоторые из этих проблем, но они держат их в секрете. Поэтому при сравнении платформ не следует рассматривать их как черно-белые, а скорее как светло-серые/темно-серые.
Компания Шерлок предлагает клиентам гибридную модель между частными аудитами и публичными конкурсами. В каждом конкурсе есть ведущий старший Ватсон - эксперт, который получает фиксированный процент от конкурсного пула. Затем LSW соревнуется с каждым участвующим аудитором за оставшуюся часть банка.
Основная ценность «Шерлока» - меритократия. Хотите стать LSW? Тогда победите его и займите его место. Хотите стать ведущим судьей? Тогда победите нынешнего судью и станьте судьей. Все - это соревнование, в котором побеждает тот, кто стоит первым.
Преимущества:
- Если вы любите бесконечные споры и безжалостную конкуренцию, это место для вас.
- Это делают немногие, поэтому количество участников ниже, чем на других платформах.
- Постоянный поток небольших конкурсов с очень коротким циклом обратной связи.
- Если вы сможете стать LSW, вы будете в большом плюсе.
Недостатки:
- Судьи выбираются через соревновательную систему лидерборда, подобную LSW, где они соревнуются в судействе сообщества после каждого конкурса. Лучший участник может стать ведущим судьей конкурса. Однако вознаграждение судьи чрезвычайно мало по сравнению с другими платформами. В результате у тех, кто обладает необходимым опытом для правильного судейства, нет экономического стимула участвовать в конкурсе. Следовательно, зачастую ведущий судья не обладает необходимыми знаниями.
- Отсутствие объяснений, почему результат признан недействительным, и недоверие к ведущему судье приводят к неприличному количеству эскалаций в каждом конкурсе.
- Каждая эскалация быстро превращается в перепалку между участниками, которые экономически стимулированы делать все, чтобы победить. Если вам удастся подтвердить недействительный вывод, судья потеряет деньги. Если вы можете признать недействительным чужой вывод, вы получаете деньги. В сущности, предательство выгодно, а «твоя потеря - моя выгода», так что это становится нормой.
- Эскалация может затянуться на недели.
-Интерпретация правил судейства Шерлока может меняться в разных конкурсах, а также рамки конкурса могут меняться во время или даже после его завершения.
4. Hats: «Скорость - это любовь, скорость - это жизнь»
Уникальная платформа Hats Finance полностью основана на скорости. Каждый конкурс - это гонка, в которой вознаграждается только тот, кто первым представит находку. Заявка подается на цепочке с доказательством концепции, и временная метка решает, получите ли вы все или ничего.
Преимущества:
- Если вы любите адреналин, то вам обязательно понравится Hats.
- Банк не разбавляется дубликатами. Так что если вы попали в банк, то вы попали в него по-крупному.
Многим не нравится давление, поэтому конкуренция намного ниже, чем на других платформах.
Недостатки:
- Высокая дисперсия. Вы можете подать 10 правильных заявок и получить 0 долларов только потому, что опоздали на 1 секунду.
- Психический стресс. Мало того, что вы не знаете, будет ли ваша находка признана достоверной, так еще и дополнительный стресс от того, что вы не знаете, были ли вы первыми.
5. Cantina: «There Be Dragons»
❤1👍1