Добро пожаловать обратно в "Уязвимости в центре внимания Шерлока", где мы подчеркиваем значительную уязвимость, обнаруженную во время аудита Шерлока. На этой неделе мы обсудим Спуфинг Депозита. Он был обнаружен @0xalpharush и @bernd_eth на Конкурсе Кросс-Чейн от @zetablockchain. 🧵

Вот резюме уязвимости от @bernd_eth: 1. Наблюдатели ZetaChain отслеживают транзакции на внешних цепочках (например, Ethereum, Solana) и добавляют их в централизованный входящий трекер для обработки как депозитов и выводов, предполагая успешность транзакции. 2. В отличие от интеграции EVM, реализация Solana пропускает проверки успешности транзакции, что позволяет злонамеренному наблюдателю добавлять неудачные депозиты, создавая необеспеченные ZRC20 SOL и истощая средства, переведенные через мост. 3. Несмотря на то, что наблюдатели явно находятся в белом списке ZetaChain, критически важно убедиться, что ни одна сторона не может скомпрометировать цепочку или siphon активы.

Обычно наблюдатели не обрабатывают неудачные транзакции, но этот кодовый путь не выполняет ту же проверку, что и его аналог в EVM. Хотя это требует "привилегированной" роли, каждый валидатор является наблюдателем, и консенсус BFT должен быть устойчивым к византийским ошибкам, т.е. терпеть <1/3 злонамеренных участников. Таким образом, один злонамеренный наблюдатель не должен иметь возможности подделать депозит и заставить честных валидаторов голосовать за чеканку ZRC20 Sol для неудачных транзакций через входящий трекер, который не имеет проверок для своей реализации Solana.

Коренная причина этой уязвимости: Функция ProcessInboundEvents не требует, чтобы транзакция была успешной, в отличие от наблюдателя EVM, который делает это правильно здесь. Поскольку инструкция декодируется так, как будто она была успешной, злонамеренный наблюдатель может подделать депозит для всего баланса ZRC20-SOL, а затем вывести SOL, заблокированный на стороне Solana моста, украдя все лампорты в мосту. Эта атака также может быть использована для вывода токенов SPL или выполнения произвольных депозитов и вызовов. Например, удаление свойства записи из PDA шлюза в инструкции депозита приводит к неудачной транзакции (см. ошибку ограничения якоря в POC), и она все равно может быть обработана после добавления в входящий трекер через MsgAddInboundTracker.

Внутренние предварительные условия: Злоумышленный или небрежный наблюдатель добавляет неудачную транзакцию Solana, содержащую инструкции Gateway, в входящий трекер с помощью MsgAddInboundTracker, в результате чего все валидаторы обрабатывают и голосуют за чеканку ZRC20 Sol на Zetachain. CCTX получает достаточное количество голосов, и неконтролируемый ZRC20 Sol на Zetachain чеканится.

Внешние предварительные условия: Любая сторона отправляет неудачную транзакцию в шлюз с инструкцией по депозиту (или депозитом и вызовом). Получатель ZRC20 Sol на Zetachain выводит его и получает лампорты на Solana.

Путь атаки: 1) Любая сторона отправляет неудачную транзакцию на шлюз с инструкцией по депозиту (или депозит и вызов). 2) Злоумышленник или небрежный наблюдатель добавляет неудачную транзакцию Solana, которая содержит инструкции шлюза, в входящий трекер с помощью MsgAddInboundTracker, в результате чего все валидаторы обрабатывают и голосуют за чеканку ZRC20 Sol на Zetachain. 3) Задача ProcessInboundTrackers заставляет подделанную CCTX получить достаточное количество голосов, и неконтролируемый ZRC20 Sol на Zetachain чеканится. 4) Получатель ZRC20 Sol на Zetachain выводит его и получает лампорты на Solana.

Каков эффект? Все лампорты и токены SPL, внесенные в мост Solana, могут быть украдены, поскольку депозиты могут быть подделаны на любую сумму (они обрабатываются, несмотря на то, что программа Gateway вызывает откат транзакций).

Смягчение: В процессе обработки входного трекера Solana Observer проверьте, успешна ли транзакция, прежде чем голосовать за нее.

Мы гордимся тем, что помогли обеспечить безопасность @zetablockchain благодаря этому открытию. Когда безопасность имеет первостепенное значение, Шерлок — правильный выбор.