Эксперты Certik рассказали подробности атаки на ALEX Protocol

Еще 6 июня эксперты Certik зафиксировали атаку на децентрализованный протокол ALEX, в результате которой из нескольких пулов ликвидности были похищены цифровые активы. По данным исследователей, злоумышленник вывел 8,4 млн STX, 21,85 sBTC, 149,85 тыс. aUSD и 2,8 aBTC. Эксперты рассказали, что эксплойт стал возможен из-за уязвимости в функции Permissionless Pool Creation, реализованной через метод Create2. Протокол допустил саморегистрацию токенов без надлежащей проверки, что позволило атакующему внедрить вредоносный смарт-контракт. Общая сумма ущерба оценивается выше $100 тыс. по текущим рыночным ценам.
Хакер сначала развернул фальшивый токен под названием labubu, встроив в него вредоносную реализацию метода transfer(). Этот способ, в отличие от стандартной версии, не просто передавал цифрвоые валюты, а активировал скрипт, который списывал средства у вызывающего адреса.
Далее токен был добавлен в интерфейс протокола ALEX через Self Listing Helper V3A. В этой версии отсутствовала должная валидация и контроль разрешений при создании новых пулов. Это дало злоумышленнику полную власть над логикой обмена и взаимодействием пула с внешними контрактами.
Когда пользователи или автоматические маркетмейкеры начинали своп с участием нового токена, происходил вызов вредоносного метода transfer(). Как только осуществлялась попытка перевода, активы с баланса вызывающего кошелька отправлялись в хранилище злоумышленника. Система не определяла передачу как подозрительную, поскольку с технической точки зрения операция соответствовала ожидаемому поведению.
Подобная техника использует пробелы в логике разрешенных взаимодействий и потенциально применима в других DeFi-средах. Именно отсутствие базовой валидации токенов и недостаточный аудит контрактов Helper V3A стали главными причинами инцидента.
Эксперты Certik подчеркивают, что Permissionless-подход к созданию пулов без централизованной проверки требует особенно строгого аудита всех вспомогательных библиотек и интерфейсов. Атака не была направлена на какую-либо уязвимость самого AMM-протокола или стеков, а лишь использовала слабости в процессах валидации.