По следам аудита zkSync Era. Часть 2

Далее еще один момент, который редко где упоминают.

2. Задавайте вопросы разработчикам и общайтесь в чатах конкурса.

Не зря code4rena и sherlock создают отдельные ветки в своем Дискорде и представляют команду разработчиков или ответственное лицо, который готов отвечать на вопросы.

За время аудита я задал более 20 различных вопросов по zkSync одному из разработчиков. И на каждый был получен детальный ответ! Это сильно помогло мне понять идею некоторых действий и функций.

Не бойтесь писать им в личку! Используйте гугл переводчик, если есть проблемы с английским. Во-первых, это в их интересах дать качественные ответы, которые, возможно, помогут сделать их проект безопаснее. А, во-вторых, это поможет вам лично разобраться с деталями, возможно, найти баг и получить вознаграждение.

#zksync #era #audit #feedback

По следам аудита zkSync Era. Часть 3

Ну, и последний, не совсем очевидный момент, но:

3. На следующий аудит вы потратите меньше сил.

Проекты зачастую возвращаются на конкурсную площадку через некоторое время, после исправлений и совершенствований предыдущего аудита.

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

И все это вы получите, не говоря уж о том, что знатно прокачаете свои навыки.

В конце, хотел бы добавить свое собственное наблюдение по конкурсным проектам.

Я бы порекомендовал начинающим брать более сложные проекты, чтобы начать формировать свой собственный формат аудита. С чего начинать, как двигаться, какие инструменты использовать и т.д.

У меня было так, что я уделял меньше внимания проектам, которые считал простыми. Типа, просмотрел, нашел - не нашел, закрыл. Со сложными - хотелось закопаться в код и доки на пару суток и понять, в чем там дело.

Это помогает мне развиваться. Надеюсь и вы сможете найти для себя пару новых идеи для следующего своего аудита.

#zksync #era #audit #feedback

Найденный баг в Optimism

Хочу тут еще сделать пост о найденном баге, который принес Trust и Obront + 150к в конкурсном аудите. Вот ссылка на сам баг.

Мне пришлось перечитывать его несколько раз, что понять его смысл. Вероятно, вы сможете осознать его быстрее.

Как я сам понял, недочёт крылся в расчетах газа для проведения транзакции. В одной из особенный функций Оптимизм была заложена идея, что пользователь может на свой страх и риск провести транзакцию, которая будет стоить в разы меньше, чем если бы была осуществлена обычным способом. Сама транзакция банальна - перевод денег с L2 на L1.

Так вот, тут расчеты основывали на проверке:

require(gasleft() >= _tx.gasLimit + 20000, "...");

которая была перед вызовом:

bool success = SafeCall.call(
   _tx.target,
   gasleft() - 20000,
   _tx.value,
   _tx.data
);

и все бы ничего, если между ними не было установки переменной: l2Sender = _tx.sender.

Разработчики не учли, что и это тоже требует расхода газа.

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

Если газа не хватало, то активы пользователя навсегда блокировались бы на контракте.

Вот такая маленькая деталь принесла такие большие деньги!

#audit #optimism

По следам аудита от Патрика Коллинса

Выше я делал пост о том, что создатель 32-часового курса по Solidity, Патрик Коллинс, открыл свою аудиторскую компанию и решил провести марафон на несколько дней, делая аудит одного из проектов вживую на стриме.

Я посмотрел его стримы и, таки, мне есть, что сказать.

Точнее обратиться к новичкам и "вечно обучающимся". Не тратьте время на 101% изучения языка, способов проведения тестов и постоянного надумывания, что у вас не хватает какого-нибудь опыта. Всего у вас хватает!

Патрик, не смотря на его опыт и знания, разрешает себе заглядывать в документацию Foundry, EVM, wikipedia, чтобы посмотреть, как реализовать конкретный тест или, что значит этот "сдвиг".

Это нормально! Вы не обязаны знать все, что связано с языком и работой Эфира, чтобы начать что-то делать. Просто невозможно держать все в голове.

Поэтому, немного расслабьтесь и приступайте к практике прямо сегодня.

#audit #feedback

Аудит вне рамок - 12

Интересный аудиторский отчет протокола Rysk, который попросил Trust посмотреть один единственный контракт, который напрямую связан с UniswapV3.

Стоит отметить, что только в этом одном контракте аудитор нашел 2 High, 4 Medium и 4 Low проблемы. И, не смотря на то, что некоторые ошибки можно было найти просто внимательно вчитываясь в код и его логику, несколько нюансов нужно было знать наверняка и исследовать прицельно.

Обращаем внимание при аудите

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

Также и с sqrtPriceX96 в UniswapV3. Вот кто из вас, не заглядывая в доки, может сказать, за что он отвечает? В моем случае, мне будет трудно объяснить это даже, заглянув в документацию...

Два бага в контракте были основаны на том, что разработчики не до конца понимали особенностей работы с sqrtPriceX96 (TRST-M-1, TRST-M-3).

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

#audit #outofbox

Аудит вне рамок - 13

Ранее в некоторых отчетах я натыкался на проблемы с работой enumerable контрактов с ERC721. В этом отчете можно найти прекрасные описания других проблем, но уже с 1155.

Вообще, как я понял, если в аудите вы встречаете не самый популярный контракт, те же enumerable, metadata, необычные eip, то всегда нужно уделять дополнительное время для его изучения.

P.S. Посты из данной тематики теперь будут выходить в виде заметок, для самостоятельного и более подробного изучения отчетов.

#audit #outofbox

Аудит вне рамок - 14

Еще один интересный баг, основанный на abi.encodeWithSignature() и рефанде неиспользованного газа обратно пользователю.

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

#audit #outofbox

Аудит вне рамок - 15

Необычная особенность стандарта 4337, которая гласит, что "... to prevent replay attacks ... the signature should depend on chainid".

Другими словами, если вы используете этот eip, то в проверку подписи нужно включать еще и id блокчейн сети, так как без нее появляется возможность Cross-Chain Signature Replay Attack.

#audit #outofbox

ERC2612, ERC20Permit, аппрув без газа, EIP712

На канале у Ильи вышел новый интересный урок. Смотрим и учимся.

#erc2612 #permit #approve

ReentrancyGuard в прокси?

Необычный способ реализации ReentrancyGuard предложила одна из команд на мероприятии ETHDenver 2023 Hackathon.

Основной смысл заключается в том, чтобы вместо добавления модификатора ReentrancyGuard в каждую функцию в контракте Логики, создать защиту только в Прокси контракте.

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

Более подробно можно прочитать в этой статье.

Возможно, мы скоро увидим этот концепт в конкурсных аудитах.

#reentrancy #security #proxy

Обновления и патчи Openzeppelin

В разделе Security в репо Openzeppeling можно найти информацию о проблемах в старых версиях контрактов и версии патчей, когда эти уязвимости были поправлены.

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

#openzeppelin

Больше о побитовых операциях

На днях в одном из конкурсных аудитов встретил следующий код:

function hasBeenDistributed(uint256 _index) public view returns (bool) {

    uint256 distributedWordIndex = _index / 256;
    uint256 distributedBitIndex = _index % 256;
    uint256 distributedWord = distributedBitMap[distributedWordIndex];
    uint256 mask = (1 << distributedBitIndex);

    return distributedWord & mask == mask;
}

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

Если для вас предельно понятны функции в тестовом примере и на скрине поста, то, поздравляю, с побитовыми операциями у вас все в порядке. Если же нет, то следующие три статьи прольют больше света на этот вопрос.

Статьи на английском языке, но время на них стоит потратить, чтобы хорошо разобраться.

Во-первых, читаем эту статью на Медиум.

Потом читаем пост с Solidity Developer. Спасибо @SovaSlava, что показал мне ее.

И в конце, получаем небольшой разбор с операциями со скрина.

Надеюсь, после этого вам, как и мне, станет более понятна логики таких действий.

#bitmap #bit

Интервью с Zach Obront

Недавно вышло интервью с Заком, тем самым аудитором, который вместе с Trust нашел крутой критический баг в сети Optimism.

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

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

Смотрим видео и вдохновляемся!

Приятного просмотра.

#obront

Not So-Famous Solidity Attack Vectors

Одновременно прекрасное и ужасное видео с с конференции ETH Dubai, рассказывающее о не самых очевидных атаках в смарт контрактах.

Прекрасное оно из-за набора тем, которые поднимает спикер. Многие из них действительно могут быть упущены при аудите. Ужасное же оно только из-за сложности восприятия речи. Будет сложно даже тем, кто хорошо знает и понимает английский язык.

Тем не менее, видео достойное для изучения.

#security #ethdubai

5 стадий обучения аудитора

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

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

Поэтому тут я скорее за разделение профессий. Фокус на чем-то одном, будет быстрее продвигать вас в обучении.

Во-вторых, для себя я определил 5 глобальных стадий обучения аудитора.

1. Обучение базовым уязвимостям в смарт контрактах. Тут будет достаточно получить понимание, чем реентранси отличается от dos атак. Ну, и знать, как их искать в коде. Для этого вообще не обязательно записываться на онлайн курсы. Вся информация есть на этом канале и в сети, на первых страницах гугла.

2. Решение задач. Ethernaut, dvd, CTE и любые другие задачи будут невероятно качественным подспорьем на этой стадии. Тут для аудитора важно будет начать определять участки кода с возможной проблемой и находить варианты взлома.

3. Аудиторские отчеты. Только после того, как вы научитесь решать задачи, стоит преступать к чтению отчетов. Можно брать отчеты с популярных площадок, типа c4, или от профессиональных аудиторов, типа obront. На этом этапе нужно понять, что уязвимости в контрактах выходят за рамки обычных задача. Будет не лишним и самому повторять доказательные тесты в своей ide.

4. Конкурсы. После того, как вы потратите некоторое время на изучение отчетов, можно и самим попробовать зарегистрироваться на конкурсных площадках и начать проводить аудиты. Тут вы научитесь подготавливать проект для аудита, устанавливать его зависимости и писать первые отчеты.

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

Вполне вероятно, чуть позже я добавлю еще пару стадий. Но сейчас я сам на последней из них.

Фокус и практика сделают вас прекрасным специалистом.

#audit

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#audit #report

ERC4626: Tokenized vaults

Очередное прекрасное видео от Ильи. Как вы поняли из названия, в этот раз мы поговорим о стандарте ERC4626, какие проблемы он решает и как стоит его использовать в свои проектах.

Приятного просмотра!

#erc4626

Аудитор, продавай свои баги

Написать этот пост меня сподвигла ситуация, которая происходила со мной на площадках code4rena и sherlock. Можно прочитать сотни аудиторских отчетов, понять важные уязвимости и методы их предотвращения, но упустить из виду один важный момент: то, как пишутся сами отчеты.

Поначалу, я думал, что баг есть баг: если ты его нашел, то молодец, получай оплату. Но не тут-то было.

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

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

Тем не менее, его отклонили. Однако этот репорт пометили, как High, а сам аудитор получил $2382.89 USDC, хотя суть проблемы такая же: доступ к функциям для всех.

Другая находка из аудита протокола Kairos, которую отклонили судьи, особо не вникая.

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

Третья, как мне кажется, валидная находка была в протоколе Токио, которая была принята судьями, но отвергнута самими разработчиками. Если бы было сделано описание как это может повлиять на работу проекта в будущем с приведенными цифрами, уверен, что итоговое решение было бы другим.

Для себя я вынес несколько правил по работе с конкурсными площадками, да и в целом, по работе аудитора:

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

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

3. Очень часто на конкурсах ставится флажок, что админ \ модератор по-умолчанию хорошие ребята и все связанные с ними бага исключаются. Старайтесь не приплетать админов протокола к ответственности, даже когда проблема напрямую зависит от них. Старайтесь описывать проблему, а не качества админа.

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

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

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

#audit #report

Шаблон для форка и тестов в Foundry

В Твиттере поделились новой библиотекой для простого форка EVM совместимых сетей и написания тестов.

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

#foundry #fork

Honeypot или Jackpot?

Потрясающая задачка из Твиттера! Я не сразу понял, в чем тут дело и пришлось лезть в документацию и Ремикс, чтобы разобраться.

А что вы скажете?

Ответ опубликую чуть позже в комментах.

#task #types