Стрим от Патрика

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

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

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

Ну, а для нас, это будет хорошим поводом посмотреть, как проходит работа аудитора: от подготовки до просмотра кода.

Первый стрим уже был вчера. Сегодня будет новый в 23:30 по мск.

Записи изначально сохраняются на Твитч, но он планирует позже выложить их на Ютуб.

Ссылка на канал Патрика на Твитч.

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

#audit

Соберем воркшоп / шеринг / конфу? Часть 2

Ранее я делал пост с предложением собрать небольшой онлайн воркшоп или конференцию. Вот ссылка, если хотите прочитать больше.

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

Настало время собрать спикеров.

На данный момент, есть несколько человек, которые готовы раскрыть темы аудита, абстрактных аккаунтов и lens протокола.

Если вы хотите выступить спикером и раскрыть интересующую вас тему, то напишите мне в личку или в комментариях к посту.

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

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

Кто готов?

P.S. Буду признателен, если сделаете репост в свои каналы и чаты, или просто продублируете сообщение о наборе спикеров для онлайн конференции.

#conf #workshop

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

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

Для начала, упомяну, что я пропустил февральский аудит Optimism, так после первого взгляда решил, что он еще "не моего поля ягода". А зря...

По своей сути, zkSync, так же как и Optimism, является layer 2 от Эфира. Другими словами, вы проводите аудит смарт контрактов другого уровня, нежели популярные протоколы с nft и токенами.

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

1. Чтение документации происходит на всех уровнях аудита.

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

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

Только так вы сможете понять сразу несколько вещей:

- Что делает эта конкретная функция?
- Какой результат ее исполнения должен быть?

И что самое главное:

- Что подразумевал разработчик, когда ее писал?
- Какой ход исполнения, может нарушить результат?

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

#zksync #era #audit #feedback

По следам аудита 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