По следам вчерашнего поста
Спасибо всем, кто оставил коммент вчера. Я специально подождал сутки, в надежде, что и другие выскажут свое мнение.
Вы правы, нужно делать то, что заводит самого. Будут и задачи, и разборы, и новости, и другие штуковины по смарт контрактам, на которые я натыкаюсь по мере своего обучения, без "удержания" какой-либо конкретной темы.
Всем спасибо! Продолжаем!
Спасибо всем, кто оставил коммент вчера. Я специально подождал сутки, в надежде, что и другие выскажут свое мнение.
Вы правы, нужно делать то, что заводит самого. Будут и задачи, и разборы, и новости, и другие штуковины по смарт контрактам, на которые я натыкаюсь по мере своего обучения, без "удержания" какой-либо конкретной темы.
Всем спасибо! Продолжаем!
Аудиторы будут больше не нужны?
Вчера в твиттере стали появляться все больше сообщений, что был запущен некий AI бот, который определяет уязвимости в смарт контрактах и дает отчет по ним. Пример такого отчета вы можете видеть на скрине, а почитать больше на официальном сайте.
Я хотел поиграться с ним, но сервис не доступен для пользователей из России (регистрация с смс), более того виртуальные номера с VoIP также отсекаются.
Как я понял, код смарт контракта на Solidity прогоняется через бот, и тот отлавливает все популярные уязвимости, сопоставляя их с теми, что уже в его базе. Понятное дело, все шутят, что скоро аудиторы будут не нужны.
Хотя я немного другого мнения.
Даже с учетом того, что уже несколько лет существуют такие крутые инструменты как Slither, Echidna, Manticore и другие, работы у аудиторов не убавилось, также как не прекратились и взломы. А текущей версии бота еще далеко до этих сервисов.
Да и после его совершенствования, где гарантии, что он будет отслеживать кросс-контрактные и кросс-блокчейн уязвимости? Или симулировать логические операции с flash займами и временными отрезками?
Так или иначе подобные сервисы будут крайне полезны для первоначального тестирования смарт контрактов, но полностью заменить человека не смогут в ближайшие 5-10 лет.
#ai #security
Вчера в твиттере стали появляться все больше сообщений, что был запущен некий AI бот, который определяет уязвимости в смарт контрактах и дает отчет по ним. Пример такого отчета вы можете видеть на скрине, а почитать больше на официальном сайте.
Я хотел поиграться с ним, но сервис не доступен для пользователей из России (регистрация с смс), более того виртуальные номера с VoIP также отсекаются.
Как я понял, код смарт контракта на Solidity прогоняется через бот, и тот отлавливает все популярные уязвимости, сопоставляя их с теми, что уже в его базе. Понятное дело, все шутят, что скоро аудиторы будут не нужны.
Хотя я немного другого мнения.
Даже с учетом того, что уже несколько лет существуют такие крутые инструменты как Slither, Echidna, Manticore и другие, работы у аудиторов не убавилось, также как не прекратились и взломы. А текущей версии бота еще далеко до этих сервисов.
Да и после его совершенствования, где гарантии, что он будет отслеживать кросс-контрактные и кросс-блокчейн уязвимости? Или симулировать логические операции с flash займами и временными отрезками?
Так или иначе подобные сервисы будут крайне полезны для первоначального тестирования смарт контрактов, но полностью заменить человека не смогут в ближайшие 5-10 лет.
#ai #security
👍1
Возможные скамы с 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
Когда искал информацию по различным уязвимостям и взломам, то нашел репо от одной аудиторской компании Quillhash, в которой сделали подборку популярных обманов в мире NFT. Делаю короткий перевод.
1. NFT Swap Scams. Помимо площадок, где вы можете купить NFT, есть маркетплейсы для их обмена. Скам, в этом случае, происходит, когда мошенник общается с жертвами на популярных каналах (телеграм, дискорд), а затем предлагает обменяться токенам на каком-либо сером сайте. Жертва переводит свой NFT на такой сайт для обмена и теряет его навсегда.
2. "Trojan Horse" NFT. Кратко говоря, это такой токен, который жертва может получить через airdrop, который содержит вредоносный коди и после может вызвать окошко / кнопку / что-то еще для совершения действия пользователем. Действие это может разрешить перевод всех его NFT на адрес мошенника.
3. Impersonation scams. Мошенники выдают себя за службу поддержки сервиса, например Opensea, мониторят форумы, где пользователи пишут о своих проблемах. Через диалог с таким пользователями они крадут все токены через фишинг или подписанные транзакции.
4. Rug Pull. Это такой скам, когда мошенники "раздувают" инфо о своем NFT, нагоняют спрос, и сваливают в закат, как только получают крупные суммы от вкладчиков, закрывая проект.
#nft #scam
👍1
Чуть больше о взломе ANKR сегодня
Кто не слышал: сегодня был взломан сервис ANKR и украдено, по разным источникам, 10-20 миллиардов токенов aBNBc. До сих пор идут обсуждения, как это произошло. Пока что вот некоторая доступная информация.
Многие пользователи, в том числе аудиторы из крупных компаний, сходятся на том, что изначально были скомпрометированы приватные ключи ANKR.
Затем хакер несколько раз обновлял прокси контракт (Twitter).
В то время как функция mint() защищена модификатором, хакер вызвал другую функцию 0x3b3a5522, которая позволяла обойти проверки и сминтить токены. (Twitter).
Эти токены предназначались для наград (rewards) пользователей за действия на сервисе, таким образом все оригинальные токены BNB не были задеты, и взлом никак не повлиял на его цену.
Далее он обменял украденные токены на биржах PancakeSwap и ApeSwap на BNB, чем практически опустошил оба пула и задампил цену.
Чуть позже он перевел все на Tornado cash и через мост на Ethereum и обменял часть BNB на USDC.
Вот к чему может привести кража приватных ключей.
Остается один вопрос: каким образом это произошло? Некоторые склоняются, что слив ключей произошел в момент обновления сервиса и его кода за несколько часов до взлома (Twitter).
Код контракта можно посмотреть тут.
Далее снова про скамы NFT.
#ankr #break
Кто не слышал: сегодня был взломан сервис ANKR и украдено, по разным источникам, 10-20 миллиардов токенов aBNBc. До сих пор идут обсуждения, как это произошло. Пока что вот некоторая доступная информация.
Многие пользователи, в том числе аудиторы из крупных компаний, сходятся на том, что изначально были скомпрометированы приватные ключи ANKR.
Затем хакер несколько раз обновлял прокси контракт (Twitter).
В то время как функция mint() защищена модификатором, хакер вызвал другую функцию 0x3b3a5522, которая позволяла обойти проверки и сминтить токены. (Twitter).
Эти токены предназначались для наград (rewards) пользователей за действия на сервисе, таким образом все оригинальные токены BNB не были задеты, и взлом никак не повлиял на его цену.
Далее он обменял украденные токены на биржах PancakeSwap и ApeSwap на BNB, чем практически опустошил оба пула и задампил цену.
Чуть позже он перевел все на Tornado cash и через мост на Ethereum и обменял часть BNB на USDC.
Вот к чему может привести кража приватных ключей.
Остается один вопрос: каким образом это произошло? Некоторые склоняются, что слив ключей произошел в момент обновления сервиса и его кода за несколько часов до взлома (Twitter).
Код контракта можно посмотреть тут.
Далее снова про скамы NFT.
#ankr #break
👍1
Возможные скамы с 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
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
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
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
В одном из постов был приведен пример возможных проблем с контрактом, если он был создан с помощью опкода create2. Напомню, что такие контракты могут быть заменены на другие под тем же адресом, но с другим функционалом, что дает возможности мошенникам обманывать пользователей.
Я ни разу не работал с подобными случаями, поэтому заинтересовался, как такое вообще возможно, чтобы один контракт подменят другой?
Немного погуглив, я нашел прекрасные статьи, где приводится пример кода контрактов, которые показывают данную проблему.
Первая статья с простым примером контрактов, и вторая - более подробная про опкод.
Я протестировал их в ремиксе и в goerly, и к моему удивлению, так делать действительно можно.
Попробуйте поочередно задеплоить контракты, как описано в статье (достаточно скопировать код в ремикс), затем уничтожить их через selfdestruct(), изменить функцию в Target, и снова задеплоить. Под тем же адресом будет другой контракт с обновленными функциями.
#create2 #security
👍4
Не принятый create3
А еще один из участников в сообществе ранее делился ссылкой на репо GitHub, где представлен способ создания контрактов с create3.
Как я понял, create3 был предложен в EIP-3171 и был призван обновить create2, убрав из него initCode адреса, на основе которого должен был создаваться новый контракт.
Однако предложение не прошло, и create3 был оставлен в качестве библиотеки. Вот ссылка на нее.
Кратко говоря, основные фичи create3 это:
- Создание контракта на основе msg.sender + salt;
- Один адрес для разных EVM сетей;
- Поддержка конструкторов;
- Возможность payable contract creation;
Однако использование этой библиотеки увеличивает затраты на газ, по сравнению с create2, примерно на 55к.
Примеров в контрактах в mainnet я не встречал, так же как и задач с ним. Тем не менее, на канале его упомянуть стоило.
#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
Позавчера в Твиттере выложили задачу, которая заставила меня немного врасплох.
Посмотрите на скрин выше внимательно. Решение тут будет открыто изначально, так как пост скорее обучающий, а не для тренировки навыков.
На строчке owner.call{} я сразу понял, что может случиться gas griefing атака (если не в курсе, что это, то поищите посты по тегу), и побежал в комменты писать свой ответ.
И все бы ничего, если бы не два твита, которые поставили меня в некое замешательство. Вот первый и второй.
Они оба указывали на некую особенность исполнения контракта ERC721Enumerable от OpenZeppelin, о которой я слышал впервые. И мне захотелось поглубже копнуть, чтобы понять, о чем идет речь.
Для начала посмотрите вот это видео, объясняющее работу этого контракта.
Обратите особое внимание на то, как преобразуется массив во время transfer токена от одного пользователя другому.
Если потребуется, то напишу еще один пост про это, но, вроде как, на видео все предельно просто и понятно.
И вот, из-за особенностей формирования массива при изменении владельцев токена, в данной задаче один пользователь может дважды получить награду, а другой, тот чей индекс будет подвинут, вообще ничего не получит.
Надеюсь, вы сможете разобраться в этом.
Люблю задачи, в которых знание нюансов кода и логики может сыграть значительную роль!
#security #erc721 #enumerable #task #erc721enumerable
👍6
Тонкости с прокси переменными
Зацените еще одну классную задачу от Immunefi.
P.S. Эти ребята проводят свои bug bounty программы и аудиты контрактов, и умеют подмечать некоторые нюансы и уязвимости, которые сложно придумать просто так для задач или ctf. Обожаю их!
С первого взгляда все ок. Импортированные контракты от надежной компании, мало кода, и все выглядит хорошо. Опять же, если не знать "внутреннюю кухню".
Вы можете сами остановиться на этом моменте и взглянуть на скрин внимательно.
В общем, ошибка тут кроется в конфликте переменных в памяти. Да, ранее в постах я уже писал об этом баге, но в такой реализации встречаю впервые.
Какая же тут ошибка? Тут только одна переменная _IMPLEMENTATION_SLOT, в чем же тут конфликт?
А проблема в том, что контракт Implementation наследует от Ownable, а уже там, в первом слоте памяти, хранится другая переменная _owner.
Таким образом переменная в прокси будет перезаписываться при инициализации контракта Implementation.
Но тут есть еще один момент. Если мы обозначим _IMPLEMENTATION_SLOT как constant или immutable, то конфликта в памяти не возникнет.
Все потому, что constant и immutable не занимают слоты в памяти контракта. Если я правильно понял, то они зашиваются прямо в байткод контракта (constant - сразу, immutable - в момент работы конструктора).
Теперь мы начнем обращать внимание и на такие детали в контрактах. А казалось, про переменные я знаю все.
#proxy #security
Зацените еще одну классную задачу от Immunefi.
P.S. Эти ребята проводят свои bug bounty программы и аудиты контрактов, и умеют подмечать некоторые нюансы и уязвимости, которые сложно придумать просто так для задач или ctf. Обожаю их!
С первого взгляда все ок. Импортированные контракты от надежной компании, мало кода, и все выглядит хорошо. Опять же, если не знать "внутреннюю кухню".
Вы можете сами остановиться на этом моменте и взглянуть на скрин внимательно.
В общем, ошибка тут кроется в конфликте переменных в памяти. Да, ранее в постах я уже писал об этом баге, но в такой реализации встречаю впервые.
Какая же тут ошибка? Тут только одна переменная _IMPLEMENTATION_SLOT, в чем же тут конфликт?
А проблема в том, что контракт Implementation наследует от Ownable, а уже там, в первом слоте памяти, хранится другая переменная _owner.
Таким образом переменная в прокси будет перезаписываться при инициализации контракта Implementation.
Но тут есть еще один момент. Если мы обозначим _IMPLEMENTATION_SLOT как constant или immutable, то конфликта в памяти не возникнет.
Все потому, что constant и immutable не занимают слоты в памяти контракта. Если я правильно понял, то они зашиваются прямо в байткод контракта (constant - сразу, immutable - в момент работы конструктора).
Теперь мы начнем обращать внимание и на такие детали в контрактах. А казалось, про переменные я знаю все.
#proxy #security
Книга аудитора смарт контрактов
В последнюю неделю в чатах, группах и твиттере гуляла ссылка на файл, где собраны аудиты с разных проектов для bug bounties. Вот версия в pdf.
Очень большая! Более 3900 страниц.
Ну, и ссылка на проект для интересующихся.
#pdf #audit #book
В последнюю неделю в чатах, группах и твиттере гуляла ссылка на файл, где собраны аудиты с разных проектов для bug bounties. Вот версия в pdf.
Очень большая! Более 3900 страниц.
Ну, и ссылка на проект для интересующихся.
#pdf #audit #book
👍1
Возможные скамы с токенами ERC20
Понравилась небольшая статья от Quill Audits, где они приводят примеры скамов с токенами (криптовалютой). К слову, они же делали подборку скамов с NFT.
Краткий перевод.
1. Установка максимальной комиссии на продажу токенов. Некоторые мошенники прописывают в контрактах отдельную функцию, которой могут управлять только админы, на установку комиссии на продажу, которая может доходить до 100%. Так, если вы захотите продать токен за 100 $, то и комиссии придется заплатить столько же.
2. Черный список пользователей. После того, как инвесторы или другие покупатели приобретают токены, админ вносит их в черный список, запрещая тем самым какие-либо действия с токеном.
3. Сжигание токенов. Владелец может изменить код в функции burn, что позволит ему сжигать токены пользователя при внешнем вызове. Например, после покупки такого токена, админ сразу сжигает их, чтобы взвинтить цену токена и опустошить пул.
4. Бесконечный минт токенов. Админ минтит токены, чем снижает цену и банкротит пользователей.
5. Токены нельзя продать после покупки. Например, пользователи покупают токены для какой-либо игры, надеясь сделать небольшой профит после. Однако оказывается, что они не могут продать его. Цена токена взлетает, и админ опустошает пул.
6. Вредный код в наследуемом/подключенном контракте. Админы могут прятать вредоносный исполняемый код в стороннем контракте, который подключается к токену, вводя в заблуждение пользователей одноименными функциями.
Пара советов. Перед покупкой каких-либо токенов стоит заранее посмотреть его контракт и наследования на предмет возможного скама. Это могут подсказать функции, которые доступны только админам (увеличение комиссии, добавление в черный список, запрет на продажу и т.д.). Так или иначе, для начала можно купить крохотную сумму токена и попробовать его продать. Да и вообще, следует внимательнее изучать всю подноготную токенов перед инвестициями.
#security #erc20
Понравилась небольшая статья от Quill Audits, где они приводят примеры скамов с токенами (криптовалютой). К слову, они же делали подборку скамов с NFT.
Краткий перевод.
1. Установка максимальной комиссии на продажу токенов. Некоторые мошенники прописывают в контрактах отдельную функцию, которой могут управлять только админы, на установку комиссии на продажу, которая может доходить до 100%. Так, если вы захотите продать токен за 100 $, то и комиссии придется заплатить столько же.
2. Черный список пользователей. После того, как инвесторы или другие покупатели приобретают токены, админ вносит их в черный список, запрещая тем самым какие-либо действия с токеном.
3. Сжигание токенов. Владелец может изменить код в функции burn, что позволит ему сжигать токены пользователя при внешнем вызове. Например, после покупки такого токена, админ сразу сжигает их, чтобы взвинтить цену токена и опустошить пул.
4. Бесконечный минт токенов. Админ минтит токены, чем снижает цену и банкротит пользователей.
5. Токены нельзя продать после покупки. Например, пользователи покупают токены для какой-либо игры, надеясь сделать небольшой профит после. Однако оказывается, что они не могут продать его. Цена токена взлетает, и админ опустошает пул.
6. Вредный код в наследуемом/подключенном контракте. Админы могут прятать вредоносный исполняемый код в стороннем контракте, который подключается к токену, вводя в заблуждение пользователей одноименными функциями.
Пара советов. Перед покупкой каких-либо токенов стоит заранее посмотреть его контракт и наследования на предмет возможного скама. Это могут подсказать функции, которые доступны только админам (увеличение комиссии, добавление в черный список, запрет на продажу и т.д.). Так или иначе, для начала можно купить крохотную сумму токена и попробовать его продать. Да и вообще, следует внимательнее изучать всю подноготную токенов перед инвестициями.
#security #erc20
👍1
Обход проверки на code size
В некоторых контрактах мы видели, что есть проверка на размер кода в require или условии. Напомню, что предполагается, если code size > 0, то это контракт, если меньше - пользователь.
Даже в одной из задач ранее порой требовалось обойти подобную проверку через конструктор.
Так вот, нашел интересный пример кода "призрачного" контракта, через который можно отправлять запросы в другие контракты, при этом проходя проверку на code size.
Вот этот контракт:
contract Ghost {
function sendGhostTransaction(bytes calldata payload) public returns (bool) {
assembly {
calldatacopy(0x80, payload.offset, payload.length)
let deployedAddress := create(0, 0x80, payload.length)
if iszero(deployedAddress){
mstore(0x00, false)
return(0x00, 0x20)
}
mstore(0x00, true)
return(0x00, 0x20)
}
}
}
В calldata подставляете вызов нужной функции в другом контракте.
#ghost #codesize #security
В некоторых контрактах мы видели, что есть проверка на размер кода в require или условии. Напомню, что предполагается, если code size > 0, то это контракт, если меньше - пользователь.
Даже в одной из задач ранее порой требовалось обойти подобную проверку через конструктор.
Так вот, нашел интересный пример кода "призрачного" контракта, через который можно отправлять запросы в другие контракты, при этом проходя проверку на code size.
Вот этот контракт:
contract Ghost {
function sendGhostTransaction(bytes calldata payload) public returns (bool) {
assembly {
calldatacopy(0x80, payload.offset, payload.length)
let deployedAddress := create(0, 0x80, payload.length)
if iszero(deployedAddress){
mstore(0x00, false)
return(0x00, 0x20)
}
mstore(0x00, true)
return(0x00, 0x20)
}
}
}
В calldata подставляете вызов нужной функции в другом контракте.
#ghost #codesize #security
👍1
Что вернет low-level?
Еще одна задача на знание нюансов работы EVM и кода Solidity.
Функция, в целом, написана правильно и будет отрабатываться правильно. Даже слишком правильно.
Дело в том, что она вернет true даже в том случае, если такого контракта нет, или он был уничтожен с selfdestruct.
Поэтому, тут нужно делать дополнительную проверку на существование контракта токена.
Эта задача была также выставлена на Immunefi, а те, в свою очередь, взяли ее из отчета Trail of Bits (15 страница). Но ни там, ни там не упоминается, как сделать эту проверку.
Я поспрашивал в чатах, в которых состою, однако не уверен на 100% в предложенных вариантах проверки существования контракта.
1. Проверка code size контракта;
2. Использование сторонних библиотек, типа openzeppelin и isContract();
3. Создание whitelist адресов в собственном контракте;
Если вы знаете какие-либо другие проверки, буду рад узнать о них!
#lowlevel #security
Еще одна задача на знание нюансов работы EVM и кода Solidity.
Функция, в целом, написана правильно и будет отрабатываться правильно. Даже слишком правильно.
Дело в том, что она вернет true даже в том случае, если такого контракта нет, или он был уничтожен с selfdestruct.
Поэтому, тут нужно делать дополнительную проверку на существование контракта токена.
Эта задача была также выставлена на Immunefi, а те, в свою очередь, взяли ее из отчета Trail of Bits (15 страница). Но ни там, ни там не упоминается, как сделать эту проверку.
Я поспрашивал в чатах, в которых состою, однако не уверен на 100% в предложенных вариантах проверки существования контракта.
1. Проверка code size контракта;
2. Использование сторонних библиотек, типа openzeppelin и isContract();
3. Создание whitelist адресов в собственном контракте;
Если вы знаете какие-либо другие проверки, буду рад узнать о них!
#lowlevel #security
Сайт визитка, LinkedIn и польза для общества
В процессе общения на форумах, на собеседованиях, да и просто видел в нескольких видео от блогеров в web3 сфере рекомендации, которые могут помочь устроиться на работу. Все они сводились к нескольким пунктам:
1) Хорошее резюме;
2) Реализованные проекты;
3) Профиль на LinkedIn;
4) Личный сайт - визитка;
5) Общественная деятельность;
Эти пункты не столько повысят ваши шансы быть нанятыми на хорошую работу (ведь все равно будут присылать тестовые задания и изучать ваш опыт), сколько позволят помочь обратить на вас внимание.
Поэтому я хочу сегодня сделать небольшой сайт-визитку и обновить профиль на LinkedIn. Это займет некоторое время и посты на канале может выйдут под вечер, а может уже и завтра.
У меня пока по собеседованиям немного глухо. Были несколько отказов, несколько собеседований и несколько тестовых заданий. Напомню, что я подаюсь в крупные аудиторские компании. И работу начал искать две недели назад.
И с данными рекомендациями я хочу повысить свои шансы на то, чтобы быть замеченным в индустрии.
Поможет это или нет скоро увидим. Держу вас в курсе.
В процессе общения на форумах, на собеседованиях, да и просто видел в нескольких видео от блогеров в web3 сфере рекомендации, которые могут помочь устроиться на работу. Все они сводились к нескольким пунктам:
1) Хорошее резюме;
2) Реализованные проекты;
3) Профиль на LinkedIn;
4) Личный сайт - визитка;
5) Общественная деятельность;
Эти пункты не столько повысят ваши шансы быть нанятыми на хорошую работу (ведь все равно будут присылать тестовые задания и изучать ваш опыт), сколько позволят помочь обратить на вас внимание.
Поэтому я хочу сегодня сделать небольшой сайт-визитку и обновить профиль на LinkedIn. Это займет некоторое время и посты на канале может выйдут под вечер, а может уже и завтра.
У меня пока по собеседованиям немного глухо. Были несколько отказов, несколько собеседований и несколько тестовых заданий. Напомню, что я подаюсь в крупные аудиторские компании. И работу начал искать две недели назад.
И с данными рекомендациями я хочу повысить свои шансы на то, чтобы быть замеченным в индустрии.
Поможет это или нет скоро увидим. Держу вас в курсе.
👍5
Поиск уязвимостей. Обучение. Первые итоги. Часть 1
В последнее время мне на глаза попадаются все более и более сложные задачи на поиск уязвимостей в контрактах: в одних нужно знать нюансы исполнения кода, в других иметь практику в конкретной области (типа defi), в третьих приводятся примеры реально найденных багов от топовых аудиторских компаний. В общем, перед тем как "топить" за новый круг своего обучения, хотелось бы подвести некоторые итоги текущего обучения.
Прежде всего скажу, что чем больше я вникаю в аудит и безопасность смарт контрактов, тем меньше мне самому хочется их писать. В самом деле, практически в каждом контракте можно найти пару ошибок. А если вы пишете большой проект, то его обязательно нужно отдавать на проверку, иначе взлом произойдет в самое неподходящее время.
За время своего обучение я прошел и разобрал задачи:
1) Damn Vulnerable Defi
2) Capture The Ether
3) Ethernaut
4) Spot the bug от Immunefi
5) 50+ примеров уязвимостей в defi (и еще прохожу)
Прочитал аудиторских отчетов:
1) 15+ от Code4Arena;
2) 6 от Quill Audits;
3) 10+ от Immunefi;
А также пересмотрел кучу информации по скамам и последним взломам.
И знаете, как я сам ощущаю свой опыт в деле аудита и поиска уязвимостей?
Я едва достиг среднего уровня. Другими словами, я спокойно увижу явные уязвимости в контракте и с некоторым усердием пойму более сложные баги, но проблему вызовут контракты с логическими связками переводов токенов, сложного расчета их бонусов / комиссии, неявные reentrancy и исключения из правил. И это уже уровень уверенного сеньора.
В паре последующих постов я расскажу, как я просматриваю контракты на уязвимости, и, возможно, вы найдете для себя пару идей для своих аудитов.
Более того, поделюсь, как буду обучаться дальше.
#security #audit
В последнее время мне на глаза попадаются все более и более сложные задачи на поиск уязвимостей в контрактах: в одних нужно знать нюансы исполнения кода, в других иметь практику в конкретной области (типа defi), в третьих приводятся примеры реально найденных багов от топовых аудиторских компаний. В общем, перед тем как "топить" за новый круг своего обучения, хотелось бы подвести некоторые итоги текущего обучения.
Прежде всего скажу, что чем больше я вникаю в аудит и безопасность смарт контрактов, тем меньше мне самому хочется их писать. В самом деле, практически в каждом контракте можно найти пару ошибок. А если вы пишете большой проект, то его обязательно нужно отдавать на проверку, иначе взлом произойдет в самое неподходящее время.
За время своего обучение я прошел и разобрал задачи:
1) Damn Vulnerable Defi
2) Capture The Ether
3) Ethernaut
4) Spot the bug от Immunefi
5) 50+ примеров уязвимостей в defi (и еще прохожу)
Прочитал аудиторских отчетов:
1) 15+ от Code4Arena;
2) 6 от Quill Audits;
3) 10+ от Immunefi;
А также пересмотрел кучу информации по скамам и последним взломам.
И знаете, как я сам ощущаю свой опыт в деле аудита и поиска уязвимостей?
Я едва достиг среднего уровня. Другими словами, я спокойно увижу явные уязвимости в контракте и с некоторым усердием пойму более сложные баги, но проблему вызовут контракты с логическими связками переводов токенов, сложного расчета их бонусов / комиссии, неявные reentrancy и исключения из правил. И это уже уровень уверенного сеньора.
В паре последующих постов я расскажу, как я просматриваю контракты на уязвимости, и, возможно, вы найдете для себя пару идей для своих аудитов.
Более того, поделюсь, как буду обучаться дальше.
#security #audit
👍2