На прошлой неделе произошла необычная цепочка событий в экосистеме Ethereum: злоумышленник попытался эксплуатировать уязвимость в кастомном модуле Safe (многоподписного кошелька Kelp), но вместо успеха столкнулся с собственным взломом. MEV-бот "Yoink", предназначенный для перехвата прибыльных транзакций, случайно встал на защиту проекта — он выполнил фронт-ран атаку быстрее самого злоумышленника и присвоил украденные средства себе.
В результате этого несвязанного между собой противостояния из экосистемы было извлечено 2 390 rsETH (примерно $7,7 млн на момент инцидента). rsETH — это токен стейкинга от Kelp DAO, позволяющий пользователям получать награды от валидации Ethereum без необходимости запирать полные 32 ETH. Кошелек Kelp содержал резервы этого токена, и именно они стали целью атаки.
Злоумышленник использовал уязвимость в кастомном модуле Safe — дополнительном контракте, который расширяет функциональность стандартного многоподписного кошелька. Такие модули часто содержат логику управления средствами или условных платежей, и если они недостаточно протестированы, могут создавать лазейки. Однако до критического момента дело не дошло: система Ethereum в данном случае сработала непредсказуемо для всех участников.
MEV-боты вроде "Yoink" — это автоматизированные контракты, которые мониторят мемпул (очередь неподтвержденных транзакций) в поиске выгодных возможностей для арбитража, ликвидаций или других манипуляций с порядком выполнения. "Yoink" специализируется на откровенно хищнических стратегиях: обнаружив перспективную транзакцию, он встраивает свою собственную транзакцию прямо перед ней, захватывая стоимость. В этом случае бот случайно оказал услугу Kelp, но из совершенно меркантильных мотивов — ему было все равно, кто пытается украсть средства, главное — успеть первым.
Команда Kelp оперативно заморозила адрес, на который был осуществлен перевод краденых средств. В блокчейне это означает добавление адреса в черный список специального контракта, из-за чего никакие манипуляции с токенами на этом адресе становятся невозможны (если другие контракты этот черный список соблюдают). Это классический подход для восстановления после взлома — попытка заблокировать выведенные средства до того, как они будут обменены на другие активы и размыты по множеству адресов.
Для российского бизнеса этот случай иллюстрирует несколько болезненных реалий блокчейн-приложений. Если компания использует кастомные смарт-контракты (будь то для управления резервами, условных платежей или автоматизации операций), каждая строка кода должна быть тщательно аудирована — уязвимость в малом модуле может привести к потере семизначных сумм в доллары. При разработке критичных контрактов стоит рассчитывать на профессиональный аудит третьей стороны, а не полагаться на собственное тестирование. Кроме того, имеет смысл продумать стратегию восстановления: наличие мултисига, возможность срочной заморозки контракта и предварительно подготовленных отношений с крупными майнингпулами или валидаторами может ускорить восстановление контроля над средствами после обнаружения взлома.
Случай Kelp также показывает, что опасность исходит не только от внешних злоумышленников, но и от самой природы Ethereum как платформы: в цепочке без единого арбитра и формального судопроизводства каждый контракт защищается исключительно корректностью своего кода. Попытка сыграть на опережение всегда чревата встречей с еще более быстрым игроком — в данном случае той встречей и стала.