Пример работы Frontrun ботов

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

Рекомендую к просмотру каждому.

#frontrun #security

Код - ловушка

Посмотрите внимательно на код на скрине. Если вы повстречаете его где-либо, то, скорее всего, перед вами типичная honeypot ловушка.

Помните, что address(this).balance всегда включает в себя msg.value данной транзакции.

#security

Задача на день

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

Подсказка

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

#task

Интересный нюанс с call вызовом

В Твиттере у одного из аудиторов увидел пост о том, что call вызов может привести к атаке gas griefing через байты, которые он возвращает в качестве ответа. Смотрите, что получается:

(bool success,) = payable(receiver).call{gas: 3000, value: amount}(hex"");

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

(bool success, bytes memory data)

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

При этому bytes data, которая возвращается из return, будет скопирована в память. И, если размер data будет слишком большой, то стоимость записи в память может превысить лимиты и получится gas griefing.

Аудитор предлагает использовать assembly, который автоматически не копирует возвращаемые значения в память, например:

bool success;
assembly {
success := call(3000, receiver, amount, 0, 0, 0)
}

Не могу точно сказать, что это 100% уязвимость и нужно переходить на assembly всем, так как доказательств в документации я не нашел.

Тем не менее, данный вопрос поднимался не раз на GitHub, вот один из таких примеров.

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

#assembly #call

Блог с разбором взломов

Вчера на канале у Officer CIA проскочило короткое сообщение, в котором он рекомендовал блоги:

faith2dxy.xyz и faraz.faith

Это, по сути, один и тот же блог одного автора. Просто он решил сделать обновление и перешел на другой домен.

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

#secirity #blog

Домашнее задание на каникулы

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

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

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

Сборник найденных уязвимостей 1

Сборник найденных уязвимостей 2

Сборник найденных уязвимостей 3

Аудиты Code4rena

Аудиты Immunefi

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

С 9 января мы продолжим наше обучение, вернемся к аудитам и ведению канала.

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

#homework

Делимся ссылками

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

Вы также можете в комментариях поделиться своими подписками и рекомендациями, и не только в Твиттере.

Faith

patrickd

zzykxx

Trust

okkothejawa

pashov

afeli.eth

WINTΞR

philogy

Liam | Sydney

WATCHPUG

0xrudra

Samrat Gupta

rmi7.eth

Christoph Michel

Officer's Notes

alpharush

this is now a shitpost account


Компании

Chainlink

Trail of Bits

OpenZeppelin

Uniswap Labs

Hardhat

Code4rena

Alchemy | The web3 developer platform

Developer DAO

ConsenSys

Etherscan

Immunefi

rekt

Paradigm CTF

QuillAudits

SHERLOCK

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

Можете спокойно сохранять себе и делать репосты.

#twitter

С Новым Годом!

Поздравляю всех с Новым Годом! Желаю, чтобы все ваши усилия в штурмовании web3 сполна окупились в 2023, и уже в его конце, вы, попивая пинаколаду где-нибудь на Бали, подумали: "А ведь все это было не зря!".

Еще раз С Новым Годом! Удачи, здоровья и безопасности!

🎄🎄🎄🎄🎄🎄🎄🎄

Возвращаемся к работе

Всем привет! Надеюсь вы отлично провели праздничные дни и готовы к достижению новых высот в web3.

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

Поделюсь своими планами на развитие канала.

Прежде всего, я решил для себя сфокусироваться на конкурсных аудитах на таких площадках как code4rena и sherlock.

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

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

Чего не будет на канале?

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

Фокус будет нацелен на безопасность смарт контрактов и их тестирование в foundry.

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

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

Всем прекрасного года и легкого обучения!

Для начинающих аудиторов

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

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

Дело в том, что в задачах / отчетах / статьях я имел дело с конкретными функциями или короткими контрактами, зачастую не больше двух. Да и код в них был довольно короткий: 50 - 100 строчек кода.

И вот когда я решил попробовать свои силы в конкурсе, я был слегка обескуражен: количество контрактов было около 15 и строк кода около 3500. И я такой: "Эмм, и что с этим делать"...

Полез сразу в forge init, установку зависимостей и т.д. Открыл первый контракт... Второй... Третий... И ничего не понятно.

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

Ответ прост: читайте документацию.

Перед любым аудитом вам стоит потратить пару часов на:

- Прочтение условий конкурса. Порой из 20 контрактов на аудит просят всего 5 из них. Т.е. даже если вы найдете уязвимость в 6 контракте - за него не заплатят.

- Прочтение документации проекта. Посетите их сайт или репо на GitHub, чтобы узнать более детальные подробности о контрактах и логике работы;

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

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

#audit #аудит

Double Entry Point

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

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

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

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

Так в чем же здесь может быть проблема?

А в том, что контракт функционировал через прокси.

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

Так вот, в случае с Balancer пользователь мог взаимодействовать как с прокси контрактов, так и с третьим контрактом напрямую! Это-то и создавало баг double entry point.

В примере эксплойта, который приводится в статье, хакер мог запросить займ токенов из обоих контрактов: прокси и исполнения. Причем в первом случае он брал займ на 100% возможную сумму токенов, а во втором - 0. Это создавало некий баг в конечный расчетах, что приводило к тому, что весь займ токенов переводился в контракт Сейфа, и никто потом больше не мог брать займ под этот токен.

Да, хакер не получал ничего, но и работа сервиса стопорилась.

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

#security #doubleentrypoint

Signature Malleability

Нашел интересную ветку в Твиттере с описанием данной уязвимости.

Все подписи содержат в себе значения:

R - a point on the secp256k1 elliptic curve (32 bytes)
S - a point on the secp256k1 elliptic curve (32 bytes)
V - recovery id (1 byte)

Имея на руках подпись и подписанное сообщение, любой пользователь может восстановить адрес, кому эта подпись принадлежит, используя функцию ecrecover(hash, v, r, s).

Уязвимость Signature Malleability может содержать в себе две и более разных подписей для восстановления для одного и того же подписанного сообщения. Это может быть достигнуто изменением оригинальной подписи и недостаточной валидацией.

В данном примере используется модификация подписи EIP2098 (Компактная подпись), которая помещает V (0 или 1) на верх бита S. Это приводит к тому, что подпись становится на 1 бит короче, и теперь нужно, чтобы контракт делал дополнительное действие - разворачивание подписи.

Посмотрите на пример выше на скрине. Тут передается подпись, восстанавливается адрес и сообщение сохраняется в маппинг, чтобы предотвратить replay атаку.

Тем не менее мы можем выполнить эту функцию дважды: с нормальной подписью и, модифицировав ее, с EIP2098.

Чаще всего используется библиотеки от OpenZeppeling. Эта уязвимость возможна на версиях ниже 4.7.3.

Обращайте на это внимание.

#security #ECDSA #signature

Signature Malleability 2

Ну, и еще одна уязвимость от того же автора из Твиттер.

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

Но тут чего-то не хватает?

А точнее, тут не хватает валидации S значения!

if (uint256(s) > 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 ) {
     return (address(0), RecoverError.InvalidSignatureS);
}

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

Из-за особенностей работы системы, сюда вы можете передать две разные подписи (с одинаковым подписанным сообщением) и получить один и тот же восстановленный адрес!

В этой ветке дается объяснения почему это происходит, и как это связано с EIP2 и secp256k1n/2. Спойлер: особенности шифрования.

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

#security #signature #eip2

E в Ethereum Signed Message

Знали ли вы, что буква Е в Ethereum Signed Message (подписанные сообщения), на самом деле параметр, а не просто буква?

В исходном коде сообщение выглядит так:

0x19 <0x45 (E)> <thereum Signed Message:\n" + len(message)> <data to sign>

0x45 или "E" - говорит, что используется одна из версий подписи сообщений.

Больше информации на скрине.

#signature

Новые задачи CTF

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

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

Mr Steal Yo Crypto

CTF Protocol

QuillCTF


И для практики в Foundry:

Damn Vulnerable DeFi

Ethernaut CTF

Fifty years Capture the Ether

Приятных вам голодных игр!

#ctf

Классная задача от Immunefi

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

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

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

С кодом все ок. По крайней мере, если не знать особенностей работы контрактов токенов и разных EIP.

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

Если кто не знает, то такие токены стандарта ERC777 при трансфере имеют не одну, а целых две callback функции:

_callTokensToSend() - которая вызывается до фактической отправки токенов;
_callTokensReceived() - которая вызывается после отправки токенов.

Обе они в рамках функции transfer(). Поняли теперь, в чем дело в задаче?

Используя _callTokensToSend() токена, хакер может заходить в функцию deposit() несколько раз (reentrancy), и спровоцировать увеличенное количество shares!

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

Интересно, да?

#task #security #erc777

Аудиты, тесты и больше практики

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

В обучении и практике нет "серединки".

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

А тесты? Все обучающие видео и статьи строятся вокруг "Как начать делать тесты"? Попробуйте найти хоть одно видео, где приводится тестирование мостов или крупных проектов.

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

10+ перекликающихся контрактов, 5000 строк кода, туча импортов и непонятных настроек. И это хорошо, если разработчики постарались и написали комментарии с подробным описанием функций, идеи проекта и natspec. А если нет?..

К чему я это все веду.

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

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

А я пошел дальше разбираться с foundry.

#практика

В дополнение к предыдущему посту

Сейчас проводится конкурс на аудит контрактов Astaria.

Почему я предлагаю этот проект?

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

Что можно сделать для своей практики?

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

Прежде всего постарайтесь ответить себе на следующие вопросы:

1) Понимаю ли я основную идею проекта?
2) Понимаю ли я, за что отвечает каждый контракт?
3) Понимаю ли я их взаимосвязь?
4) Понимаю ли я исходную точку для пользователя?
5) Понимаю ли я весь набор файлов в проекте?
6) Понимаю ли я подключенные библиотеки?

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

Далее попробуйте написать свои тесты для него:

1) Создать Сейф от имени пользователя;
2) Сделать перевод;
3) Добавить пользователей и от их имени проведите транзакции;
4) Отдайте NFT в займ;
5) Прочитайте переменные памяти контракта;

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

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

Дерзайте!

#практика

Задачка на день

Ну, и небольшая задачка на день. Сможете найти, в чем тут проблема?

Решение

В аудитах следует всегда обращать внимание на модификаторы функций, какие условия они нам ставят.

В текущем же примере, он просто сверяет msg.sender с другим параметров, а значит, что функция _safeMint() не защищена от reentrancy атак.

#security #task