Ласкаво просимо назад до Sherlock's Vulnerability Spotlight, де ми висвітлюємо вражаючу вразливість, виявлену під час аудиту Шерлока. Цього тижня ми маємо спуфінг депозитів. Він був виявлений @0xalpharush & @bernd_eth на конкурсі @zetablockchain Cross-Chain Contest. 🧵

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

Зазвичай спостерігачі не обробляють невдалі транзакції, але цей шлях до коду не виконує таку ж перевірку, як його аналог EVM. Хоча це вимагає «привілейованої» ролі, кожен валідатор є спостерігачем, а консенсус BFT має бути візантійським толерантним, тобто толерантним до <1/3 зловмисників. Таким чином, один зловмисний спостерігач не зможе підробити депозит і спонукати чесних валідаторів проголосувати за карбування ZRC20 Sol за невдалі транзакції через вхідний трекер, який не має перевірок для його реалізації Solana.

Першопричина цієї вразливості: Функція ProcessInboundEvents не вимагає, щоб транзакція була успішною, на відміну від EVM inbound observer, який тут робить це правильно. Оскільки інструкція розшифровується так, ніби вона вдалася, зловмисний спостерігач може підробити депозит для всього балансу ZRC20-SOL, а потім вивести SOL, заблокований на стороні Solana мосту, викравши всі ламппорти в мосту. Ця атака також може бути використана для виведення токенів SPL або виконання довільних депозитів і дзвінків. Наприклад, видалення записуваної властивості з КПК шлюзу в інструкції депозиту призводить до помилки транзакції (див. помилку обмеження прив'язки в POC), і вона все ще може бути оброблена після додавання до вхідного трекера через MsgAddInboundTracker.

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

Зовнішні передумови: Будь-яка сторона надсилає невдалу транзакцію на шлюз з інструкцією щодо депозиту (або внести депозит і зателефонувати). Одержувач ZRC20 Sol на Zetachain відкликає його та отримує ламппорти на Solana.

Шлях атаки: 1) Будь-яка сторона надсилає невдалу транзакцію до шлюзу з інструкцією щодо депозиту (або внести депозит і зателефонувати). 2) Зловмисний або недбайливий спостерігач додає несправний TX Solana, який містить інструкції шлюзу, до вхідного трекера за допомогою MsgAddInboundTracker, в результаті чого всі валідатори обробляють і голосують за карбування ZRC20 Sol на Zetachain. 3) Завдання ProcessInboundTrackers призводить до того, що підроблений CCTX отримує достатню кількість голосів, і карбується незабезпечений ZRC20 Sol на Zetachain. 4) Одержувач ZRC20 Sol на Zetachain відкликає його та отримує ламппорти на Solana.

Які наслідки? Усі лемпорти та токени SPL, депоновані на мосту Solana, можуть бути вкрадені, враховуючи, що депозити можуть бути підроблені на будь-яку суму (вони обробляються, незважаючи на те, що програма Gateway спричиняє скасування транзакцій).

Пом'якшення наслідків: Під час обробки вхідного трекера Solana Observer перевірте, чи транзакція пройшла успішно, перш ніж голосувати за неї.

Ми пишаємося тим, що допомогли убезпечити @zetablockchain завдяки цьому відкриттю. Коли це конче потрібно убезпечити, Шерлок – правильний вибір.