Вот здесь был пост про CPIMP атаки, когда скрытно компрометируется прокси контракт
Особенность такого вида атак в том числе состоит в том, что их достаточно сложно детектировать, потому что атака специально разработана для скрытного присутствия
Но обнаружить её всё же можно, в этом нам помогут
1. Анализ логов транзакции деплоя. Двойной
event Upgraded является признаком CPIMP. Само событие - стандарт для прокси-контрактов, но в норме оно одно.2. Глубокая трассировка вызовов. Сначала основной прокси вызывает контракт CPIMP, который выполняет свою вредоносную логику, а затем делает второй
delegatecall к оригинальному контракту реализации. Это отображается как двойной delegatecall3. Проверка подмены слотов хранения. Хакеры используют spoofing для обмана блокчейн-сканеров, так что при взгляде на контракт в сканере не видно ничего подозрительного. Так что необходимо вручную считывать содержимое всех критических слотов через
eth_getStorageAt и сравнивать их с ожидаемыми значениями.4. Верификация байткода и хеш-сумм. CPIMP может мимикрировать под ABI легитимного контракта, простой проверки функций недостаточно. Лучше получить сырой байткод по адресу, указанному в слоте реализации EIP-1967, и сравнить его хеш с хешем байткода заведомо чистого контракта реализации.
5. Анализ на устойчивость к обновлениям. Особенность атаки заключается в том, что вредоносный контракт перезаписывает адрес реализации в конце каждой транзакции. Вредоносный код использует функцию, которая выполняет операцию
SSTORE в критический слот реализации. Для того, чтобы увидеть это, необходимо отслеживать изменения в слоте реализации в рамках одной транзакции. Если в начале транзакции слот указывает на один адрес, а в конце принудительно возвращается к адресу CPIMP, это явный признак persistence-логики (логики, направленной на удержание контроля)Так же существуют диагностические инструменты, такие как Watchdog от компании Dedaub, которые способны выявить подозрительные контракты
Источники
- Пост в блоге Dedaub
- Пост от Halburn
- Пост от Nevermind
https://t.me/web3securityresearch