CPIMP атака на 1kk$ или почему аудит скрипта деплоя важен

Итак, представьте, ваш код проходит два аудита, вы исправляете то, что считаете важным (а что считаете неважным помечаете known), но это не делает ваш протокол безопасным, потому что уязвимость в другом месте, а вот проекту UPD_io и представлять не нужно

Clandestine Proxy In the Middle Proxy — "скрытый/подпольный прокси посередине". Это сложная атака, включающая в себя фронтраннинг (посты про MEV не теряют актуальности: раз, два), направленная на upgradable контракты. Суть её заключается во вставке посредника между proxy и implementation контрактами. Эта вставка по сути является man in the middle. Известна стала в июле 2025 года.

В первом приближении схема upgradable контрактов выглядит так:
Прокси -> Имплементация
После CPIMP получается так:
Прокси -> Атакующий -> Имплементация

Что случилось
- 16 сентября 2025 года команда деплоила неинициализированный прокси-контракт
- В окне между деплоем и инициализацией (36 секунд) атакующий опередил команду с помощью Multicall3-транзакции, первым вызвал функцию initialize и захватил права администратора
- Атакующий установил свой malicious proxy, который перенаправлял вызовы на легитимный (аудированный) код, но позволял манипулировать транзакциями
- Для маскировки использовались манипуляции с событиями (events) и слотами хранения, чтобы на блок-эксплорерах (типа Etherscan) всё выглядело нормально — показывался легитимный код
- Атакующий ждал 78 дней, пока протокол набирал ликвидность, и только в декабре активировал эксплойт.

Почему его никто не заметил?
Потому что он гений. Строго говоря, заметить атаку можно было, если бы был проведен анализ логов сразу после деплоя, на это указывают и объясняют Chain Argos. Были подозрительные раздачи ролей на несвязанные с командой адреса, была инициализация контрактов.

А вот после деплоя для маскировки использовались две тактики:
1) Самовосстановление (self-restoration). После делегирования каждого вызова легитимному implementation-контракту CPIMP перезаписывал свой собственный адрес обратно в слот implementation до завершения транзакции. Пытаешься апгрейдить прокси, чтобы избавиться от него? Не сработает, такие дела
2) Подделка слотов для Etherscan (spoofing). Etherscan и другие блок-эксплореры определяют, какой код показывать для upgradeable-прокси, так:
- Читают стандартный слот хранения ERC1967/EIP-1967 (конкретный keccak-хэш), где лежит адрес implementation.
- Показывают верифицированный исходный код по этому адресу.

В реальности слот указывает на malicious-контракт. Но malicious-контракт специально написан так, чтобы перехватывать чтение этого самого слота: Когда кто-то (включая Etherscan) вызывает геттер implementation() или напрямую читает слот, malicious возвращает адрес легитимного контракта (тот, который команда задеплоила и верифицировала).
Поэтому на Etherscan всё выглядит идеально: показывается правильный, аудированный код, как будто ничего не случилось.
Сам malicious-контракт остаётся «в тени» — его код не отображается, и он не верифицирован. Атакующий изучил, как именно работают блок-эксплореры, и встроил эту подделку, чтобы даже внимательный осмотр на Etherscan не вызывал подозрений.

Всё это привело к тому, что 4 декабря 2025 года команда USPD сообщила о взломе. Атакующий сминтил около 98 миллионов токенов USPD и вывел ликвидность из пулов — примерно 232–237 stETH (около $1 млн на тот момент).

Тема прокси достаточно объемная, писать про них посты? Ставь реакцию, если да (и если просто понравился пост)

Источники для подготовки поста:
- Пост на rekt.news
- Разбор теории атаки от Nevermind
- Критика и разбор от chain argos
- Анализ от safe edges
- Анализ от halborn

https://t.me/web3securityresearch