🔥 Как чуть не взломали EVAA.
Пару месяцев назад @gosunov и @peskarbrain изучали код смарт-контрактов EVAA, и обнаружили интересное. От обнуления TVL EVAA спасла чистая случайность. Важно: в коде больше ничего найдено не было, информация в посте на данный момент уже точно устаревшая.
EVAA, как и любой здоровый DeFi протокол на TON, использует vanity контракты (они у EVAA названы blank). Это удобно, позволяет не зависеть от конкретной версии протокола — абсолютный best practice на TON, всем советуем.
По сути vanity контракты — это система авторизации внутри DeFi архитектуры, поэтому с ней нужно быть максимально внимательным. Если ты авторизуешь контракт по vanity-дате, то тебе нужно быть уверенным, что его никто, кроме тебя, не может задеплоить (это делается с помощью проверки деплоера на vanity), и что никак иначе подменить vanity-код с помощью твоей архитектуры нельзя. Со вторым у EVAA возникла проблема.
Всё возможно, как это часто на TON случается, от слишком большой свободы. EVAA позволяет пользователям отправлять кастомные сообщения (forward data) при выводе TON из протокола (при заёме или выводе средств). Ранее недостаточный контроль данных в кастомных сообщениях привела к багу в DEX coffee swap, мы об этом писали.
Из существующих деталей пазла собрать предположительную (в реальности она не работает и никогда не работала) атаку очень просто:
1) Деплоим ванити контракт вместо EVAA (разумеется, подменить мы ничего на нём не можем).
2) Отправляем на него вывод из протокола, в forward_data которого указываем новый код для замены. Vanity проверяет, что сообщение пришло от правильного адреса (с волта EVAA), поэтому авторизует его и принимает все данные из сообщения как должные — подменяет свой код, и вуаля, у нас есть свой собственноручно написанный контракт внутри периметра ончейн архитектуры EVAA.
Спасла EVAA чистая случайность (или холодный расчёт) — их опкоды операций внутри архитектуры все начинались с нескольких лидирующих нулей. Из-за этого maybe_ref, которым должен был быть код нашего кастомного контракта, для vanity считался пустым, и он его игнорировал. Интересно то, что если бы EVAA соблюли стандарт по формированию опкодов через crc32, то атака была бы возможна.
Несмотря на несколько аудитов от крайне крупных аудиторских компаний, практика показывает, что это крайне типовой баг для блокчейна TON, и об этом всегда стоит думать при проектировании архитектуры смарт-контрактов. Если хотите проверить вашу ончейн логику — обращайтесь к @TheOpenDevTeam.
Везёт тому, кто везёт.
@TheOpenDevBlog
Пару месяцев назад @gosunov и @peskarbrain изучали код смарт-контрактов EVAA, и обнаружили интересное. От обнуления TVL EVAA спасла чистая случайность. Важно: в коде больше ничего найдено не было, информация в посте на данный момент уже точно устаревшая.
EVAA, как и любой здоровый DeFi протокол на TON, использует vanity контракты (они у EVAA названы blank). Это удобно, позволяет не зависеть от конкретной версии протокола — абсолютный best practice на TON, всем советуем.
По сути vanity контракты — это система авторизации внутри DeFi архитектуры, поэтому с ней нужно быть максимально внимательным. Если ты авторизуешь контракт по vanity-дате, то тебе нужно быть уверенным, что его никто, кроме тебя, не может задеплоить (это делается с помощью проверки деплоера на vanity), и что никак иначе подменить vanity-код с помощью твоей архитектуры нельзя. Со вторым у EVAA возникла проблема.
Всё возможно, как это часто на TON случается, от слишком большой свободы. EVAA позволяет пользователям отправлять кастомные сообщения (forward data) при выводе TON из протокола (при заёме или выводе средств). Ранее недостаточный контроль данных в кастомных сообщениях привела к багу в DEX coffee swap, мы об этом писали.
Из существующих деталей пазла собрать предположительную (в реальности она не работает и никогда не работала) атаку очень просто:
1) Деплоим ванити контракт вместо EVAA (разумеется, подменить мы ничего на нём не можем).
2) Отправляем на него вывод из протокола, в forward_data которого указываем новый код для замены. Vanity проверяет, что сообщение пришло от правильного адреса (с волта EVAA), поэтому авторизует его и принимает все данные из сообщения как должные — подменяет свой код, и вуаля, у нас есть свой собственноручно написанный контракт внутри периметра ончейн архитектуры EVAA.
Спасла EVAA чистая случайность (или холодный расчёт) — их опкоды операций внутри архитектуры все начинались с нескольких лидирующих нулей. Из-за этого maybe_ref, которым должен был быть код нашего кастомного контракта, для vanity считался пустым, и он его игнорировал. Интересно то, что если бы EVAA соблюли стандарт по формированию опкодов через crc32, то атака была бы возможна.
Несмотря на несколько аудитов от крайне крупных аудиторских компаний, практика показывает, что это крайне типовой баг для блокчейна TON, и об этом всегда стоит думать при проектировании архитектуры смарт-контрактов. Если хотите проверить вашу ончейн логику — обращайтесь к @TheOpenDevTeam.
Везёт тому, кто везёт.
@TheOpenDevBlog