Тесты с Foundry. Часть 5
Еще одна классная штука, которая есть в Foundry и нет в hardhat или remix, это проведение fuzz тестов.
Fuzz тесты - это такие операции с функциями, когда в ее параметры подставляют разные случайные значения и пытаются сломать выполнение.
Ранее для подобных тестов использовались сторонние сервисы, типа Echidna от Trail of Bits. Это, конечно, очень крутая программа, но если вам нужно сделать простые тесты, то Foundry подойдет, как нельзя кстати.
Возьмем к примеру такую функцию:
function testWithdraw() public {
payable(address(safe)).transfer(1 ether);
uint256 preBalance = address(this).balance;
safe.withdraw();
uint256 postBalance = address(this).balance;
assertEq(preBalance + 1 ether, postBalance);
}
Если мы переводим 1-2 Эфира, то все ок. А если кто-то захочет сломать функцию и перевести другие суммы?
И вот как она будет выглядеть в fuzz тестах:
function testWithdraw(uint256 amount) public {
payable(address(safe)).transfer(amount);
uint256 preBalance = address(this).balance;
safe.withdraw();
uint256 postBalance = address(this).balance;
assertEq(preBalance + amount, postBalance);
}
Т.е. мы разрешаем Foundry вставлять в параметры функции свои значения под uint amount и проверять исполнение.
Если прогнать этот тест, то мы увидим, что он провалится, так как на одном из шагов будет предложено значение 2**96 wei, что вызовет overflow.
В документации сказано, что так можно проверять и другие типы данных: строки и булево значения. Но чаще всего используют именно для чисел.
Также в тестах можно определять границы подставляемых значений с помощью команды vm.assume(), например, для нашего случая:
vm.assume(amount > 0.1 ether);
Сами тесты прогоняются 256 раз по умолчанию. Другими словами, программа попробует подставить 256 различных значений и проверить их.
Мы можем изменить этот параметр в файле конфигурации, добавив строку:
fuzz_runs = 10000 (количество тестов)
Подобные тесты очень помогают для проверки расчетов и транзакций в наших функциях, так как мы никогда не сможем предугадать, кто и как будет использовать наш контракт.
В общем, Foundry сильно облегчает нам работу!
#foundry
Еще одна классная штука, которая есть в Foundry и нет в hardhat или remix, это проведение fuzz тестов.
Fuzz тесты - это такие операции с функциями, когда в ее параметры подставляют разные случайные значения и пытаются сломать выполнение.
Ранее для подобных тестов использовались сторонние сервисы, типа Echidna от Trail of Bits. Это, конечно, очень крутая программа, но если вам нужно сделать простые тесты, то Foundry подойдет, как нельзя кстати.
Возьмем к примеру такую функцию:
function testWithdraw() public {
payable(address(safe)).transfer(1 ether);
uint256 preBalance = address(this).balance;
safe.withdraw();
uint256 postBalance = address(this).balance;
assertEq(preBalance + 1 ether, postBalance);
}
Если мы переводим 1-2 Эфира, то все ок. А если кто-то захочет сломать функцию и перевести другие суммы?
И вот как она будет выглядеть в fuzz тестах:
function testWithdraw(uint256 amount) public {
payable(address(safe)).transfer(amount);
uint256 preBalance = address(this).balance;
safe.withdraw();
uint256 postBalance = address(this).balance;
assertEq(preBalance + amount, postBalance);
}
Т.е. мы разрешаем Foundry вставлять в параметры функции свои значения под uint amount и проверять исполнение.
Если прогнать этот тест, то мы увидим, что он провалится, так как на одном из шагов будет предложено значение 2**96 wei, что вызовет overflow.
В документации сказано, что так можно проверять и другие типы данных: строки и булево значения. Но чаще всего используют именно для чисел.
Также в тестах можно определять границы подставляемых значений с помощью команды vm.assume(), например, для нашего случая:
vm.assume(amount > 0.1 ether);
Сами тесты прогоняются 256 раз по умолчанию. Другими словами, программа попробует подставить 256 различных значений и проверить их.
Мы можем изменить этот параметр в файле конфигурации, добавив строку:
fuzz_runs = 10000 (количество тестов)
Подобные тесты очень помогают для проверки расчетов и транзакций в наших функциях, так как мы никогда не сможем предугадать, кто и как будет использовать наш контракт.
В общем, Foundry сильно облегчает нам работу!
#foundry
👍3
Тесты с Foundry. Часть 6
В видео у Ильи мы делали тесты конечных результатов выполнения функции с помощью команды assertEq(), которая проверяет равны ли введённые значения.
В Foundry есть и другие команды для проверки условий:
assertGt() - проверка, если "а" больше "б";
assertGe() - проверка, если "а" больше или равно "б";
assertLt() - проверка, если "а" меньше "б";
assertLe() - проверка, если "а" меньше или равно "б";
assertTrue() - проверка, если значение возвращает true;
Также возможно и такие проверки:
assertEqDecimal() - проверка равности значений decimals, например:
uint256 a = 1 ether;
uint256 b = 1e18 wei;
assertEqDecimal(a, b, 18);
assertEq32() - равны ли значения bytes32;
assertEq0() - равны ли значения bytes;
Еще мне очень понравилось, что достаточно много команд и проверок можно выполнять в самой консоли. Об этом можно почитать тут.
В общем, с помощью cast команд в локальной сети можно просматривать транзакции, подписывать ее, рассчитывать газ, получить код деплоя или информацию о блоке, работать с адресом и abi контракта, а также получать данные из etherscan (при наличии API ключа) и много чего еще.
Вот, чем больше я изучаю Foundry, тем больше он мне нравится. И что самое интересное, это довольно таки новый проект. Есть большая вероятность, что с дальнейшим развитием, он станет еще круче!
#foundry
В видео у Ильи мы делали тесты конечных результатов выполнения функции с помощью команды assertEq(), которая проверяет равны ли введённые значения.
В Foundry есть и другие команды для проверки условий:
assertGt() - проверка, если "а" больше "б";
assertGe() - проверка, если "а" больше или равно "б";
assertLt() - проверка, если "а" меньше "б";
assertLe() - проверка, если "а" меньше или равно "б";
assertTrue() - проверка, если значение возвращает true;
Также возможно и такие проверки:
assertEqDecimal() - проверка равности значений decimals, например:
uint256 a = 1 ether;
uint256 b = 1e18 wei;
assertEqDecimal(a, b, 18);
assertEq32() - равны ли значения bytes32;
assertEq0() - равны ли значения bytes;
Еще мне очень понравилось, что достаточно много команд и проверок можно выполнять в самой консоли. Об этом можно почитать тут.
В общем, с помощью cast команд в локальной сети можно просматривать транзакции, подписывать ее, рассчитывать газ, получить код деплоя или информацию о блоке, работать с адресом и abi контракта, а также получать данные из etherscan (при наличии API ключа) и много чего еще.
Вот, чем больше я изучаю Foundry, тем больше он мне нравится. И что самое интересное, это довольно таки новый проект. Есть большая вероятность, что с дальнейшим развитием, он станет еще круче!
#foundry
👍3
Защита от атак Signature Replay
Несколько раз в задачах встречал уязвимости с подписями пользователей транзакций, что приводило к Front run и Signature Replay атакам. Мне захотелось чуть больше узнать о них. И для начала небольшой пример кода:
function unlock(
address _to,
uint256 _amount,
uint8[] _v,
bytes32[] _r,
bytes32[] _s
)
external
{
require(_v.length >= 5);
bytes32 hashData = keccak256(_to, _amount);
for (uint i = 0; i < _v.length; i++) {
address recAddr = ecrecover(hashData, _v[i], _r[i], _s[i]);
require(_isValidator(recAddr));
}
to.transfer(_amount);
}
Это сильно упрощенный код из аудиторского отчета одного из мостов. По своей сути, функция запрашивает как минимум 5 подписей, чтобы разблокировать сумму и отправить ее получателю.
Другими словами, поставщик должен собрать пять подписей на проведение транзакции, после чего он может отправить ее на исполнение. Поняли в чем подвох?
В тот момент, когда поставщик отправит транзакцию в мемпул, злоумышленник может скопировать данные подписи и сам вызвать unlock() уже со своим адресом для получения активов. И делать это можно до тех пор, пока пул не будет опустошен!
Самой простой защитой было бы добавить nonce в аргументы функции (индивидуальный номер) и проверку типа require(_nonce == nonce++).
Как же получше защититься от них?
Вот три самых популярных решения:
1. Сохранять message hash в контракте, и позже проверять его на предмет повтора;
2. Включать в message hash адрес контракта, чтобы удостовериться, что сообщение используется только в данном контрактом;
3. Никогда не генерировать message hash вместе с подписью пользователя.
Будьте очень осторожны в работе с подписями и в обязательном порядке проверяйте их уникальность.
#signaturereplay #signature #replay #security
Несколько раз в задачах встречал уязвимости с подписями пользователей транзакций, что приводило к Front run и Signature Replay атакам. Мне захотелось чуть больше узнать о них. И для начала небольшой пример кода:
function unlock(
address _to,
uint256 _amount,
uint8[] _v,
bytes32[] _r,
bytes32[] _s
)
external
{
require(_v.length >= 5);
bytes32 hashData = keccak256(_to, _amount);
for (uint i = 0; i < _v.length; i++) {
address recAddr = ecrecover(hashData, _v[i], _r[i], _s[i]);
require(_isValidator(recAddr));
}
to.transfer(_amount);
}
Это сильно упрощенный код из аудиторского отчета одного из мостов. По своей сути, функция запрашивает как минимум 5 подписей, чтобы разблокировать сумму и отправить ее получателю.
Другими словами, поставщик должен собрать пять подписей на проведение транзакции, после чего он может отправить ее на исполнение. Поняли в чем подвох?
В тот момент, когда поставщик отправит транзакцию в мемпул, злоумышленник может скопировать данные подписи и сам вызвать unlock() уже со своим адресом для получения активов. И делать это можно до тех пор, пока пул не будет опустошен!
Самой простой защитой было бы добавить nonce в аргументы функции (индивидуальный номер) и проверку типа require(_nonce == nonce++).
Как же получше защититься от них?
Вот три самых популярных решения:
1. Сохранять message hash в контракте, и позже проверять его на предмет повтора;
2. Включать в message hash адрес контракта, чтобы удостовериться, что сообщение используется только в данном контрактом;
3. Никогда не генерировать message hash вместе с подписью пользователя.
Будьте очень осторожны в работе с подписями и в обязательном порядке проверяйте их уникальность.
#signaturereplay #signature #replay #security
👍2
Новые уязвимости? Часть 1. Фантомные функции
Нашел интересную статью на английском языке, где приводятся возможные новые уязвимости, на которые стоит обращать внимание. Предлагаю перевод в нескольких постах.
Фантомные функции
Представьте, что разработчик делает вызов случайной функции в НЕзадеплоеный контракт. Интуитивно, он ожидает, что транзакция будет откатана (revert), но это не так.
Объяснить это можно особенностью работы EVM: вся работа байткода контракта заканчивается специальным опкодом Stop. Именно он говорит EVM вернуть результат (return) без каких-либо ошибок.
Ситуация меняется с задеплоенными контрактами, когда разработчик вызывает несуществующую функцию и EVM делает revert.
Но и тут есть нюанс, а именно наличие fallback функции, которая выполняет определенные действия в этом случае.
Вот тут и может таиться уязвимость. Разработчик ожидает, что:
1) Транзакция откатится, если такой функции в контракте не существует;
2) А если такая функция существует, то транзакция может откатиться, если что-то пойдет не так;
Но, что если вызываемой функции в контракте нет, но есть fallback функция, которая принимает любые параметры и никогда не откатывается? Посмотрите на код ниже:
function depositWithPermit(...) {
IERC20(token).permit(receiver, address(this), value, deadline, v, r, s);
IERC20(token).transferFrom(receiver, address(this), value);
}
Это реальный код одного из проектов. Разработчики ожидали, что transferFrom() может быть вызван только после того как пользователь пройдет permit(), в другом случае должен был произойти откат. Однако некоторые токены, типа WETH, не имеют функции permit(), но есть fallback(), которая никогда не делает revert.
В этом случае хакер может пройти permit() и опустошить контракт, заранее сделав approve() на себя.
При аудите контракта всегда нужно предполагать, что разработчики могли предусмотреть не все случаи откатов транзакций, или не знать о подобных вариантах работы EVM.
#security #phantom
Нашел интересную статью на английском языке, где приводятся возможные новые уязвимости, на которые стоит обращать внимание. Предлагаю перевод в нескольких постах.
Фантомные функции
Представьте, что разработчик делает вызов случайной функции в НЕзадеплоеный контракт. Интуитивно, он ожидает, что транзакция будет откатана (revert), но это не так.
Объяснить это можно особенностью работы EVM: вся работа байткода контракта заканчивается специальным опкодом Stop. Именно он говорит EVM вернуть результат (return) без каких-либо ошибок.
Ситуация меняется с задеплоенными контрактами, когда разработчик вызывает несуществующую функцию и EVM делает revert.
Но и тут есть нюанс, а именно наличие fallback функции, которая выполняет определенные действия в этом случае.
Вот тут и может таиться уязвимость. Разработчик ожидает, что:
1) Транзакция откатится, если такой функции в контракте не существует;
2) А если такая функция существует, то транзакция может откатиться, если что-то пойдет не так;
Но, что если вызываемой функции в контракте нет, но есть fallback функция, которая принимает любые параметры и никогда не откатывается? Посмотрите на код ниже:
function depositWithPermit(...) {
IERC20(token).permit(receiver, address(this), value, deadline, v, r, s);
IERC20(token).transferFrom(receiver, address(this), value);
}
Это реальный код одного из проектов. Разработчики ожидали, что transferFrom() может быть вызван только после того как пользователь пройдет permit(), в другом случае должен был произойти откат. Однако некоторые токены, типа WETH, не имеют функции permit(), но есть fallback(), которая никогда не делает revert.
В этом случае хакер может пройти permit() и опустошить контракт, заранее сделав approve() на себя.
При аудите контракта всегда нужно предполагать, что разработчики могли предусмотреть не все случаи откатов транзакций, или не знать о подобных вариантах работы EVM.
#security #phantom
❤2
Новые уязвимости? Часть 2. Double-Entry Point Tokens
Я даже не смог найти подходящий перевод для этой уязвимости, поэтому оставим ее в изначальном варианте.
Эта уязвимость была обнаружена в контрактах Compound с токеном TrueUSD.
У них был некий Legacy Contract, который пользователи могли использовать как и контракт токена TUSD, и все, что он делал, это просто перенаправлял действия в TUSD.
Таким образом пользователи имели одинаковые балансы на обоих контрактах, и могли делать переводы с любого из них.
При этом, если пользователь пополнял TUSD, то мог влиять на цену токена в пуле token\cToken, что приводило к другой атаке - манипуляция оракулом.
В случае аудита биржевых контрактов, мы всегда должны смотреть, на что влияет баланс контракта, баланс пользователя на контракте и оракулы, а также с чем они связаны.
#security #phantom
Я даже не смог найти подходящий перевод для этой уязвимости, поэтому оставим ее в изначальном варианте.
Эта уязвимость была обнаружена в контрактах Compound с токеном TrueUSD.
У них был некий Legacy Contract, который пользователи могли использовать как и контракт токена TUSD, и все, что он делал, это просто перенаправлял действия в TUSD.
Таким образом пользователи имели одинаковые балансы на обоих контрактах, и могли делать переводы с любого из них.
При этом, если пользователь пополнял TUSD, то мог влиять на цену токена в пуле token\cToken, что приводило к другой атаке - манипуляция оракулом.
В случае аудита биржевых контрактов, мы всегда должны смотреть, на что влияет баланс контракта, баланс пользователя на контракте и оракулы, а также с чем они связаны.
#security #phantom
Новые уязвимости? Часть 3. Новые наивные токены
Все мы знаем, что код и контракты в блокчейне открыты для всех. И ничего не стоит скопировать их, слегка изменить и выдать за свой проект.
В последние годы участились подобные случаи копирования. Разница лишь в том, что оригиналы контрактов пишут профессионалы, а затем отдают их на аудит, а вторые - копипастят, и зачастую бездумно.
Также было и с токеном XDAI, который после обновления, добавил новую функцию-хук callAfterTransfer(). Именно ее копировальщики и не восприняли всерьез.
Без определённых действий защиты для этой функции, которые предотвращали reentrancy в XDAI, остальные контракты оказались уязвимыми для хакеров.
Поэтому хороший аудитор должен знать контракты популярных проектов, типа Uniswap, чтобы в дальнейшем понимать, был ли скопирован этот код или контракт оригинальный.
#security #phantom
Все мы знаем, что код и контракты в блокчейне открыты для всех. И ничего не стоит скопировать их, слегка изменить и выдать за свой проект.
В последние годы участились подобные случаи копирования. Разница лишь в том, что оригиналы контрактов пишут профессионалы, а затем отдают их на аудит, а вторые - копипастят, и зачастую бездумно.
Также было и с токеном XDAI, который после обновления, добавил новую функцию-хук callAfterTransfer(). Именно ее копировальщики и не восприняли всерьез.
Без определённых действий защиты для этой функции, которые предотвращали reentrancy в XDAI, остальные контракты оказались уязвимыми для хакеров.
Поэтому хороший аудитор должен знать контракты популярных проектов, типа Uniswap, чтобы в дальнейшем понимать, был ли скопирован этот код или контракт оригинальный.
#security #phantom
Новые уязвимости? Часть 4. Атаки NFT Flashloan
Эта уязвимость была обнаружена при AirDrop токенов для проекта BAYC. Владелец NFT мог вызвать функцию claimTokens() и получить взамен токены Apes равные количеству NFT.
Другие проекты, типа NFTX пытаются привнести механизмы DeFi в мир NFT. Другими словами, они блокируют на контракте ваш NFT и дают взамен токены.
При этом NFTX также предлагает флеш займы этих токенов, что по сути является займом данного оригинального NFT.
Получается, что сторонний пользователь может взять займ этого NFT, зайти на проект BYAC и получить бесплатный AirDrop.
Вероятнее всего, аудиторам придется предусматривать и такие развития ситуаций в скором будущем.
#security #phantom
Эта уязвимость была обнаружена при AirDrop токенов для проекта BAYC. Владелец NFT мог вызвать функцию claimTokens() и получить взамен токены Apes равные количеству NFT.
Другие проекты, типа NFTX пытаются привнести механизмы DeFi в мир NFT. Другими словами, они блокируют на контракте ваш NFT и дают взамен токены.
При этом NFTX также предлагает флеш займы этих токенов, что по сути является займом данного оригинального NFT.
Получается, что сторонний пользователь может взять займ этого NFT, зайти на проект BYAC и получить бесплатный AirDrop.
Вероятнее всего, аудиторам придется предусматривать и такие развития ситуаций в скором будущем.
#security #phantom
👍1
Новые уязвимости? Часть 5. Read-Only Reentrancy
Еще одна интересная атака. Попробую объяснить ее просто.
Все мы знаем, что некоторые функции в контрактах защищаются с помощью модификатора nonReentrant или каким-либо другим способом, который предотвращает повторный вход в функцию, до момента ее полного исполнения.
После ее выполнения практически всегда изменяется одна из переменных состояния, например баланс пользователя или пула.
Так вот, несмотря на то, что в external функции ставят защиту, view функции порой обходят стороной. А зря.
Теперь небольшой пример.
Возьмем функцию remove_liquidity(), которая удаляет все токены ликвидности с пула, делает рассылку underling токенов участникам один за одним в цикле, и в конце изменяет стоимость токена и его баланс.
Далее есть view функция get_virtual_price(), на которую полагаются другие протоколы, и которая показывает цену токена.
Хакер, в этих протоколах, мог вызывать view функцию через fallback(), в тот момент когда шла рассылка токенов в remove_liquidity(), и проводить свои манипуляции не до конца измененной ценой данного токена.
Надеюсь более-менее понятно расписал, потому что я сам пару раз запутывался в логике.
Проводя аудит контракта, теперь нам нужно следить и за view функциями, особенно, когда они на полагаются на баланс или цену токенов из стороннего контракта или биржи в целом.
#security #phantom
Еще одна интересная атака. Попробую объяснить ее просто.
Все мы знаем, что некоторые функции в контрактах защищаются с помощью модификатора nonReentrant или каким-либо другим способом, который предотвращает повторный вход в функцию, до момента ее полного исполнения.
После ее выполнения практически всегда изменяется одна из переменных состояния, например баланс пользователя или пула.
Так вот, несмотря на то, что в external функции ставят защиту, view функции порой обходят стороной. А зря.
Теперь небольшой пример.
Возьмем функцию remove_liquidity(), которая удаляет все токены ликвидности с пула, делает рассылку underling токенов участникам один за одним в цикле, и в конце изменяет стоимость токена и его баланс.
Далее есть view функция get_virtual_price(), на которую полагаются другие протоколы, и которая показывает цену токена.
Хакер, в этих протоколах, мог вызывать view функцию через fallback(), в тот момент когда шла рассылка токенов в remove_liquidity(), и проводить свои манипуляции не до конца измененной ценой данного токена.
Надеюсь более-менее понятно расписал, потому что я сам пару раз запутывался в логике.
Проводя аудит контракта, теперь нам нужно следить и за view функциями, особенно, когда они на полагаются на баланс или цену токенов из стороннего контракта или биржи в целом.
#security #phantom
👍1
Пример работы Frontrun ботов
Нашел прекрасное видео, хоть и на английском языке, которое демонстрирует как работают frontrun боты в мемпуле.
Рекомендую к просмотру каждому.
#frontrun #security
Нашел прекрасное видео, хоть и на английском языке, которое демонстрирует как работают frontrun боты в мемпуле.
Рекомендую к просмотру каждому.
#frontrun #security
YouTube
How To Get Front-Run on Ethereum mainnet
In this video, we:
- Cover the concept of front-running
- Write and deploy a smart contract that is vulnerable to front-running
- Put 0.035 ETH (~$8) in the contract
- Submit a transaction that is front-run by several parties, creating a gas-war to be the…
- Cover the concept of front-running
- Write and deploy a smart contract that is vulnerable to front-running
- Put 0.035 ETH (~$8) in the contract
- Submit a transaction that is front-run by several parties, creating a gas-war to be the…
👍2
Код - ловушка
Посмотрите внимательно на код на скрине. Если вы повстречаете его где-либо, то, скорее всего, перед вами типичная honeypot ловушка.
Помните, что address(this).balance всегда включает в себя msg.value данной транзакции.
#security
Посмотрите внимательно на код на скрине. Если вы повстречаете его где-либо, то, скорее всего, перед вами типичная honeypot ловушка.
Помните, что address(this).balance всегда включает в себя msg.value данной транзакции.
#security
👍4
Задача на день
Эта задача ранее была опубликована Immunefi, и прекрасно подтверждает один недавний пост на канале. Сможете понять в чем тут дело?
Подсказка
Посмотрите пост про frontrun на канале пару дней назад и вы сможете понять, какие ошибки были допущены тут.
#task
Эта задача ранее была опубликована Immunefi, и прекрасно подтверждает один недавний пост на канале. Сможете понять в чем тут дело?
Подсказка
👍1
Интересный нюанс с 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
В Твиттере у одного из аудиторов увидел пост о том, что 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
👍2
Блог с разбором взломов
Вчера на канале у Officer CIA проскочило короткое сообщение, в котором он рекомендовал блоги:
faith2dxy.xyz и faraz.faith
Это, по сути, один и тот же блог одного автора. Просто он решил сделать обновление и перешел на другой домен.
Автор делает разборы взломов с примерами кода и объяснением хода атак. Все достаточно подробно описано. Прекрасное чтиво на праздники.
#secirity #blog
Вчера на канале у Officer CIA проскочило короткое сообщение, в котором он рекомендовал блоги:
faith2dxy.xyz и faraz.faith
Это, по сути, один и тот же блог одного автора. Просто он решил сделать обновление и перешел на другой домен.
Автор делает разборы взломов с примерами кода и объяснением хода атак. Все достаточно подробно описано. Прекрасное чтиво на праздники.
#secirity #blog
👍4
Домашнее задание на каникулы
Новый год приближается и в повседневности наступает больше суеты. Сейчас у меня не получается сесть за обучение на несколько часов и концентрироваться на нем. Поэтому я решил взять небольшой отпуск с 28 декабря по 8 января.
И так как канал сейчас ушел в сторону безопасности смарт контрактов и аудита, я хотел бы предложить вам некоторое домашнее задание на каникулы.
Я оставлю здесь несколько ссылок, где вы сможете почитать о найденных уязвимостях и повысить свои знания.
Сборник найденных уязвимостей 1
Сборник найденных уязвимостей 2
Сборник найденных уязвимостей 3
Аудиты Code4rena
Аудиты Immunefi
Старайтесь не бросать обучение в период праздников, хоть это будет сделать довольно сложно. Открывайте по ссылке раз день, читайте отчет или баг в свободное время, как это собираюсь делать я.
С 9 января мы продолжим наше обучение, вернемся к аудитам и ведению канала.
Сегодня будет еще один пост с рекомендациями для подписок в Твиттере на других аудиторов, надеюсь вы сможете добавить кого-нибудь еще.
#homework
Новый год приближается и в повседневности наступает больше суеты. Сейчас у меня не получается сесть за обучение на несколько часов и концентрироваться на нем. Поэтому я решил взять небольшой отпуск с 28 декабря по 8 января.
И так как канал сейчас ушел в сторону безопасности смарт контрактов и аудита, я хотел бы предложить вам некоторое домашнее задание на каникулы.
Я оставлю здесь несколько ссылок, где вы сможете почитать о найденных уязвимостях и повысить свои знания.
Сборник найденных уязвимостей 1
Сборник найденных уязвимостей 2
Сборник найденных уязвимостей 3
Аудиты Code4rena
Аудиты Immunefi
Старайтесь не бросать обучение в период праздников, хоть это будет сделать довольно сложно. Открывайте по ссылке раз день, читайте отчет или баг в свободное время, как это собираюсь делать я.
С 9 января мы продолжим наше обучение, вернемся к аудитам и ведению канала.
Сегодня будет еще один пост с рекомендациями для подписок в Твиттере на других аудиторов, надеюсь вы сможете добавить кого-нибудь еще.
#homework
👍3
Делимся ссылками
Решил поделиться своей подборкой на различные аккаунты аудиторов и компаний, за которыми наблюдаю в Твиттере. На удивление, эта соцсеть оказалась отличной штукой для поиска информации и людей.
Вы также можете в комментариях поделиться своими подписками и рекомендациями, и не только в Твиттере.
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
Решил поделиться своей подборкой на различные аккаунты аудиторов и компаний, за которыми наблюдаю в Твиттере. На удивление, эта соцсеть оказалась отличной штукой для поиска информации и людей.
Вы также можете в комментариях поделиться своими подписками и рекомендациями, и не только в Твиттере.
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
Подписавшись на них, вы сможете не только составить свою ленту "без воды", но и получать дельные советы по разработке смарт контрактов.
Можете спокойно сохранять себе и делать репосты.
🔥7👍4
С Новым Годом!
Поздравляю всех с Новым Годом! Желаю, чтобы все ваши усилия в штурмовании web3 сполна окупились в 2023, и уже в его конце, вы, попивая пинаколаду где-нибудь на Бали, подумали: "А ведь все это было не зря!".
Еще раз С Новым Годом! Удачи, здоровья и безопасности!
🎄🎄🎄🎄🎄🎄🎄🎄
Поздравляю всех с Новым Годом! Желаю, чтобы все ваши усилия в штурмовании web3 сполна окупились в 2023, и уже в его конце, вы, попивая пинаколаду где-нибудь на Бали, подумали: "А ведь все это было не зря!".
Еще раз С Новым Годом! Удачи, здоровья и безопасности!
🎄🎄🎄🎄🎄🎄🎄🎄
👍9🔥4
Возвращаемся к работе
Всем привет! Надеюсь вы отлично провели праздничные дни и готовы к достижению новых высот в web3.
Приятно видеть, что за время небольшого отпуска на канале к нам присоединилось еще несколько участников! Буду рад, если вы найдете тут много полезной и новой для себя информации.
Поделюсь своими планами на развитие канала.
Прежде всего, я решил для себя сфокусироваться на конкурсных аудитах на таких площадках как code4rena и sherlock.
Да, у меня до нового года были планы создать проект в коопе для портфолио, а также написать небольшой ресурс для русскоговорящих разработчиков, но подумал, что аудиты смогут быстрее принести мне доход, а также некоторый рейтинг, который поможет в найме. Поэтому только аудиты.
На канале я буду выкладывать некоторые моменты из аудиторских отчетов, описание эксплойтов, работу с foundry, а также нюансы по EVM и Solidity.
Чего не будет на канале?
На канале не будет постов про "связывание" контрактов и фронтенда, подключение ethers.js и метамаска, токеномики, создание ботов и игру на бирже.
Фокус будет нацелен на безопасность смарт контрактов и их тестирование в foundry.
При этом, если кто-то вдруг захочет также писать на канал про темы фронтенда - я буду только за! Однако писать надо будет подробно, с примерами кода.
Для новичков, скорее всего, это будет сложно, поэтому рекомендую для начала пройти все уроки от Ильи на Ютуб.
Всем прекрасного года и легкого обучения!
Всем привет! Надеюсь вы отлично провели праздничные дни и готовы к достижению новых высот в web3.
Приятно видеть, что за время небольшого отпуска на канале к нам присоединилось еще несколько участников! Буду рад, если вы найдете тут много полезной и новой для себя информации.
Поделюсь своими планами на развитие канала.
Прежде всего, я решил для себя сфокусироваться на конкурсных аудитах на таких площадках как code4rena и sherlock.
Да, у меня до нового года были планы создать проект в коопе для портфолио, а также написать небольшой ресурс для русскоговорящих разработчиков, но подумал, что аудиты смогут быстрее принести мне доход, а также некоторый рейтинг, который поможет в найме. Поэтому только аудиты.
На канале я буду выкладывать некоторые моменты из аудиторских отчетов, описание эксплойтов, работу с foundry, а также нюансы по EVM и Solidity.
Чего не будет на канале?
На канале не будет постов про "связывание" контрактов и фронтенда, подключение ethers.js и метамаска, токеномики, создание ботов и игру на бирже.
Фокус будет нацелен на безопасность смарт контрактов и их тестирование в foundry.
При этом, если кто-то вдруг захочет также писать на канал про темы фронтенда - я буду только за! Однако писать надо будет подробно, с примерами кода.
Для новичков, скорее всего, это будет сложно, поэтому рекомендую для начала пройти все уроки от Ильи на Ютуб.
Всем прекрасного года и легкого обучения!
👍8🔥2
Для начинающих аудиторов
Небольшая заметка для тех, кто только начинает свой путь в аудитах на популярных площадках, как и я.
Не знаю, каков был ваш путь в обучении, но у меня за последние месяцы упор был на CTF задачи, аудиторские отчеты и статьи по взломам. Отсюда вылезла небольшая проблема, когда я впервые столкнулся с конкурсным аудитом.
Дело в том, что в задачах / отчетах / статьях я имел дело с конкретными функциями или короткими контрактами, зачастую не больше двух. Да и код в них был довольно короткий: 50 - 100 строчек кода.
И вот когда я решил попробовать свои силы в конкурсе, я был слегка обескуражен: количество контрактов было около 15 и строк кода около 3500. И я такой: "Эмм, и что с этим делать"...
Полез сразу в forge init, установку зависимостей и т.д. Открыл первый контракт... Второй... Третий... И ничего не понятно.
Не, функции читаемые, описания есть, но объемы вводят в ступор. Только позже, поэкспериментировав на каникулах, я понял, с чего нужно начинать аудит.
Ответ прост: читайте документацию.
Перед любым аудитом вам стоит потратить пару часов на:
- Прочтение условий конкурса. Порой из 20 контрактов на аудит просят всего 5 из них. Т.е. даже если вы найдете уязвимость в 6 контракте - за него не заплатят.
- Прочтение документации проекта. Посетите их сайт или репо на GitHub, чтобы узнать более детальные подробности о контрактах и логике работы;
- Прочтение архитектуры проекта. Поищите схему взаимодействия контрактов, иногда она публикуется где-то отдельно от обычной документации.
И вот после всего этого, когда вы сможете объяснить необходимость каждого контракта в наборе, вы можете открывать код и приступать к его изучению.
#audit #аудит
Небольшая заметка для тех, кто только начинает свой путь в аудитах на популярных площадках, как и я.
Не знаю, каков был ваш путь в обучении, но у меня за последние месяцы упор был на CTF задачи, аудиторские отчеты и статьи по взломам. Отсюда вылезла небольшая проблема, когда я впервые столкнулся с конкурсным аудитом.
Дело в том, что в задачах / отчетах / статьях я имел дело с конкретными функциями или короткими контрактами, зачастую не больше двух. Да и код в них был довольно короткий: 50 - 100 строчек кода.
И вот когда я решил попробовать свои силы в конкурсе, я был слегка обескуражен: количество контрактов было около 15 и строк кода около 3500. И я такой: "Эмм, и что с этим делать"...
Полез сразу в forge init, установку зависимостей и т.д. Открыл первый контракт... Второй... Третий... И ничего не понятно.
Не, функции читаемые, описания есть, но объемы вводят в ступор. Только позже, поэкспериментировав на каникулах, я понял, с чего нужно начинать аудит.
Ответ прост: читайте документацию.
Перед любым аудитом вам стоит потратить пару часов на:
- Прочтение условий конкурса. Порой из 20 контрактов на аудит просят всего 5 из них. Т.е. даже если вы найдете уязвимость в 6 контракте - за него не заплатят.
- Прочтение документации проекта. Посетите их сайт или репо на GitHub, чтобы узнать более детальные подробности о контрактах и логике работы;
- Прочтение архитектуры проекта. Поищите схему взаимодействия контрактов, иногда она публикуется где-то отдельно от обычной документации.
И вот после всего этого, когда вы сможете объяснить необходимость каждого контракта в наборе, вы можете открывать код и приступать к его изучению.
#audit #аудит
👍4
Double Entry Point
На каникулах прочитал об одном интересном эксплойте, который случился с Balancer в 2022 году. Саму статью можно прочитать тут, а я дам краткий пересказ уязвимости.
Balancer позволяет пользователям брать быстрые займы без залога, если они будут возвращены в той же транзакции. Именно в функции flashloan и крылся интересный баг.
Кратко говоря, функция узнавала изначальный баланс имеющихся токенов для займа, высчитывала процент займа и пересылала средства пользователю. Также там была fallback функция receiveFlashLoan(), которая должна была быть определена в контракте пользователя для возврата займа.
После того, как займ возвращался обратно от пользователя, высчитывалась разница в изначальном и конечном балансах, и эта разница пересылалась в другой контракт Balancer, который использовался как сейф.
Так в чем же здесь может быть проблема?
А в том, что контракт функционировал через прокси.
Мы же помним, что в правильном варианте работы логики прокси контрактов, пользователь взаимодействует именно с прокси, который позже переводит все действия в контракт исполнения? Т.е., упрощенно говоря, мы вызываем какую-либо функцию в прокси контракте, она делегирует исполнения в третий контракт.
Так вот, в случае с Balancer пользователь мог взаимодействовать как с прокси контрактов, так и с третьим контрактом напрямую! Это-то и создавало баг double entry point.
В примере эксплойта, который приводится в статье, хакер мог запросить займ токенов из обоих контрактов: прокси и исполнения. Причем в первом случае он брал займ на 100% возможную сумму токенов, а во втором - 0. Это создавало некий баг в конечный расчетах, что приводило к тому, что весь займ токенов переводился в контракт Сейфа, и никто потом больше не мог брать займ под этот токен.
Да, хакер не получал ничего, но и работа сервиса стопорилась.
Мне просто понравился этот баг, и теперь при аудите контрактов, где используется прокси и erc20, я всегда проверяю и эту возможность.
#security #doubleentrypoint
На каникулах прочитал об одном интересном эксплойте, который случился с Balancer в 2022 году. Саму статью можно прочитать тут, а я дам краткий пересказ уязвимости.
Balancer позволяет пользователям брать быстрые займы без залога, если они будут возвращены в той же транзакции. Именно в функции flashloan и крылся интересный баг.
Кратко говоря, функция узнавала изначальный баланс имеющихся токенов для займа, высчитывала процент займа и пересылала средства пользователю. Также там была fallback функция receiveFlashLoan(), которая должна была быть определена в контракте пользователя для возврата займа.
После того, как займ возвращался обратно от пользователя, высчитывалась разница в изначальном и конечном балансах, и эта разница пересылалась в другой контракт Balancer, который использовался как сейф.
Так в чем же здесь может быть проблема?
А в том, что контракт функционировал через прокси.
Мы же помним, что в правильном варианте работы логики прокси контрактов, пользователь взаимодействует именно с прокси, который позже переводит все действия в контракт исполнения? Т.е., упрощенно говоря, мы вызываем какую-либо функцию в прокси контракте, она делегирует исполнения в третий контракт.
Так вот, в случае с Balancer пользователь мог взаимодействовать как с прокси контрактов, так и с третьим контрактом напрямую! Это-то и создавало баг double entry point.
В примере эксплойта, который приводится в статье, хакер мог запросить займ токенов из обоих контрактов: прокси и исполнения. Причем в первом случае он брал займ на 100% возможную сумму токенов, а во втором - 0. Это создавало некий баг в конечный расчетах, что приводило к тому, что весь займ токенов переводился в контракт Сейфа, и никто потом больше не мог брать займ под этот токен.
Да, хакер не получал ничего, но и работа сервиса стопорилась.
Мне просто понравился этот баг, и теперь при аудите контрактов, где используется прокси и erc20, я всегда проверяю и эту возможность.
#security #doubleentrypoint
👍7
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
Нашел интересную ветку в Твиттере с описанием данной уязвимости.
Все подписи содержат в себе значения:
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
👍3