Новые уязвимости? Часть 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
Немного о фантомных функциях
Уже несколько раз в различных статьях видел упоминания о фантомных функциях в контрактах. И вот еще одна прекрасная статья, рассказывающая о том, что в контрактах токенов могут быть подобные функции, которые могут привести к взлому.
Сама статья на английском языке, но ее суть в том, что если в контракте токена, как например в WETH, нет функции permit(), но есть fallback(), то вызывая из вашего контракта weth.premit() - транзакция не откатится с ошибкой.
Это может быть уязвимостью, как было в примере с AnySwap/MultiChain.
Подробнее читаем в статье.
#phantom #fallback #permit
Уже несколько раз в различных статьях видел упоминания о фантомных функциях в контрактах. И вот еще одна прекрасная статья, рассказывающая о том, что в контрактах токенов могут быть подобные функции, которые могут привести к взлому.
Сама статья на английском языке, но ее суть в том, что если в контракте токена, как например в WETH, нет функции permit(), но есть fallback(), то вызывая из вашего контракта weth.premit() - транзакция не откатится с ошибкой.
Это может быть уязвимостью, как было в примере с AnySwap/MultiChain.
Подробнее читаем в статье.
#phantom #fallback #permit
❤3