Vítejte zpět u Sherlockova článku o zranitelnosti, kde upozorňujeme na závažnou zranitelnost odhalenou během Sherlockova auditu. Tento týden pro vás máme Deposit Spoofing. Bylo to odhaleno @0xalpharush & @bernd_eth v @zetablockchain Cross-Chain Contestu. 🧵

Zde je shrnutí této chyby zabezpečení podle @bernd_eth: 1. Pozorovatelé ZetaChainu sledují transakce na externích chainech (např. Ethereum, Solana) a přidávají je do centralizovaného sledovače příchozích dat, aby je zpracovali jako vklady a výběry, za předpokladu úspěchu transakce. 2. Na rozdíl od integrace EVM implementace Solana přeskakuje kontroly úspěšnosti transakcí, což umožňuje zlomyslnému pozorovateli přidávat neúspěšné vklady, razit nekryté ZRC20 SOL a odčerpávat překlenovací prostředky. 3. Navzdory tomu, že pozorovatelé jsou výslovně povoleni ZetaChainem, je důležité zajistit, aby žádná strana nemohla ohrozit řetězec nebo sifonová aktiva.

Za normálních okolností pozorovatelé nezpracovávají neúspěšné transakce, ale tato cesta kódu neprovádí stejnou validaci jako její protějšek EVM. I když to vyžaduje "privilegovanou" roli, každý validátor je pozorovatel a konsensus BFT má být byzantsky tolerantní, tj. tolerovat <1/3 zlomyslných stran. Jeden zlomyslný pozorovatel by tedy neměl být schopen zfalšovat vklad a přimět poctivé validátory, aby hlasovali pro ražbu ZRC20 Sol za neúspěšné transakce prostřednictvím příchozího trackeru, který postrádá ověření pro jeho implementaci Solana.

Hlavní příčina této chyby zabezpečení: Funkce ProcessInboundEvents nevyžaduje, aby transakce byla úspěšná, na rozdíl od příchozího pozorovatele EVM, který to zde dělá správně. Vzhledem k tomu, že instrukce je dekódována, jako by byla úspěšná, může zlomyslný pozorovatel podvrhnout vklad na celý zůstatek ZRC20-SOL a poté vybrat SOL uzamčený na straně mostu Solana, čímž ukradne všechny lamporty na můstku. Tento útok by mohl být také použit k výběru SPL token nebo k provádění svévolných vkladů a hovorů. Například odstranění zapisovatelné vlastnosti z PDA brány v instrukci pro vklad má za následek neúspěšnou transakci (viz chyba omezení ukotvení v POC) a lze ji stále zpracovat po přidání do příchozího sledovače pomocí MsgAddInboundTracker.

Vnitřní předpoklady: Zlomyslný nebo nedbalý pozorovatel přidá selhávající Solana tx, který obsahuje instrukce brány, do příchozího trackeru pomocí MsgAddInboundTracker, což má za následek, že všichni validátoři zpracují a odhlasují ražbu ZRC20 Sol na Zetachainu. CCTX získává dostatek hlasů a nekrytý ZRC20 Sol na Zetachainu je ražen.

Externí předpoklady: Kterákoli strana odešle neúspěšnou transakci bráně s instrukcí k vkladu (nebo vkladem a voláním). Příjemce ZRC20 Sol na Zetachainu jej vybírá a dostává lamporty na Solaně.

Cesta útoku: 1) Kterákoli strana odešle neúspěšnou transakci bráně s instrukcí k vkladu (nebo vkladem a voláním). 2) Zlomyslný nebo nedbalý pozorovatel přidá selhávající Solana tx, který obsahuje instrukce Gateway, do příchozího trackeru pomocí MsgAddInboundTracker, což má za následek, že všechny validátory zpracují a odhlasují ražbu ZRC20 Sol na Zetachainu. 3) Úloha ProcessInboundTrackers způsobí, že podvržený CCTX získá dostatek hlasů a nezajištěný ZRC20 Sol na Zetachainu je vyražen. 4) Příjemce ZRC20 Sol na Zetachainu jej vybírá a dostává lamporty na Solana.

Jaký to bude mít dopad? Všechny lamporty a SPL token uložené na mostě Solana mohou být odcizeny, protože vklady mohou být zfalšovány na libovolnou částku (jsou zpracovány navzdory tomu, že program Gateway způsobil vrácení transakcí zpět).

Zmírnění rizik: Při zpracování příchozího trackeru Solana Observer před hlasováním zkontrolujte, zda je transakce úspěšná.

Jsme hrdí na to, že jsme tímto objevem pomohli zajistit @zetablockchain. Když je to nezbytně nutné zabezpečit, je Sherlock tou správnou volbou.