В начале своего пути в крипте, когда почти ни чего не понимал в кодинге смарт-контрактов сам чуть не попал в такую ловушку

Изучал последние добавленные блоки на езерскане и наткнулся на такой контракт-квиз

https://etherscan.io/address/0xad63b86d77b9c84cbc81cf3c1cf5136de0297e11

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

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

УРА! пошли в езерскан смотреть ответ!

Вот транзакция в которой хранится ответ. Ну ничего себе! еще и 30 эфиров. Я буду богат!

Скорей открываю транзакцию вижу заветный ответ

Нет, нет, не может быть все просто. Здесь где то обман!

Иду смотреть контракт снова.

Ответ на загадку хранится в как bytes32. В функции Start эта переменная сохраняет хеш из строки, которую только что нашел на езерскане.

А в функции New эта переменная не расчитывается ончейн, а значит ее знает только админ

Может функия New не была еще вызвана? снова смотрим езерскан.

Во внешних вызовах нет New

Во внутриних вызовах только пересылка эфиров

Может езерскан врет. Нужен более профессиональный инструмент! воспользуемся тендерли

Тут тоже нет вызова New. Похоже мошенник забыл активировать ловушку! и я все таки могу забрать 30 эфиров

А, стоп, а что это?

Вот спрятанная транзакиция, активирующая ловушку!

Но даже если бы эта ловушка не была активирована - не факт что удалось бы вывести 30 эфиров.

Возможно, что нашу транзакцию зафронтранили и снял бы эфиры раньше нас

1. стать админом прокси

Нам даны 2 контракта: Контракт прокси и Реализация Кошелька

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

Для этого нам нужно понять что такое слоты памяти proxy и delegatecall

Слот памяти - 32 байтная ячейка памяти, в которой хранится переменная(ые) смарт контракта. Компилятор может оптимизировать память и помещать несколько переменных в один слот.

Главное что нужно помнить - у каждого контракта есть своя память

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

Это промежуточный смарт-контракт, который перенаправляет запрос пользователя в актуальную версию смарт-контракта

Но в такой простой реализации кроется проблема - если мы мы использовали call в контракт-реализацию, то если мы публикуем новую версию контракта-реализации, то все наши данные (настройки, балансы пользователей и т.п) теряются, т.к были использованы слоты памяти, которые остались на старой версии контракта.

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

Тут приходит на помощь функция delegatecall.

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

Разберем на примере

Для хранения переменных используются слоты в порядке их объявления в реализации

Если мы добавляем новую переменную в новой версии реализации, то будет использован соответствующий слот

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

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

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

Теперь обладая новыми знаниями взглянем на контракты

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

Из этого следует, что переписать значение переменной admin в proxy мы можем вызвать изменение maxBalance в контракте реализующем логику.

Видим что у функции setMaxBalance есть модификатор onlyWhitelisted

Что бы добавить себя в вайтлист нужно вызвать функцию addToWhitelist

Но нам мешает require, который проверяет owner'a

Проверим что за адрес выдается по запросу owner'a

Изучив код контракта мы видим, что переменная owner занимает 1й слот и переменная pendingAdmin в прокси контракте находится в том же слоте

Воспользуемся этой уязвимостью - Что бы стать owner'ом вызовем фунцию proposeNewAdmin в прокси контракте, предложив в качестве нового админа свой адрес

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

Копируем адрес инстанса из ethernaut'а и вставляем в Remix в поле рядом с кнопкой At address. Нажимаем кнопку

У нас появился интерфейс для взаимодействия с прокси

Нажимаем кнопку proposeNewAdmin, вставив свой адрес в поле рядом. Ждем пока исполнится транзакция. Переходим в ethernaut и проверяем owner'a

Видим что теперь здесь наш адрес

Теперь, когда мы owner - добавляем так же свой адрес в вайтлист

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

Рассмотрев реализацию контракта PuzzleWallet мы видим, что в функции execute можем снять только те эфиры, которые задепазитили в функции deposit

Также мы видим что в функции multicall есть ограничение, которое не дает вызвать повторно функцию deposit в рамках мультиколла, что бы учесть полученные эфиры только один раз

Функция multicall принимает массив байт - последовательность селекторов функций

Например [ func1, func2, func3 ]

и в цикле вызывает переданные ей функции

Данная реализация multicall'a защищена от передачи такого параметра [deposit, deposit]

Но данная реализация не защитит контракт, если мы пошлем вызов multicall в multicall в который пошлем deposit 🤯.

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

Функция getCall заполняет массив таким образом [ deposit, multicall [ deposit ] ]

Функция multicallAttack принимает адрес инстанса прокси и она payable

В прокси мы передаем подготовленный массив из селекторов и эфиры.

На контракте прокси уже лежит 0.001 eth, поэтому мы пошлем еще 0.001, что бы после атаки на функцию multicall мы могли снять удвоенный балланс

И затем с помощью execute мы снимаем 0.002 eth

Загружаем контракт в сеть и добавляем адрес этого контракта в вайтлист

Теперь вызываем функцию multicallAttack передав адрес прокси и 0.001 eth

Можем убедиться в Tenderly, что мы передали 0.001, а получили 0.002 опустошив прокси

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

Убеждаемся что мы теперь админ

Задача решена

ДАО (англ. DAO — decentralized autonomous organization) — это децентрализованная автономная организация.

Процесс голосования, посредством которого ДАО принимает решения, называется on-chain governance, и он стал центральным компонентом децентрализованных протоколов. ДАО принимает решения, такие как настройка параметров, обновление смарт-контрактов, интеграция с другими протоколами, управление казначейством, выдача грантов и т. д.

Предложение (Propose) - это действие, которое будет исполнено от имени ДАО, если члены ДАО поддержат его.

• После создания предложения оно имеет статус Pending - ожидает начала голосования.
• После прохождения времени необходимого для ознакомления с предложением, покупки токенов голосования и т.п. начинается период голосования и предложение имеет статус Active.
• После того как завершился период голосования происходит подсчет голосов. Если набралось достаточное количество голосов и кворум был достигнут, то предложение имеет состояние Succeeded. Если кворум не достигнут и предложение отклонено - Defeated.
• Далее предложение помещается в очередь на исполнение - Queued.
• Если предлжение находится слишком долго в очереди, то состояние меняется на Expired.
• Исполненное предложение имеет стату Executed.
• Также предложение может быть отменено до исполнения - Canseled.

Разберем пример построения ДАО с использованием библиотеки OpenZeppeline v5.0. Нам нужны несколько контрактов для организации ДАО:

Контракты:

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

ERC20Vote - Токен голосования.

Governor DAO - контракт, который отвечает за создание предожений, голосование и планирование исполнения предожений.

TimeLockController - дополнительный контракт, который выполненяет предложение, одобреное контрактом Governor.

Target Contract From Propose - тестовый контракт, за взаимодействие с которым будут голосовать пользователи в нашем тестовом предложении.

Действия:

1. Proposer создает предложение (состояние предложения Pending)
2. User приобретает токены голосования (состояние предложения Pending или Active)
3. User делегирует право голосования (себе или кому то другому) (состояние предложения Pending или Active)
4. User голосует против, за, или воздержался (состояние предложения Active)
5. Executer ставит предложение в очередь на исполнение (состояние предложения Succeeded)
6. Executer запускает исполнение предложение от имени ДАО (состояние предложения Queued или Expired)

Создаем контракт, наследуемся от ERC20Votes. Decimals буду использовать равный 6ти, что бы было проще осуществлять обмен с USDT

Создаем контракт для продажи токенов за USDT

Приведу часть контракта собственно DAO. Наследуемся от следующих контрактов:

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

GovernorCountingSimple - модуль, реализующий голосование с 3мя вариантами (Против, За, Воздержался)

GovernorVotes - модуль, для расчета веса голоса в зависимости от количества токенов голосования

GovernorVotesQuorumFraction - модуль, отвечающий за кворум

GovernorTimelockControl - модуль, отвечающий за взаимодействие Governor'а и TimeLockController'а

Также приведу часть тестов написанных на Foundry:

Переменные и подготовка контрактов

Тест создающий предложение, голосующий, и исполняющий предложение

• После изменения количества токенов голосования нужно вызвать delegate()
• Для расчета времени используется block.number, а не timestamp
• Прежде чем исполнить предложение его нужно поместить в очередь на исполнение

• Critical - Уязвимости, приводящие к краже активов, блокировке доступа к средствам или к любым другим потерям средств.
• High - Уязвимости, которые приводят к сбоям контракта и которые могут быть исправлены только путем изменения или полной замены кода контракта.
• Medium - Уязвимости, нарушающие предполагаемую логику контракта, но не приводящие к потере средств и не требующие замены контракта.
• Low - Мелкие ошибки, которые можно учесть с целью улучшения общего качества кода.

Вариант оценки 2:

• High Risk - Проблема ставит под угрозу большинство или значительное количество конфиденциальной информации пользователей или вероятно приведет к катастрофическим последствиям для репутации клиента или серьезным финансовым последствиям как для клиента, так и для пользователей.
• Medium Risk - Проблема ставит под угрозу часть чувствительной информации пользователей, будет вредной для репутации клиента, если будет использована, или, скорее всего, приведет к умеренным финансовым последствиям.
• Low Risk - Риск относительно невелик и не может быть злоупотреблен на регулярной основе, или это риск, который клиент считает низким в свете своей деловой ситуации.
• Informational - Проблема не представляет собой немедленную угрозу, но соответствует лучшим практикам по безопасности или принципам "защиты в глубину" (Defense in Depth).
• Undetermined - Последствия проблемы неопределены.

Примеры уязвимостей

Critical

• Манипуляция результатами голосования в управлении, отклоняющаяся от принятого решения и приводящая к непосредственному изменению первоначальных результатов.
• Прямая кража средств любого пользователя.
• Прямая кража NFT пользователей .
• Постоянная заморозка средств.
• Постоянная заморозка NFT.
• Несанкционированная чеканка NFT.
• Предсказуемый или манипулируемый генератор случайных чисел, который можно использовать для изменения результатов в свою пользу
• Непреднамеренное изменение того, что представляет собой NFT (например, токен URI, полезная нагрузка, художественное содержание).
• Неспособность протокола соблюсти финансовые обязательства.

High

• Кража несписанных доходов
• Кража несписанных роялти
• Постоянная заморозка несписанных доходов
• Постоянная заморозка несписанных роялти
• Временная заморозка средств
• Временная заморозка NFT

Medium

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

Low

• Контракт не способен обеспечить обещанный доход, но не теряет своей стоимости.

Ссылки и источники:

https://swcregistry.io/

https://github.com/sirhashalot/SCV-List#scv-list

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

Задача:

• Выкупить всю NFT коллекцию за одну транзакцию.

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

Взглянем на код модификатора. С первого взгляда кается, что все правильно:

Если размер кода по адресу не ноль, то это контракт и запрещаем работу

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

Давайте немного разберем атаку:

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

2. Для минта NFT на атакающем адресе не должно быть больше NFT чем maxPerAddressDuringMint

Что бы обойти это ограничение мы можем перевести сминченные NFT на другой адрес, что бы текущий баланс снова стал равен нулю.

3. Следующее ограничение проверяет, что мы не можем сминтить больше NFT чем есть в коллекции

Это ограничение обходистя с помощью изменения количества запрашиваемых токенов для минта - _quentity

Ниже привиден код, для осуществления задуманной атаки на маркетплейс

Атака начнется во время развертывания контракта. В качестве параметра передаем адрес маркетплейса

Задача решена

https://github.com/secureum/AMAZEX-DSS-PARIS/tree/main/src/2_ModernWETH

Создан ERC20 контракт, который оборачивает эфир. На нем находится 1000 ETH

Задачи:

• Начиная с 10 ETH, украсть 1000 ETH из контракта ModernWETH.

Изучив код контракта, замечаем что в функции withdrawAll на 33 и 36 строке проверяется текущее количество токенов.

Уязвимость заключается в том, что при вызове call'а исполнение передается в другой контракт (если msg.sender это контракт) и баланс токенов может быть изменен там.

Воспользуемся данной уязвимостью что бы опустошить ModernWETH.

Создадим 2 контракта: 1й будет использовать данную уязвимость, 2й будет служить временным хранилищем токенов.

Теперь разберем алгоритм атаки

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

Теперь создадим атакующий контракт и вызовем функцию атаки

Задача решена

Во многих децентрализованных биржах используется другая схема - автоматический маркетмейкер (АММ). Это система при которой нет необходимости ждать пока на продажу найдется покупатель и на покупателя - продавец. АММ предоставляет ликвидность для обмена из собственных резервов беря за этот обмен небольшую комиссию.

Самый простой АММ работает по такому принципу:

• Пул состоит из 2х токенов между которыми осуществляется обмен;
• Цена на обмен формируется из условия - произведение количества токена X и токена Y в пуле является константой;

Если представить X * Y = K в виде графика, то получится кривая, которая не пересекается с осями (гипербола). Это значит, что если одного из токенов в пуле становится очень мало, то цена его становится очень большой и на оборот: чем больше токена - тем он дешевле

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

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

В новых версиях АММ эта проблема решена с помощью концентрированной ликвидности.

Например, если человек считает что цена токена А будет меняться от 100 до 200, то он дает ликвидность только в этот диапазон цен, а не на весть диапазон от ~0 до +∞.

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

Так же нужно понимать что при выходе за указанный диапазон токены конвертируются в дешевеющий (относительно другого) токен.

Реальный пример дачи ликвидности

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

текущая цена

Для этого я буду использовать дачу ликвидности на сети Avalanche на площадке Trader Joe в пул BTC.b / USDC

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

Если биткоин будет падать к нижней границе, то внесенные USDC постепенно конвертируются в BTC, как если бы я постоянно усреднялся докупая биткоин вручную, но преимущество АММ в том что пока биткоин будет падать - я буду зарабатывать на комиссиях от обменов других пользователей в моем диапазоне

Вношу в протокол 405$ в USDC и 17$ в BTC.b. Текущая позиция выглядит так

Update 1. Спустя 24 часа

текущая цена

ликвидность в пуле и проторгованный объем

моя позиция

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

на комиссиях за 24 часа заработано 0.36$. Комиссии идут и в BTC.b и в USDC что составляет ~30% годовых

Update 1. Спустя 5 дней

Цена ~ 27200$. На комиссиях заработано 1.79$

Update 3. Спустя 12 дней

Цена вышла за верхний диапазон, полностью перелилась в USDC и перестала зарабатывать. На комиссиях заработано 4.10$. Если в ближайшую неделю цена не вернется в мой диапазон - буду смещать его

Вводные:

https://github.com/secureum/AMAZEX-DSS-PARIS/tree/main/src/1_MagicETH

Протокол был взломан и украдены 1000 mETH

Задачи:

- Вернуть украденые1000 mETH с кошелька exploiter.

- Конвертировать mETH в ETH.

Изучив код протокола, замечаем что на 35 строке допущена ошибка. Перепутаны местами адреса msg.sender и account.

Это значит что происходит проверка "Сколько токенов мы разрешили сжечь/перевести с account'а", а не он нам.

Так же мы видим в 39 строке, что уже нам дается approve на снятие токенов с accout'а

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

• Сами даем approve на 1000 mETH exploiter'у
• Вызываем функцию burnFrom , что бы самим получить approve от exploiter'a

• Переводим себе токены с адреса exploiter'a
• Обмениваем mETH на нативный ETH используя функцию withdraw

Задача решена

1. опустошить контракт

Изучив контракт мы видим что стейт контракта изменяется после передачи эфира через call().

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

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

1. Сначала донатим немного эфира, для того что бы выполнить условие из первой строки функии withdraw()
2. Запрашиваем снятие эфира
3. Повторно запрашиваем снятие эфира после получения эфира на наш контракт
4. Выполняем в цикле снятие и запрос до того момента пока атакуемый контракт не опустеет

Не ваши ключи — не ваши монеты

1. Где?

1.1 На бирже

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

1.2. На горячем кошельке

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

Рекомендую Rabby Wallet вместо метамаска

1.3. На холодном кошельке

Отдельная железяка, которая не дает вирусам украсть ваши средства, а так же дает дополнительное время подумать пока вы нажимаете на физические кнопки

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

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

2. Хранение seed-фразы

2.1 На компьютере или в облаке

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

2.2 На бумаге

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

2.3 На железной пластине

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