Новый тест от 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

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

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

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

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

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

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

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

Вариант 1:

batchReward()
manualReward()

Вариант 2:

manualReward()
batchReward()

Вариант 3:

manualReward()
manualReward()

В конечном итоге, он стал рассматривать их также с учетом временных рамок:

manualReward(A-D)
batchReward(E-H)
manualReward(E-H)
batchReward(A-D)

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

Аудитору нужно иметь в виду, что если где-то предусмотрен порядок (основанный на времени, метках или чем-то еще), то нужно рассмотреть все способы, что "сломать" его.

#audit #outofbox

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

Отличный пример логического недочета, который нашел только Trust, в протоколе Forgeries.

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

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

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

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

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

Меня всегда поражало, как такие аудиторы, как Trust, могут думать вне рамок контракта. Хочу научиться также.

#audit #outofbox

Баг в компиляторе Solidity

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

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

Если вы использовали функции из подключенной библиотеки в конструкторе своего контракта, то они должны были быть использованы только в initcode. Однако созданный из них байткод включался также и в runtime. Это приводило к тому, что размер контракта увеличивался, как и стоимость его разворачивания. В некоторых случаях, такой "не нужный код" мог занимать до трети от размера контракта!

По словам комментаторов, этот баг актуален для всех версий Solidity ниже 0.18, т.е. самой последней.

#solidity #solc

ERC-4337 в основной сети Ethereum

Разработчики развернули стандарт ERC-4337 в основной сети Ethereum. Это ключевое усовершенствование блокчейна, которое существенно упростит доступ пользователей к заблокированным кошелькам.

Стандарт ERC-4337 позволит разработчикам Ethereum реализовать технологию абстракции учетной записи. Это значит, что пользователям больше не придется запоминать или записывать сложную фразу для восстановления. Вместо этого уникальные криптографические ключи можно будет фиксировать в стандартных модулях безопасности смартфонов. Таким образом, абстракция превратит телефоны в простые в использовании аппаратные кошельки, что может значительно способствовать массовому внедрению криптовалют.

У данной технологии также есть ряд других важных преимуществ:

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

По словам разработчиков Ethereum, абстракция учетной записи имеет «те же функции, что и банк, без необходимости доверять банку». Эксперты считают, что в 2023 году смарт-аккаунты получат мощный импульс для развития.

#eip4337

Выпустили Foundry v0.2.0

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

Если говорить кратко, то:

1) Скорость компиляции стала еще быстрее;
2) Также как и скорость проведения тестов;
3) Команда forge test -vvvv показывает не только путь выполнения, но и выводит данные на каждый субвызов;
4) Отчет по газу стал еще круче;
5) Появился интерактивный дебаггер;
6) Добавились новые читкоды (пока список не нашел, возможно, еще не обновили доки);
7) Появилась еще более гибкая кастомизация toml файла;
8) Более простая установка;

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

#foundry

Заметка о проведении аудита

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

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

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

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

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

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

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

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

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

Всем удачных аудитов!

#audit

Отличный совет от аудитора

Недавно вышел новый Shorts на YouTube от опытного аудитора Owen Thurm, в котором он дает дельный совет, как проводить аудит и на что обращать внимание.

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

Ссылка на видео.

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

#audit

Аудит в коопе

Вероятно, некоторые из вас знают, что в недавнем конкурсе на аудит Optimism двое участников, Trust и Obront, получили более 100к за одну единственную уязвимость в коде.

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

1) Они создали отдельный сервер на Дискорд. Не канал, а именно сервер. Это позволило организовать общение по тематическим веткам, и держать основные моменты аудита в фокусе.

2) У них было три основные категории на сервере:

- Текстовые каналы: любые обсуждения, не связанные с какими-либо багами;
- Лиды: обсуждали все, что казалось интересным по коду (например, неподтвержденные баги);
- Подтвержденные баги

3) Они оба "шли по коду", как если бы они делали аудит каждый по отдельности. И как только кто-либо находил интересную штуку, он начинал новый канал в Лидах. Это позволяло держать партнера в курсе находок, не прерывая друг друга.

4) После того, как Лид был подтвержден, он перемещался в другой раздел: Подтвержденные баги. Они использовали смайлы для обозначения уровня угрозы уязвимости (⚪️, 🟡, 🟢), а также ✅, когда отчет был написан, и 🎉, когда отчет был отправлен.

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

6) Телефонные созвоны. Порой это может отвлекать, но они иногда устраивали короткие созвоны, чтобы "быть на одной волне":

- Брифинг: когда партнер углублялся в нюанс кода, нужно было, чтобы другой узнал о результатах;
- Брейнсторм: после 1 недели они обсуждали возможные эксплойты и фокус на 2 неделю;
- Обмен знаниями: тут и так понятно;

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

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

#audit

Твит от Pashov

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

Основной перевод: Есть некоторая причина, почему профессия называется Исследователь по безопасности смарт контрактов, так как вы должны быть хороши в поисковых мероприятиях. Прежде чем просить совет или задавать вопрос, попробуйте поискать ответ в Твиттере или Гугл. Так вы сможете усилить свои навыки и знания в данной сфере.

#hint

Немного о конкурсах и аудиторах

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

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

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

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

#hint