Что по аудиту? Sablier - результаты
Только вчера вечером изучал предварительные результаты конкурса и сегодня уже в комментах увидел вопрос о том, приняли ли мои находки.
Нет, оба репорта оказались не валидными. И раз уж я пошел делиться с вами своим процессом аудита, то будет правильно рассказать вам об "ожиданиях на бум" и столкновением с реальностью.
Всего сейчас в конкурсе три подтвержденных находки уровня Low.
Я отправил два репорта, вместо трех, как хотел изначально. И знаете, какой был третий репорт? Да, как раз на расхождение со стандартом ERC4906. Почему же я не отправил его?
После изучения протокола я увидел, что Sablier превосходно подготовились к аудиту и не оставили никаких более-менее открытых возможностей для атаки. Контракт отличается высоким уровнем безопасности и продуманности. И такая проблема, как расхождение со стандартом, скорее всего, была обусловлена выбором самих разработчиков. И что ее посчитают максимум Info, и все равно сделают не валидной.
По своему первому репорту, я понадеялся, что "прокатит". Да, видел в репорте от LightChaser есть пункт на отсутствие проверки аргументов на нулевой адрес. При этом там были явно указаны некоторые функции, где такой проверки не было. Я же обратил внимание на ситуацию, которая не была описана в отчете. Судьи посчитали, что это "проблема одной сути" (что по факту так и есть) и поставили invalid.
Со вторым репортом я сам ошибся и только вчера понял, что если бы уделил чуть больше времени на валидацию находки, то ничего бы в итоге не отправил.
Когда я просматривал контракты, то обратил внимание, что в одной из функций сначала было деление (descale), а потом умножение (scale). Решил, что это обычная математическая проблема и не проверил, на что она повлияет. В итоге получилось, что я был отчасти прав и это часть уже была указана в одном из предыдущих репортов.
В завершение могу сказать, что упустил две проблемы:
1. Пользователи могут избежать комиссии, делая депозит мелких сумм.
2. Оракул возвращает одинаковые значения для разных по сути Flow.
И если про первый баг, я даже не задумывался, то со вторым интереснее...
Я писал, что понял протокол где-то на 90%. И функция, в которой был найден 2 баг, была как раз в этих 10%. Я тогда (да и сейчас), не особо понял, зачем вообще нужна эта функция. К тому же она не использовалась ни в каких других в протоколе. Грубо говоря, тогда я решил просто "забить" на нее и фокусировал внимание на основной части протокола.
Думаю, стоит вынести пару уроков из этого конкурса:
1. Подавайте все, что вам кажется будет валидным. Не стоит делать за судей работу и решать уровни багов. Нашли несоответствие стандарту - подавайте. Даже если эту находку не примут, вы ничего не потеряете.
2. Проверяйте лучше свои находки. Если вы нашли какую-то проблему в контракте, то потратьте больше времени на подтверждение своей находки. Не стоит полагаться, что если подобное было раньше, то 100% это засчитают и сейчас. Проверяйте! А лучше напишите тест, если время вам позволяет.
3. Старайтесь понять протокол на 100%. Если вы планируете стать аудитором на все рабочее время, то для хороших находок вам нужно понимать весь протокол целиком. Даже из этого конкурса можно вынести то, что в нишевой функции, которая нигде больше не используется, может быть проблема.
Вскоре заканчивается еще один маленький конкурс на Codehawks и после него я также поделюсь своими заметками и наблюдениями!
Всем приятной недели и легкого обучения!
#audit
Только вчера вечером изучал предварительные результаты конкурса и сегодня уже в комментах увидел вопрос о том, приняли ли мои находки.
Нет, оба репорта оказались не валидными. И раз уж я пошел делиться с вами своим процессом аудита, то будет правильно рассказать вам об "ожиданиях на бум" и столкновением с реальностью.
Всего сейчас в конкурсе три подтвержденных находки уровня Low.
Я отправил два репорта, вместо трех, как хотел изначально. И знаете, какой был третий репорт? Да, как раз на расхождение со стандартом ERC4906. Почему же я не отправил его?
После изучения протокола я увидел, что Sablier превосходно подготовились к аудиту и не оставили никаких более-менее открытых возможностей для атаки. Контракт отличается высоким уровнем безопасности и продуманности. И такая проблема, как расхождение со стандартом, скорее всего, была обусловлена выбором самих разработчиков. И что ее посчитают максимум Info, и все равно сделают не валидной.
По своему первому репорту, я понадеялся, что "прокатит". Да, видел в репорте от LightChaser есть пункт на отсутствие проверки аргументов на нулевой адрес. При этом там были явно указаны некоторые функции, где такой проверки не было. Я же обратил внимание на ситуацию, которая не была описана в отчете. Судьи посчитали, что это "проблема одной сути" (что по факту так и есть) и поставили invalid.
Со вторым репортом я сам ошибся и только вчера понял, что если бы уделил чуть больше времени на валидацию находки, то ничего бы в итоге не отправил.
Когда я просматривал контракты, то обратил внимание, что в одной из функций сначала было деление (descale), а потом умножение (scale). Решил, что это обычная математическая проблема и не проверил, на что она повлияет. В итоге получилось, что я был отчасти прав и это часть уже была указана в одном из предыдущих репортов.
В завершение могу сказать, что упустил две проблемы:
1. Пользователи могут избежать комиссии, делая депозит мелких сумм.
2. Оракул возвращает одинаковые значения для разных по сути Flow.
И если про первый баг, я даже не задумывался, то со вторым интереснее...
Я писал, что понял протокол где-то на 90%. И функция, в которой был найден 2 баг, была как раз в этих 10%. Я тогда (да и сейчас), не особо понял, зачем вообще нужна эта функция. К тому же она не использовалась ни в каких других в протоколе. Грубо говоря, тогда я решил просто "забить" на нее и фокусировал внимание на основной части протокола.
Думаю, стоит вынести пару уроков из этого конкурса:
1. Подавайте все, что вам кажется будет валидным. Не стоит делать за судей работу и решать уровни багов. Нашли несоответствие стандарту - подавайте. Даже если эту находку не примут, вы ничего не потеряете.
2. Проверяйте лучше свои находки. Если вы нашли какую-то проблему в контракте, то потратьте больше времени на подтверждение своей находки. Не стоит полагаться, что если подобное было раньше, то 100% это засчитают и сейчас. Проверяйте! А лучше напишите тест, если время вам позволяет.
3. Старайтесь понять протокол на 100%. Если вы планируете стать аудитором на все рабочее время, то для хороших находок вам нужно понимать весь протокол целиком. Даже из этого конкурса можно вынести то, что в нишевой функции, которая нигде больше не используется, может быть проблема.
Вскоре заканчивается еще один маленький конкурс на Codehawks и после него я также поделюсь своими заметками и наблюдениями!
Всем приятной недели и легкого обучения!
#audit
❤5🔥4👍1
Небольшая история о путешествии в мире аудита
Этот пост был написан прекрасным аудитором Charles Wang день или два назад. Он делится своим опытом в старте аудита смарт контрактов, и что сработало для него больше всего. Думаю, этот пост будет полезен всем, кто собирается стать аудитором и участвовать в конкурсах.
Первый шаг: Построчный аудит
Когда я только начинал заниматься аудитом, мой подход был чрезвычайно стандартным. Я проверял каждый контракт строка за строкой, понимая бизнес-логику, функцию за функцией.
На этом этапе я сосредоточился на том, чтобы понять, что делает каждая функция и как она вписывается в общую функциональность. Однако такой построчный подход, хотя и был тщательным, имел свои ограничения:
1. Пропущенные уязвимости: Некоторые ошибки, особенно сложные, связанные с кросс-функциональной логикой или логикой, основанной на состояниях, просто невозможно найти, используя только этот подход.
2. Трудности с восприятием общей картины: Сосредоточенность на отдельных строчках кода мешала понять более широкий дизайн контракта или то, как взаимодействуют различные части.
На этом этапе я развивал базовые навыки: понимая синтаксис, структуру и логику, лежащую в основе различных функций, но еще не разработал метод, позволяющий выявить некоторые более сложные или тонкие уязвимости.
На этом этапе было очень тяжело, потому что ресурсы для изучения solidity (не говоря уже об аудите) были крайне ограничены.
Второй шаг: Внедрение перехода между функциями и дифференциации состояний
На втором этапе я адаптировал свой процесс, чтобы устранить ограничения чисто построчного аудита. Я начал переходить от одной функции к другой, отслеживая, как различные функции связаны и взаимодействуют друг с другом. Этот переход помог мне лучше понять управление состоянием контрактов:
1. Лучшее понимание контекста: Понимая взаимосвязи между функциями, я смог выявить уязвимости при переходе от одного состояния контракта к другому.
2. Аудит на основе функциональности: Вместо того чтобы сосредоточиться на отдельных строках, я начал рассматривать функции как часть более широкого контекста. Это позволило мне обнаружить логические проблемы, возникающие при использовании функций вместе или в определенной последовательности.
Такой подход помог мне выявить больше ошибок и улучшил мою способность анализировать сложные взаимодействия функций. К этому моменту у меня сформировался более целостный взгляд на код, но способность эффективно выявлять теоретико-игровые проблемы или уязвимости в состояниях контракта все еще не была совершенной.
Третий шаг: Первоначальная оценка через разделение state
На третьем этапе я начал аудит с первоначальной оценки на основе состояний контракта. С приобретением опыта я обнаружил, что могу выявить потенциальные слабые места, просто составив карту различных состояний и взаимодействий:
1. Предварительная идентификация ошибок: Во время этой первоначальной оценки я уже мог находить ошибки, просто классифицируя и понимая состояния контракта. Процесс разделения и анализа этих состояний прояснил многие уязвимости с самого начала.
2. Распознавание паттернов и чувствительность: Опыт научил меня распознавать закономерности и определять области, которые могут содержать уязвимости. Определенные шаблоны кодирования или переходы состояний становились «красными флажками», и я интуитивно понимал, где искать. Не следует путать это с подбором шаблонов, чем в наши дни занимается большинство аудиторов.
Такое смещение фокуса позволило мне глубже понять динамику контракта, что облегчило обнаружение уязвимостей в более широкой логике, а не только в отдельных функциях. На этом этапе я начал выявлять более сложные ошибки и крайние случаи, особенно связанные с переходами состояний и чувствительностью переменных.
Четвертый шаг: Свободный аудит и лиды, основанные на интуиции
Этот пост был написан прекрасным аудитором Charles Wang день или два назад. Он делится своим опытом в старте аудита смарт контрактов, и что сработало для него больше всего. Думаю, этот пост будет полезен всем, кто собирается стать аудитором и участвовать в конкурсах.
Первый шаг: Построчный аудит
Когда я только начинал заниматься аудитом, мой подход был чрезвычайно стандартным. Я проверял каждый контракт строка за строкой, понимая бизнес-логику, функцию за функцией.
На этом этапе я сосредоточился на том, чтобы понять, что делает каждая функция и как она вписывается в общую функциональность. Однако такой построчный подход, хотя и был тщательным, имел свои ограничения:
1. Пропущенные уязвимости: Некоторые ошибки, особенно сложные, связанные с кросс-функциональной логикой или логикой, основанной на состояниях, просто невозможно найти, используя только этот подход.
2. Трудности с восприятием общей картины: Сосредоточенность на отдельных строчках кода мешала понять более широкий дизайн контракта или то, как взаимодействуют различные части.
На этом этапе я развивал базовые навыки: понимая синтаксис, структуру и логику, лежащую в основе различных функций, но еще не разработал метод, позволяющий выявить некоторые более сложные или тонкие уязвимости.
На этом этапе было очень тяжело, потому что ресурсы для изучения solidity (не говоря уже об аудите) были крайне ограничены.
Второй шаг: Внедрение перехода между функциями и дифференциации состояний
На втором этапе я адаптировал свой процесс, чтобы устранить ограничения чисто построчного аудита. Я начал переходить от одной функции к другой, отслеживая, как различные функции связаны и взаимодействуют друг с другом. Этот переход помог мне лучше понять управление состоянием контрактов:
1. Лучшее понимание контекста: Понимая взаимосвязи между функциями, я смог выявить уязвимости при переходе от одного состояния контракта к другому.
2. Аудит на основе функциональности: Вместо того чтобы сосредоточиться на отдельных строках, я начал рассматривать функции как часть более широкого контекста. Это позволило мне обнаружить логические проблемы, возникающие при использовании функций вместе или в определенной последовательности.
Такой подход помог мне выявить больше ошибок и улучшил мою способность анализировать сложные взаимодействия функций. К этому моменту у меня сформировался более целостный взгляд на код, но способность эффективно выявлять теоретико-игровые проблемы или уязвимости в состояниях контракта все еще не была совершенной.
Третий шаг: Первоначальная оценка через разделение state
На третьем этапе я начал аудит с первоначальной оценки на основе состояний контракта. С приобретением опыта я обнаружил, что могу выявить потенциальные слабые места, просто составив карту различных состояний и взаимодействий:
1. Предварительная идентификация ошибок: Во время этой первоначальной оценки я уже мог находить ошибки, просто классифицируя и понимая состояния контракта. Процесс разделения и анализа этих состояний прояснил многие уязвимости с самого начала.
2. Распознавание паттернов и чувствительность: Опыт научил меня распознавать закономерности и определять области, которые могут содержать уязвимости. Определенные шаблоны кодирования или переходы состояний становились «красными флажками», и я интуитивно понимал, где искать. Не следует путать это с подбором шаблонов, чем в наши дни занимается большинство аудиторов.
Такое смещение фокуса позволило мне глубже понять динамику контракта, что облегчило обнаружение уязвимостей в более широкой логике, а не только в отдельных функциях. На этом этапе я начал выявлять более сложные ошибки и крайние случаи, особенно связанные с переходами состояний и чувствительностью переменных.
Четвертый шаг: Свободный аудит и лиды, основанные на интуиции
👍1
На четвертом этапе мой подход стал в значительной степени основан на интуиции. Я больше не чувствовал необходимости начинать с самого начала контракта или следовать строгому порядку строк. Вместо этого я начинал с произвольного места в архитектуре и первые несколько дней изучал кодовую базу в свободном порядке:
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