Немного о фантомных функциях

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

Сама статья на английском языке, но ее суть в том, что если в контракте токена, как например в WETH, нет функции permit(), но есть fallback(), то вызывая из вашего контракта weth.premit() - транзакция не откатится с ошибкой.

Это может быть уязвимостью, как было в примере с AnySwap/MultiChain.

Подробнее читаем в статье.

#phantom #fallback #permit

Аудит вживую

Сейчас на Шерлоке проходит конкурсный аудит для проекта GMX. Один из аудиторов, Owen Thurm из Solidity Lab, уже ранее работал с этой компанией и сейчас выкладывает некоторые свои наработки в помощь участникам.

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

В общем, рекомендую всем начинающим аудиторам.

Смотрим видео вместе.

Кстати, кто-нибудь из участников участвует в данном конкурсе?

#audit

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

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

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

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

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

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

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

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

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

#audit #outofbox

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

Посмотрите на данный отчет о найденной уязвимости в контрактах проекта Ajna.

Когда пользователь закрывает свой стейкинг, то система удаляет информацию о takes[tokenId_], однако упускает удаление snapshot, который хранится в маппинге в структуре StakeInfo. В конечном итоге это может привести к тому, что хакер, зная об этой уязвимости, может использовать информацию из не удаленного snapshot повторно для получения extra rewards.

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

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

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

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

#audit #outofbox

Один нюанс про библиотеки

На основе ветки в Твиттере от philogy.

До недавнего времени я был уверен, что в библиотеках могут быть только internal функции, но в одном из конкурсных аудитов было огромное количество библиотек с внешними функциями. Хоть напрямую пользователю их использовать нельзя (только контракты), они несут в себе некоторые неудобства по газу.

Функции в библиотеки используются через delegatecall в других контрактах, что стоит минимум 100 газа за каждый вызов. Более того единоразово к вызову внешней функции добавляется еще 2500 газа.

Таким образом, вызывающий заплатит не менее 2600 газа при вызове external функции из библиотеки.

Это одна из причин, почему в библиотеках рекомендуют использовать только internal функции.

#library #gas

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

Интересный пример, где нужно держать в голове несколько действующих лиц при тестировании функции.

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

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

Тут хочу отметить два момента.

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

2. Кто может обращаться к функции? Да, все пользователи. Но если попробовать разбить их по ролям, то выходит: заемщик, который платит займ, администратор протокола, заниматель, хакер, случайный пользователь и т.д.

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

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

#audit #outofbox

Интересная библиотека SSTORE2

На основе ветки в Твиттере от chrisdior.eth.

В августе прошлого года в проекте Solady появилась новая библиотека SSTORE2, которая, по задумке, была призвана заменить использование дорогого по газу опкода SSTORE.

Например, когда мы хотим сохранить что-то в память, мы используем SSTORE, при этом затрачиваем минимум 20 000 газа за каждые 32 байта.

Библиотека SSTORE2 позволяет нам передавать данные в виде байткода контракта, используя опкод CREATE и затем читать данные через опкод EXTCODECOPY.

Вы также могли бы подумать, что в таблице опкодов стоимость CREATE составляет 32 000 газа, что в разы больше SSTORE. Но дело тут немного в другом.

С SSTORE2 вы передаете данные как байты, которые будут интерпретироваться как переменные, которые вы хотите объявить в новом контракте, а затем вы читаете этот байткод с помощью EXTCODECOPY, что стоит всего 2600 газа.

Таким образом, если вы хотите сохранить 8 переменных в памяти, с обычным опкодом SSTORE это будет стоить около 200 000 газа для записи плюс 20 000 для чтения. А с библиотекой SSTORE2 вы заплатите 88 000 газа для записи плюс 3200 для чтения. Существенная экономия, не так ли?

#opcode #sstore #sstore2 #library

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

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

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

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

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

Говоря кратко, если у какого-либо пользователя есть больше привилегий в протоколе, особенно в отношении активов, то нужно обязательно искать варианты его недобросовестного поведения. 

#audit #outofbox

Foundry для продвинутых

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

И сегодня в очереди первый пост со статьями для тех, кто хочет повысить свои навыки работы с Foundry.

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

2. Создание моста с Foundry. Интересная статья на Медиуме с примерами, как разработчику можно создать свой простой мост между сетями блокчейна.

3. Тулкит для работы с Chainlink в Foundry. Рассказывается, как правильно создать свой узел, сделать первоначальную настройку и подготовить среду для работы.

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

#foundry #forge #scope

Подборка статей для самообучения - 1

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

1. Выпущена новая версия Sol2Uml v2.5.0, которая позволяет, вроде как, читать слоты памяти в публичных контрактах.

2. Побитовые операции в Assembly. Простая и полезная статья от одного из крутых разработчиков 0xWeiss. В аудитах я все чаще встречаю участки кода, где используются сдивиги и маскирование? (masking), поэтому хорошо бы разбираться в этом.

3. Как разбить строку в Solidity на насколько линий. Даже не могу представить случай, когда это может потребоваться, но, возможно, вам будет интересно просто прочитать про то, как разработчик решил эту проблему для себя.

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

5. Как работает ECDSA. Техническая статья о работе библиотеки. Очень много формул, расчетов и подробностей. Возможно, будет интересна тем, кто познает шифрование.

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

7. Пост про MEV. О ней сказать ничего не могу, так как еще очень давно сохранил ее и даже не просмотрел. Ее рекомендовал pashov в своем блоге.

8. Хорошая статьи от Officer CIA об AAVE v3. Там же можно найти ссылки по подобным постам про Convex, Curve V1, Balancer V1 и много чего еще. Простое и понятное объяснение многих моментов.

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

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

#scope #eip712 #mev #ecdsa #aave #bit #sol2uml

Новый тест от Secureum

Хотел поучаствовать хоть в одном таком конкурсе, но, почему-то думал, что они проводятся редко, поэтому отключал все уведомление в Дискорде. Следующую я точно не пропущу!

Тут как обычно 8 вопросов к контракту. Сделано очень удобно: отмечаете галочки, потом открываете ответы и читаете разбор вопроса.

В этот раз у меня получилось 4 полных ответа, 3 частично и 1 мимо.

Пройти тест RACE #15 Of The Secureum Bootcamp.

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

#secureum #test

Подборка статей для самообучения - 2

Вторая подборка статей из моего архива.

1. Немного о библиотеке Solmate's SafeTransferLib. Ее реализация немного отличается от привычной нам библиотеке от OpenZeppelin. При аудите следует обращать на некоторые особенные моменты, которые описываются в данной статье.

2. DAO Voting Vulnerabilities. Хорошая статья от MixBytes, которая рассказывает о популярных уязвимостях в проектах DAO.

3. Кратко о SMTChecker в Solidity и его конфигурации в Foundry. Еще не совсем разобрался, для каких практических целей это может потребоваться, но где-то чую, что может быть полезно для изучения.

4. gasLeft() exploit. Показан пример решения одной из задач в Ethernaut альтернативным способом через внутреннюю функцию проверки остатков газа. Не обычный способ, показывающий, что всегда есть как минимум еще один способ для решения любой задачи. P.S. Обратите внимание на другие статьи от данного автора.

5. Видео об уязвимости в ZK. Популярная сейчас тема, поэтому основы знать нужно.

6. Опкоды с необычным "поведением". Ветка от jtriley, где собраны описания опкодов, которые могут вести себя не так, как запланировано. Будет сложно даже для продвинутых разработчиков.

7. 35 репозиториев для разработчиков. Простая подборка с полезными репо.

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

#scope #dao #zk #solmate #opcode

Передача ownership

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

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

#dao #ownership

Соберем воркшоп / шеринг / конфу?

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

Вот я и подумал, может бросить клич по чатам и каналам, собрать спикеров и провести онлайн созвон с презентациями? Типа, за этот месяц бла бла бла...

Темы самые разнообразные:

- Общие новости в блокчейне;
- Разборы контрактов;
- Последние хаки;
- Инструменты для разработки;
- Вопросы по кодингу;

и много других. Главное с презентациями! Для спикеров это будет дополнительной рекламой (деятельности, каналов, проектов), а для интересующихся - отличный способ быть в теме.

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

Что думаете? Для первого раза было бы хорошо собрать человек 7-8.

Можете скопировать тест поста (или сделать репост, если вам норм), и спросить у своих участников в каналах / чатах.

#conf

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

Интересная логическая ошибка, которая была найдена в протоколе NounsDAO.

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

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

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

Как например в данном баге, при создании события stoptime не должен быть меньше block.timestamp, иначе событие будет невозможно отменить в будущем.

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

#audit #outofbox

Проверка для токенов с комиссией

Если проект предусматривает работу с токенами, в который есть возможность комиссии за перевод, например токен PAXG , то следует делать дополнительные проверки.

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

#token #transfer

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

В этом баге, протокола FrankenDAO, показан менее популярный нюанс, который встречается в работе с NFT.

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

Вообще, разработчикам нужно быть внимательными при работе с переводами NFT. В одном случае, safeTransferFrom() может привести к атаке reentrancy, во втором, с простым ERC721.transferFrom(), - к блокировке NFT внутри контракта.

#audit #outofbox

Обновления в Foundry

Разработчики выпустили новую версию библиотеки forge-std, добавив туда несколько новых команд и улучшений.

Во-первых, теперь можно выделять различными цветами вывод текста в консоли командой: 

console2.log(StdStyle.red("my red string"))

что сделает более удобным поиск нужно информации. Там есть и другие цвета: red, green, yellow, blue, magenta, cyan, bold, italic, underline, dim, и inverse.

Во-вторых, команда deal, с помощью которой мы могли "закинуть" себе токенов на счет в тестах, теперь работает и для стандартов ERC721 и ERC1155, например:

dealERC1155(bar, address(this), 0, 1000e18, true)

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

В-четвертых, появилась команда vm.expectCallMinGas, которая ожидает вызов на адрес с указанными параметрами, включая количество газа. Не уверен в точном переводе, но так она звучит в оригинале: vm.expectCall variants to assert on the minimum amount of gas passed to a call.

В-пятых, вместо expected/actual в выводе ошибок, теперь будет left/right. Вообще не понял смысл этого переименования, но, вероятно, разработчики вкладывали какой-то смысл в это.

В этой ветке в Твиттере можете посмотреть скрины с примерами.

#foundry #forge

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

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

Все мы привыкли к стандартным математическим функциям со знаками -, +, *, /. Также мы уже знаем, что деление перед умножением может привести к ошибке практически в каждом случае. Однако, есть не совсем очевидные моменты с математическими операциями.

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

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

Деление, в некоторых случаях, может выполняться перед умножением, даже, если функции умножения идут впереди. Сложно представить? Посмотрите на пример ниже:

newRewards_ = Maths.wmul(
REWARD_FACTOR,
Maths.wmul(
   Maths.wdiv (
     interestEarned_, totalInterestEarnedInPeriod
    ), totalBurnedInPeriod
)
);

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

#audit #outofbox

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

Аудитор Zzykxx, который под менторством популярного хакера Trust, написал статью, о том, как небольшой комментарий разработчиков в коде, помог ему найти уязвимость в контракте протокола Thena.

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

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

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

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

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

#audit #outofbox

Hardhat + Foundry

Знали ли вы, что в проект, где использовался hardhat можно установить Foundry и дальше работать с ним?

Порой это может быть полезно, когда вы делаете конкурсный аудит, а там используется hardhat. Для своего удобства вы можете добавить Foundry, при условии, что у вас уже установлен forge.

Для этого следует установить в ваш проект foundry командой:

npm install --save-dev @nomicfoundation/hardhat-foundry

Добавить в конфиг файл

import "@nomicfoundation/hardhat-foundry"; (ts)
или
require("@nomicfoundation/hardhat-foundry"); (js)

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

npx hardhat init-foundry

которая установит библиотеку forge-std и создаст файл foundry.toml. После этого вы сможете использовать foundry для своих нужд.

#foundry #hardhat