Zero trust и постоянные проверки

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

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

Остановитесь и взгляните на код на скрине. Функция позволяет пользователя отменить их транзакции в очереди. Сможете найти там баг? Давайте пройдемся по коду.

Пользователь вызывает данную функцию, которая проходит по массиву транзакций, которые должны быть отменены, одновременно проверяя, что transfer.from и msg.sender сходятся. Затем ставит статус транзакции, как "отменена", переводит токены пользователю и порождает событие. И все бы ничего, если бы не одно "но".

Решение

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

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

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

#security

Изучаем Foundry

На канале у Ильи вышел новый урок про Foundry. Это что-то вроде Hardhat, но для написания тестов используется Solidity.

Вот этот видео урок.

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

В рамках одного из них предлагали скачать архив с файлами для проверки контрактов на уязвимости, и что вы думаете? Проект там был создан для foundry. И мне пришлось в скором темпе перекидывать и адаптировать его под hh, чтобы начать работу.

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

#foundry #forge

Возможные проблемы с Foundry

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

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

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

Вообще, как оказалось, Windows достаточно дырявая система для работы со смарт контрактами, тестами и взломами. Но не об этом сейчас.

Во-вторых, скачивание пакетов (типа npm). Тут это работает немного по другому. Тут вы скачиваете git репозиторий. Причем не по ссылке, а именно в команде указываете название репозитория на GitHub, например

forge install foundry-rs/forge-std

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

В моем есть remappings.txt, где прописаны следующие строки:

@openzeppelin/=lib/openzeppelin-contracts/contracts/
@openzeppelin-upgradeable/=lib/openzeppelin-contracts-upgradeable/contracts/
@chainlink/=lib/chainlink/

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

А с командой, как показано в документации:

forge install foundry-rs/forge-std (это пример команды)

у меня постоянно возникали две ошибки: первая:

fatal: not a git repository (or any of the parent directories): .git

которая исправилась у меня через git init, и вторая:

This command requires clean working and staging areas, including no untracked files. Modify .gitignore and/or add/commit first, or add
the --no-commit option.

которая решается удалением из папки lib пустой одноименной директории и последующей командой:

forge install foundry-rs/forge-std --no-commit

После этого в lib создастся папка с нужными контрактами и настройками.

Я еще разбираюсь с остальными файлами, и если будут возникать ошибки, отпишусь здесь.

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

#foundry #forge

Задача от Immunefy

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

Что же не так с этим кодом?

Решение

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

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

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

#security #task

Кратко о Beacon Proxy

Пару раз в контрактах на аудит встречал интеграции openzeppelin с Beacon Proxy. Я знал и работал с transparent и uups, но про beacon ничего не знал. Давайте поговорим о нем немного.

Beacon Proxy - это такой прокси паттерн,в котором несколько прокси контрактов ссылаются на один контракт Исполнения. Например, у вас есть несколько прокси контрактов, и все они работают с одним контрактом, в котором выполняются все действия. Если бы мы использовали uups или transparent, но нам вручную бы пришлось обновлять контракт Исполнения в каждом прокси, что не очень удобно и может занять некоторое время.

С Beacon Proxy мы можем обновить ссылку на адрес контракта Исполнения только в нем, и все остальные прокси контракты "подцепят" это.

Другими словами Beacon Proxy это некая прослойка между прокси контрактами и контрактом Исполнения.

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

#proxy #beacon

Нужен совет сообщества

Хочу посоветоваться с вами по поводу материалов на канале.

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

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

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

Поэтому думаю как поступить лучше.

Делать посты реже, но добавлять только новую информацию на канал? Типа как, "Как сделать это?", "Как подключить кошелек?", "Как использовать uniswap?" и т.д.

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

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

Что вы думаете?

По следам вчерашнего поста

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

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

Всем спасибо! Продолжаем!

Аудиторы будут больше не нужны?

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

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

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

Хотя я немного другого мнения.

Даже с учетом того, что уже несколько лет существуют такие крутые инструменты как Slither, Echidna, Manticore и другие, работы у аудиторов не убавилось, также как не прекратились и взломы. А текущей версии бота еще далеко до этих сервисов.

Да и после его совершенствования, где гарантии, что он будет отслеживать кросс-контрактные и кросс-блокчейн уязвимости? Или симулировать логические операции с flash займами и временными отрезками?

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

#ai #security

Возможные скамы с NFT. Часть 1

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

1. NFT Swap Scams. Помимо площадок, где вы можете купить NFT, есть маркетплейсы для их обмена. Скам, в этом случае, происходит, когда мошенник общается с жертвами на популярных каналах (телеграм, дискорд), а затем предлагает обменяться токенам на каком-либо сером сайте. Жертва переводит свой NFT на такой сайт для обмена и теряет его навсегда.

2. "Trojan Horse" NFT. Кратко говоря, это такой токен, который жертва может получить через airdrop, который содержит вредоносный коди и после может вызвать окошко / кнопку / что-то еще для совершения действия пользователем. Действие это может разрешить перевод всех его NFT на адрес мошенника.

3. Impersonation scams. Мошенники выдают себя за службу поддержки сервиса, например Opensea, мониторят форумы, где пользователи пишут о своих проблемах. Через диалог с таким пользователями они крадут все токены через фишинг или подписанные транзакции.

4. Rug Pull. Это такой скам, когда мошенники "раздувают" инфо о своем NFT, нагоняют спрос, и сваливают в закат, как только получают крупные суммы от вкладчиков, закрывая проект.

#nft #scam

Чуть больше о взломе ANKR сегодня

Кто не слышал: сегодня был взломан сервис ANKR и украдено, по разным источникам, 10-20 миллиардов токенов aBNBc. До сих пор идут обсуждения, как это произошло. Пока что вот некоторая доступная информация.

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

Затем хакер несколько раз обновлял прокси контракт (Twitter).

В то время как функция mint() защищена модификатором, хакер вызвал другую функцию 0x3b3a5522, которая позволяла обойти проверки и сминтить токены. (Twitter).

Эти токены предназначались для наград (rewards) пользователей за действия на сервисе, таким образом все оригинальные токены BNB не были задеты, и взлом никак не повлиял на его цену.

Далее он обменял украденные токены на биржах PancakeSwap и ApeSwap на BNB, чем практически опустошил оба пула и задампил цену.

Чуть позже он перевел все на Tornado cash и через мост на Ethereum и обменял часть BNB на USDC.
 
Вот к чему может привести кража приватных ключей.

Остается один вопрос: каким образом это произошло? Некоторые склоняются, что слив ключей произошел в момент обновления сервиса и его кода за несколько часов до взлома (Twitter).

Код контракта можно посмотреть тут.

Далее снова про скамы NFT.

#ankr #break

Возможные скамы с NFT. Часть 2

5. NFT Duplicity. Каждый может сминтить дубликат популярных NFT и затем выдавать их за оригинал, вводя доверчивых покупателей в заблуждение. Так и хочется добавить: "Без лоха и жизнь плоха...".

6. Recovery Scams. Были случаи, когда после кражи токена, эта новость проскальзывала в соцсетях и мошенники или их боты писали жертве с предложением восстановить владение токеном. Однако за это придется заплатить. Понятное дело, что ни NFT, ни денег жертва потом не увидит.

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

8. Flash Loans. Мошенники используют займы для манипулирования ценой токенов и быстрой их перепродажи.

9. Spoofing. В точности копирование популярных сайтов (дизайн / логика) для обмана пользователей. При регистрации крадутся данные (секретная фраза, NFT, токены).

10. Ramping the Market. Как я понял, это что-то вроде использования инсайдерской информации для незаконного обогащения за счет распиаренных NFT.

11. "Fake" News. Если кратко, то: "распиарить и кинуть". Мошенники используют соцсети и статьи в популярных сми, чтобы раскрутить токен и смыться с деньгами пользователей. Очень похож на Rug Pull. Не понимаю, почему компания выделила его в отдельный вид.

#nft #scam

Возможные скамы с NFT. Часть 3

12. Bots. Боты используются для манипулирования ценой ставки на аукционах. Они могут совершать ставки в последние секунды, таким образом выигрывая. Другой способ использования бота, это добавление токена в корзину без его покупки. Таким образом токен временно становится недоступен для покупки другим пользователям.

13. Bugs in Platform. Ошибки во внутренних сервисах маркета может быть использованы мошенниками.

14. Influencers / Shilling. Иногда для привлечения внимания к NFT и накрутке его цены могут использоваться знаменитости. Однако после продажи токена, зведы выходят из проекта, тем самым обесценивая токен в разы.

15. Unlimited Permissions on Token Approval. Когда мы работаем с маркетами, они просят разрешение (approve) на перевод токенов с вашего адреса на любой другой. Иногда такое разрешение дается не на один конкретный токен, а вообще на все. Будьте аккуратны с этим.

P.S. Не уверен, что этот баг актуален в наши дни. Вроде как,  сейчас разрешения даются на конкретный токен и его количество.

16. Rewards not Updated. Пользователи могут неограниченно минтить токены в качестве награды за какое-либо действие. Это скорее ошибка в логике контракта, которая приводит к обесцениванию NFT.

17. Code Exploits. Ошибки в смарт контрактах маркета или других контрактах, с которыми он взаимодействует. 

#nft #scam

Возможные скамы с NFT. Часть 4

18. Private Key Compromise. Тут все просто, кража приватного ключа от адреса, где лежат все токены.

19. Unsafe ERC721 Operations. Стандартная библиотека Openzeppelin ERC721 считается стандартом, однако даже сама компания рекомендует использовать ее аналог ERC721Safe с безопасными функциями, которые делают дополнительные проверки.

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

21. API Exploits. Не так страшны как другие уязвимости, но могут привести к задержкам при передачи и обновлении информации по токенам.

22. NFT Social Media Hacks. Кратко говоря, фишинг через соцсети.

23. Phishing Scams. Фишинг на сайтах, в ботах и скрытых транзакциях.

24. Frontend Attacks. Хакеры взламывают официальных маркеты и перенаправляют пользователей на свои проекты для кражи данных.

#nft #scam

Проблемный create2

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

Я ни разу не работал с подобными случаями, поэтому заинтересовался, как такое вообще возможно, чтобы один контракт подменят другой?

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

Первая статья с простым примером контрактов, и вторая - более подробная про опкод.

Я протестировал их в ремиксе и в goerly, и к моему удивлению, так делать действительно можно.

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

#create2 #security

Не принятый create3

А еще один из участников в сообществе ранее делился ссылкой на репо GitHub, где представлен способ создания контрактов с create3.

Как я понял, create3 был предложен в EIP-3171 и был призван обновить create2, убрав из него initCode адреса, на основе которого должен был создаваться новый контракт.

Однако предложение не прошло, и create3 был оставлен в качестве библиотеки. Вот ссылка на нее.

Кратко говоря, основные фичи create3 это:

- Создание контракта на основе msg.sender + salt;
- Один адрес для разных EVM сетей;
- Поддержка конструкторов;
- Возможность payable contract creation;

Однако использование этой библиотеки увеличивает затраты на газ, по сравнению с create2, примерно на 55к.

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

#create3

Офигенная задача от Immunefi

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

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

На строчке owner.call{} я сразу понял, что может случиться gas griefing атака (если не в курсе, что это, то поищите посты по тегу), и побежал в комменты писать свой ответ.

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

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

Для начала посмотрите вот это видео, объясняющее работу этого контракта.

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

Если потребуется, то напишу еще один пост про это, но, вроде как, на видео все предельно просто и понятно.

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

Надеюсь, вы сможете разобраться в этом.

Люблю задачи, в которых знание нюансов кода и логики может сыграть значительную роль!

#security #erc721 #enumerable #task #erc721enumerable