Как искать уязвимости
Нашел для себя прикольный способ поиска уязвимостей в контракте, который подходит больше всего к проверке функций. Назвал его "А что если".
Вот смотрите вы на свою функцию или на ту, что в контракте аудита, и начинаете:
А что если... :
- Ввести нулевой адрес;
- Ввести свой адрес;
- Не вносить вообще ничего;
- Не тому пользователю отправляются деньги;
- Повлиять на сумму в transfer;
- Деньги / токены / не дойдут;
- Вызвать переполнение;
- Получить права админа;
- Зайти в функцию дважды;
- Подменить логику;
- Нет белого списка;
- Остались апрувы;
- Взять флеш займ;
- Обнулить счет;
- Обойти require;
и так далее. В моем случае, мне так легче сформировать цель атаки, чем вычитывать строку за строкой, пытаясь понять, что с этим кодом не так.
Надеюсь и вам поможет мой способ.
#hint #security
Нашел для себя прикольный способ поиска уязвимостей в контракте, который подходит больше всего к проверке функций. Назвал его "А что если".
Вот смотрите вы на свою функцию или на ту, что в контракте аудита, и начинаете:
А что если... :
- Ввести нулевой адрес;
- Ввести свой адрес;
- Не вносить вообще ничего;
- Не тому пользователю отправляются деньги;
- Повлиять на сумму в transfer;
- Деньги / токены / не дойдут;
- Вызвать переполнение;
- Получить права админа;
- Зайти в функцию дважды;
- Подменить логику;
- Нет белого списка;
- Остались апрувы;
- Взять флеш займ;
- Обнулить счет;
- Обойти require;
и так далее. В моем случае, мне так легче сформировать цель атаки, чем вычитывать строку за строкой, пытаясь понять, что с этим кодом не так.
Надеюсь и вам поможет мой способ.
#hint #security
👍2
Защита от атак 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
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
Signature Malleability 2
Ну, и еще одна уязвимость от того же автора из Твиттер.
Посмотрите на скрин. Вероятно, вы видели или сами реализовывали такое восстановление подписи у себя в контракте.
Но тут чего-то не хватает?
А точнее, тут не хватает валидации S значения!
if (uint256(s) > 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 ) {
return (address(0), RecoverError.InvalidSignatureS);
}
Если открыть контракт от OpenZeppelin, то там увидите довольно большой комментарий, зачем нужна проверка этого значения.
Из-за особенностей работы системы, сюда вы можете передать две разные подписи (с одинаковым подписанным сообщением) и получить один и тот же восстановленный адрес!
В этой ветке дается объяснения почему это происходит, и как это связано с EIP2 и secp256k1n/2. Спойлер: особенности шифрования.
Как я понял, вообще нужно быть очень аккуратными и внимательными с этими подписями и их восстановлением.
#security #signature #eip2
Ну, и еще одна уязвимость от того же автора из Твиттер.
Посмотрите на скрин. Вероятно, вы видели или сами реализовывали такое восстановление подписи у себя в контракте.
Но тут чего-то не хватает?
А точнее, тут не хватает валидации S значения!
if (uint256(s) > 0x7FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF5D576E7357A4501DDFE92F46681B20A0 ) {
return (address(0), RecoverError.InvalidSignatureS);
}
Если открыть контракт от OpenZeppelin, то там увидите довольно большой комментарий, зачем нужна проверка этого значения.
Из-за особенностей работы системы, сюда вы можете передать две разные подписи (с одинаковым подписанным сообщением) и получить один и тот же восстановленный адрес!
В этой ветке дается объяснения почему это происходит, и как это связано с EIP2 и secp256k1n/2. Спойлер: особенности шифрования.
Как я понял, вообще нужно быть очень аккуратными и внимательными с этими подписями и их восстановлением.
#security #signature #eip2
👍1
Классная задача от Immunefi
Уже в первых числах января Immunefi выложила еще одну задачу, которая меня очень впечатлила.
Для того, чтобы понять всю идею, откройте скрин на весь экран и внимательно прочитайте код строчка за строчкой.
Я напишу ответ не закрытый, как обычно, так как большинство участников точно не знает, в чем тут может быть проблема.
С кодом все ок. По крайней мере, если не знать особенностей работы контрактов токенов и разных EIP.
В случае с ERC20 - все будет ок. Однако проблемы могут начаться, если хакер захочет использовать токены ERC777.
Если кто не знает, то такие токены стандарта ERC777 при трансфере имеют не одну, а целых две callback функции:
_callTokensToSend() - которая вызывается до фактической отправки токенов;
_callTokensReceived() - которая вызывается после отправки токенов.
Обе они в рамках функции transfer(). Поняли теперь, в чем дело в задаче?
Используя _callTokensToSend() токена, хакер может заходить в функцию deposit() несколько раз (reentrancy), и спровоцировать увеличенное количество shares!
Лично я не знал этого момента. Пришлось покопаться в сети, чтобы понять принципы работы.
Интересно, да?
#task #security #erc777
Уже в первых числах января Immunefi выложила еще одну задачу, которая меня очень впечатлила.
Для того, чтобы понять всю идею, откройте скрин на весь экран и внимательно прочитайте код строчка за строчкой.
Я напишу ответ не закрытый, как обычно, так как большинство участников точно не знает, в чем тут может быть проблема.
С кодом все ок. По крайней мере, если не знать особенностей работы контрактов токенов и разных EIP.
В случае с ERC20 - все будет ок. Однако проблемы могут начаться, если хакер захочет использовать токены ERC777.
Если кто не знает, то такие токены стандарта ERC777 при трансфере имеют не одну, а целых две callback функции:
_callTokensToSend() - которая вызывается до фактической отправки токенов;
_callTokensReceived() - которая вызывается после отправки токенов.
Обе они в рамках функции transfer(). Поняли теперь, в чем дело в задаче?
Используя _callTokensToSend() токена, хакер может заходить в функцию deposit() несколько раз (reentrancy), и спровоцировать увеличенное количество shares!
Лично я не знал этого момента. Пришлось покопаться в сети, чтобы понять принципы работы.
Интересно, да?
#task #security #erc777
👍2
Задачка на день
Ну, и небольшая задачка на день. Сможете найти, в чем тут проблема?
Решение
В аудитах следует всегда обращать внимание на модификаторы функций, какие условия они нам ставят.
В текущем же примере, он просто сверяет msg.sender с другим параметров, а значит, что функция _safeMint() не защищена от reentrancy атак.
#security #task
Ну, и небольшая задачка на день. Сможете найти, в чем тут проблема?
Решение
В текущем же примере, он просто сверяет msg.sender с другим параметров, а значит, что функция _safeMint() не защищена от reentrancy атак.
👍2
Read-only-reentrancy
Я уже писал ранее о новой уязвимости, которая может получить распространение в этом году. Она основана на том, что даже если функция выполняющая внешний вызов защищена от reentrancy модификатором, библиотекой или как-то еще, но есть другая view / pure функция, которая используется ней, производя какие-то расчеты, например, по выплатам rewards, то все равно сохраняется возможность взлома.
Теперь аудиторы должны научиться распознавать подобные штуки в контрактах.
Пользователь под ником Bytes32 в Твиттере сделал прекрасную ветку, где расписал эту уязвимость не только на простом примере, но и показал реальный контракт, где это было возможно.
Обязательно к прочтению для всех аудиторов!
#security #reentracy
Я уже писал ранее о новой уязвимости, которая может получить распространение в этом году. Она основана на том, что даже если функция выполняющая внешний вызов защищена от reentrancy модификатором, библиотекой или как-то еще, но есть другая view / pure функция, которая используется ней, производя какие-то расчеты, например, по выплатам rewards, то все равно сохраняется возможность взлома.
Теперь аудиторы должны научиться распознавать подобные штуки в контрактах.
Пользователь под ником Bytes32 в Твиттере сделал прекрасную ветку, где расписал эту уязвимость не только на простом примере, но и показал реальный контракт, где это было возможно.
Обязательно к прочтению для всех аудиторов!
#security #reentracy
👍3🤔1
Подборка проектов с новостями
Встретил на просторах Твиттера прекрасную подборку проектов, которые пишут статьи или делают новостную рассылку о последних взломах и вопросах безопасности в блокчейне.
Secureum
Blockchain Threat Intelligence
Week in Ethereum News
NotOnlyOwner
Vulnerability Research by Samczsun
Noxx
Faith's Blog
Cygaar’s Substack
Rekt
DeFiHackLabs’s Substack
Если вас не раздражают емайл рассылки, то эти будут как нельзя кстати!
#email #security #news
Встретил на просторах Твиттера прекрасную подборку проектов, которые пишут статьи или делают новостную рассылку о последних взломах и вопросах безопасности в блокчейне.
Secureum
Blockchain Threat Intelligence
Week in Ethereum News
NotOnlyOwner
Vulnerability Research by Samczsun
Noxx
Faith's Blog
Cygaar’s Substack
Rekt
DeFiHackLabs’s Substack
Если вас не раздражают емайл рассылки, то эти будут как нельзя кстати!
#email #security #news
👍5🔥2❤1
ReentrancyGuard в прокси?
Необычный способ реализации ReentrancyGuard предложила одна из команд на мероприятии ETHDenver 2023 Hackathon.
Основной смысл заключается в том, чтобы вместо добавления модификатора ReentrancyGuard в каждую функцию в контракте Логики, создать защиту только в Прокси контракте.
Не смотря на то, что это поможет избежать популярных багов и недочетов со стороны команды разработчиков при последующих обновлениях, система не до конца проверена и безопасна.
Более подробно можно прочитать в этой статье.
Возможно, мы скоро увидим этот концепт в конкурсных аудитах.
#reentrancy #security #proxy
Необычный способ реализации ReentrancyGuard предложила одна из команд на мероприятии ETHDenver 2023 Hackathon.
Основной смысл заключается в том, чтобы вместо добавления модификатора ReentrancyGuard в каждую функцию в контракте Логики, создать защиту только в Прокси контракте.
Не смотря на то, что это поможет избежать популярных багов и недочетов со стороны команды разработчиков при последующих обновлениях, система не до конца проверена и безопасна.
Более подробно можно прочитать в этой статье.
Возможно, мы скоро увидим этот концепт в конкурсных аудитах.
#reentrancy #security #proxy
Not So-Famous Solidity Attack Vectors
Одновременно прекрасное и ужасное видео с с конференции ETH Dubai, рассказывающее о не самых очевидных атаках в смарт контрактах.
Прекрасное оно из-за набора тем, которые поднимает спикер. Многие из них действительно могут быть упущены при аудите. Ужасное же оно только из-за сложности восприятия речи. Будет сложно даже тем, кто хорошо знает и понимает английский язык.
Тем не менее, видео достойное для изучения.
#security #ethdubai
Одновременно прекрасное и ужасное видео с с конференции ETH Dubai, рассказывающее о не самых очевидных атаках в смарт контрактах.
Прекрасное оно из-за набора тем, которые поднимает спикер. Многие из них действительно могут быть упущены при аудите. Ужасное же оно только из-за сложности восприятия речи. Будет сложно даже тем, кто хорошо знает и понимает английский язык.
Тем не менее, видео достойное для изучения.
#security #ethdubai
YouTube
Not So-Famous Solidity Attack Vectors, often missed/overlooked while Auditing! by Tejaswa Rastogi
Get notified when tickets, dates and call for speakers are available for our next edition in 2024 https://www.ethdubaiconf.org/api/next
👍6
Бесплатный курс от Statemind
Ребята из Statemind попросили поделиться информацией о наборе на свой бесплатный курс Smart Contract Security Specialist.
Кратно об обучении:
• Обучение онлайн
• Длительность 4 недели
• Обучение на английском/русском языках
• Отбор проводим по входному тесту (в форме)
• После успешного прохождения программы проводим интервью и по результатам предлагаем возможность присоединиться к нашей команде в качестве интерна (мы работаем удаленно)
• Обучение с нашей стороны бесплатное, потому что основная наша задача - найти единомышленников
• Помогаем с релокацией
В программе курса:
• Introduction to blockchain
• DeFi primitives
• DeFi security
Подробная информация и форма для заполнения для тех, кому будет интересно
https://docs.google.com/forms/d/e/1FAIpQLSfdCWi1HYlU1nZs62WwwYA-PZZi7msTqpHnpBtMOARFPer2vg/viewform?usp=sf_link
Залетайте!
P.S. Подчеркну, что потребуется знание английского языка!
#statemind #security
Ребята из Statemind попросили поделиться информацией о наборе на свой бесплатный курс Smart Contract Security Specialist.
Кратно об обучении:
• Обучение онлайн
• Длительность 4 недели
• Обучение на английском/русском языках
• Отбор проводим по входному тесту (в форме)
• После успешного прохождения программы проводим интервью и по результатам предлагаем возможность присоединиться к нашей команде в качестве интерна (мы работаем удаленно)
• Обучение с нашей стороны бесплатное, потому что основная наша задача - найти единомышленников
• Помогаем с релокацией
В программе курса:
• Introduction to blockchain
• DeFi primitives
• DeFi security
Подробная информация и форма для заполнения для тех, кому будет интересно
https://docs.google.com/forms/d/e/1FAIpQLSfdCWi1HYlU1nZs62WwwYA-PZZi7msTqpHnpBtMOARFPer2vg/viewform?usp=sf_link
Залетайте!
P.S. Подчеркну, что потребуется знание английского языка!
#statemind #security
👍13❤6🔥1👌1
Канал разбора конкурсных отчетов
Кстати, я продолжаю вести закрытый канал, где мы разбираем баги с конкурсных аудитов. В день выкладываю по два небольших разбора, иногда делаю посты по нюансам в безопасности СК, на которые стоит обращать внимание, задачки, а также иногда "заходим" в небольшой конкурс и рассматриваем его в течение нескольких дней.
Сейчас уже разобрали более 100 различных уязвимостей и 3 конкурсных протокола. Дальше будем смотреть на проблемы с defil протоколами и сетями l2.
Если хотите прокачать свои навыки в поиске багов и начать чуть лучше разбираться в безопасности протоколов, то приглашаю присоединиться к нам.
Доступ в группу идет по месячной оплате в 1000 рублей, чтобы в ней оставались только те, кому интересная и актуальна тема.
Буду рад новым участникам!
#security
Кстати, я продолжаю вести закрытый канал, где мы разбираем баги с конкурсных аудитов. В день выкладываю по два небольших разбора, иногда делаю посты по нюансам в безопасности СК, на которые стоит обращать внимание, задачки, а также иногда "заходим" в небольшой конкурс и рассматриваем его в течение нескольких дней.
Сейчас уже разобрали более 100 различных уязвимостей и 3 конкурсных протокола. Дальше будем смотреть на проблемы с defil протоколами и сетями l2.
Если хотите прокачать свои навыки в поиске багов и начать чуть лучше разбираться в безопасности протоколов, то приглашаю присоединиться к нам.
Доступ в группу идет по месячной оплате в 1000 рублей, чтобы в ней оставались только те, кому интересная и актуальна тема.
Буду рад новым участникам!
#security
👍5🔥1