Из Solidity в AI и дальше

День задач на канале!

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

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

Первая задача на сегодня довольно сложная. Здесь представлена именно логическая уязвимость. Сможете понять какая?

Решение

passThruGate() проверяет, чтобы пользователь отправил сумму большую, чем gate.ethCost. Однако остатки от требуемой суммы никак не обрабатываются и не возвращаются пользователю, поэтому они остаются заблокированными на контракте. Это считается High risk issue на code4rena.

#task

Читаем отчеты вместе. 9

Если вы читаете отчеты вместе со мной, то можете смело похвалить себя! Вы прочитали на 9 отчетов больше, чем если бы делали все сами!

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

Готовы к финальному на этой неделе? Если да, то поехали! На сегодня у нас отчет от Trust.

Читаем отчет вместе!

#report #audit

Пара слов о курсе Secureum

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

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

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

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

#secureum

Solidity полон сюрпризов

А знали ли вы, что mapping могут держать функции в качестве значения? Или, что функции могут принимать функции в качестве параметров?

Лично для меня это было в диковинку. Наткнулся на эту картинку, опять же, в Твиттере и сначала подумал, что это какой-то прикол. Более того, по указанной ссылке, да и в поиске я не смогу найти информации об этом.

Переписав код со скрина в Ремикс, он скомпилировался без проблем. Да и потом исполнился на раз!

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

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

#mapping #function

Читаем отчеты вместе. 8

Ну, и по традиции, на вечер выкладываю очередной отчет. На этот раз - это новый отчет с code4rena.

Без дополнительные речей, читаем отчет вместе.

#report #audit

Еще раз все сначала

За все время, что учусь делать аудиты и решать задачи, я вел небольшой файл, куда записывал все моменты, на которые стоит обращать внимание: модификаторы, возможности доступа, особенности erc и т.д.

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

Вместе с этим я решил пересмотреть старые посты, где решал задачи Ethernaut, DVD, CTE и другие. И понял, что некоторые я забыл как решать. В том смысле, что попадись подобный пример кода в реальном аудите, я просто бы прошел мимо.

В общем, перекапывал все свои старые заметки и убил полдня.

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

Хотите ли вы вместе со мной пройти курс Secureum? Там около 30 уроков и куча текстового материала. Как я понял, там вообще с нуля вся подача, типа как с 0 до аудитора.

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

Что думаете?

#secureum

Объединение строк

Начиная с версии 0.8.12 в Solidity есть встроенная функция для объединения строк.

#strings

Манипуляции  с block.timestamp

В одной из веток Твиттера наткнулся на интересное рассуждение о манипуляциях хакеров / майнеров с timestamp.

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

Тем не менее, по утверждения автора, в текущих условиях реализации GETH подобные действия могут происходить только в промежутке 15 секунд от блока до блока. Другими словами, если timestamp будет больше, скажем 30 секунд, по нужному условию в контракте, то это будет более безопасно.

Более подробно в по этой ссылке.

#timestamp

Читаем отчеты вместе. 7

Сегодня подумал о том, что есть некая тонкая черта между bug hunter и white hat hacker, баг хантером и белым хакером.

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

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

Позабавило еще то, что в обучении процесс идет как-то так:

1) Сначала мы учимся популярным уязвимостям, читая просто их описание (баг хантер);
2) Затем играемся с CTF и другими задачами (хакер);
3) Идем на популярные конкурсные платформы (баг хантер);
4) Переходим на уровень Immunefi и работы на сетях (хакер);

т.е. идет чередование навыков.  

Но это отступление от темы. А сегодня мы вернемся к Шерлоку и прочитаем еще один не очень сложный отчет.

Итак, читаем вместе!

#report #audit

Учебная группа от Web3SecurityDao

Вчера появилась информация о том, что Web3SecurityDao запускает учебные группы по вопросам безопасности. Созвоны будут проходить на их Дискорд сервере, начало 1 февраля.

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

В общем, меня заинтересовало, может будет также и вам.

Вот ссылка на информационную страницу и Дискорд.

#study

Read-only-reentrancy

Я уже писал ранее о новой уязвимости, которая может получить распространение в этом году. Она основана на том, что даже если функция выполняющая внешний вызов защищена от reentrancy модификатором, библиотекой или как-то еще, но есть другая view / pure функция, которая используется ней, производя какие-то расчеты, например, по выплатам rewards, то все равно сохраняется возможность взлома.

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

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

Обязательно к прочтению для всех аудиторов!

#security #reentracy

Скрин к предыдущему посту

Правило 1/64

До введения стандарта EIP-150, вызывающий (caller) из одного контракта передавал вызываемому (callee) в другой контракт весь свой имеющийся газ.

Тогда, для того, чтобы предотвратить ошибку "stack too deep", максимальное количество вызовов (calls) могло быть не больше 1024, после чего последний вызов обрывался (возвращал fail).

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

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

Правило 1/64 означает, что при любых обстоятельствах у вызывающего останется 1/64 часть от всего доступного газа.

Другой особенность EIP-150 было то, что опкод call теперь имел не фиксированное количество газа, а максимально возможное. При этом, если операция требовала больше газа, чем было возможно по формуле, то транзакция все равно не откатывалась.

Перевод подготовлен на основе ветки Твиттера.

#gas #eip150

Как читать calldata?

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

Автор, DeGatchi, прекрасно рассказывает и показывает на примерах, как правильно читать, да и вообще, из чего состоит calldata.

Предлагаю и вам прочитать данную статью.

Вкратце говоря, автор показывает, что calldata состоит из набора строк по 32 байта и разбивает несколько примеров построчно. Более того, он разбирает несколько вариантов calldata: со статическими переменными, с динамическими и смешанными, а также multicall.

Очень много примеров и скринов. Классная статья!

#calldata

Читаем отчеты вместе. 6

Сегодня на очереди отчет от прекрасного аудитора и одного из наблюдателей Sherlock - Trust. В конце прошлого года он занимал лидирующие позиции на популярных платформах и заслужил доверие многих компаний.

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

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

Итак, читаем отчет вместе!

#report #audit

Чуть больше о Yul (assembly)

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

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

Я нашел интересную статью о yul для начинающих, хоть и на английском языке.

Очень длинная, но хорошо объясняющая базовые опкоды.

Оставлю ее здесь на самостоятельное изучение. А если захотите, сможем сделать день yul и разобрать статью по частям.

#yul #assembly #opcode

Новинка в Solidity 0.8.18

Встретил в Твиттере интересный пост о том, что в Solidity новой версии 0.8.18 появятся операторы (sub, mul, gt, etc.), которые определяются пользователем. Другими словами, разработчики смогут оператор "деления" переписать на функцию "умножения" и т.д. И это сlеkает работу аудитор сложнее, так как:

1) Теперь нужно будет изучать наследования переопределения в контрактах, чтобы разработчики сами не путались в своих расчетах, или ловить "плохих парней", которые хотят обмануть других пользователей;

2) Также теперь такие переопределения не всегда будут pure / view, и смогут выполнять внешние вызовы, что чревато новыми уязвимостями;

В общем, новая версия принесет новые уязвимости. Работы у аудиторов меньше не станет.

Больше можно почитать тут.

#solidity

Экономим газ дважды

Часто в отчетах, в разделе по экономии газа, я встречал, что вместо модификаторов можно использовать функции, а вместо текстовых ошибок, как мы пишем в require(1>2, "Ohh no!") лучше использовать кастомные ошибки.

Поэтому вместо

modifier onlyOwner() {
require(msg.sender == owner, "Not an owner");
}

можно использовать:

function _onlyOwner() internal {
if(msg.sender != owner) revert Error();
}

что позволит вам дважды, хоть и немного, но сэкономить газ.

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

#gas

Читаем отчеты вместе. 5

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

Сегодня на очереди отчет с проекта Sherlock. Там было обнаружено 7 High Risk, 10 Medium Risk, 14 Low risk проблем.

Сам отчет довольно большой, поэтому читать можно в несколько этапов. Не подгоняйте себя, если что-то не понятно. Читайте внимательно.

Приступаем к изучению!

#report #audit

Конкурс на аудит сети Optimism

Только что узнал, что на площадке Sherlock стартовал конкурсный аудит блокчейн сети L2 - Optimism!

И это действительно круто! Да, были классные проекты DeFi, gameFi, биржи и т.д, но они все работали как часть какой-нибудь сети! А тут такое!

Понятное дело, уязвимости там смогут найти, скорее всего, только очень опытные аудиторы (типа Trust, если знаете такого), но все же, я предлагаю и вам попробовать поучаствовать в конкурсе на хардкоре!

Во-первых, это отличная практика работы с крупными проектами. Куча документации для изучения!

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

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

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

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

Конкурс продлится до 6 февраля. Можно даже отдельный чатик создать для обмена идеями и вопросами. Что скажете?

#optimism #contest