Witamy z powrotem w Sherlock's Vulnerability Spotlight, gdzie podkreślamy istotną lukę wykrytą podczas audytu Sherlocka. W tym tygodniu mamy Deposit Spoofing. Została ona odkryta przez @0xalpharush i @bernd_eth w konkursie Cross-Chain @zetablockchain. 🧵

Oto podsumowanie podatności od @bernd_eth: 1. Obserwatorzy ZetaChain monitorują transakcje na zewnętrznych łańcuchach (np. Ethereum, Solana) i dodają je do scentralizowanego rejestru przychodzącego, aby przetwarzać je jako depozyty i wypłaty, zakładając sukces transakcji. 2. W przeciwieństwie do integracji EVM, implementacja Solany pomija kontrole sukcesu transakcji, co pozwala złośliwemu obserwatorowi dodać nieudane depozyty, mintując niepoparte ZRC20 SOL i drenować środki z mostu. 3. Mimo że obserwatorzy są wyraźnie umieszczani na liście dozwolonych przez ZetaChain, kluczowe jest zapewnienie, że żadna pojedyncza strona nie może skompromitować łańcucha ani siphonować aktywów.

Zazwyczaj obserwatorzy nie przetwarzają nieudanych transakcji, ale ta ścieżka kodu nie wykonuje tej samej walidacji co jej odpowiednik w EVM. Chociaż wymaga to "uprzywilejowanej" roli, każdy walidator jest obserwatorem, a konsensus BFT ma być odporny na ataki byzantyjskie, tzn. tolerować <1/3 złośliwych stron. Zatem jeden złośliwy obserwator nie powinien być w stanie sfałszować depozytu i skłonić uczciwych walidatorów do głosowania na wyemitowanie ZRC20 Sol za nieudane transakcje poprzez tracker przychodzący, który nie ma walidacji dla swojej implementacji Solany.

Główną przyczyną tej podatności: Funkcja ProcessInboundEvents nie wymaga, aby transakcja zakończyła się sukcesem, w przeciwieństwie do obserwatora EVM, który robi to poprawnie tutaj. Ponieważ instrukcja jest dekodowana tak, jakby zakończyła się sukcesem, złośliwy obserwator może sfałszować depozyt dla całego salda ZRC20-SOL, a następnie wypłacić SOL zablokowane po stronie Solany mostu, kradnąc wszystkie lamporty w moście. Ten atak mógłby być również użyty do wypłaty tokenów SPL lub wykonania dowolnych depozytów i wywołań. Na przykład, usunięcie właściwości zapisu z PDA bramy w instrukcji depozytu skutkuje nieudana transakcją (zobacz błąd ograniczenia kotwicy w POC), a mimo to może być przetwarzana po dodaniu do śledzenia przychodzącego za pomocą MsgAddInboundTracker.

Wewnętrzne warunki wstępne: Złośliwy lub niedbały obserwator dodaje nieudane transakcje Solana, które zawierają instrukcje Gateway do śledzenia przychodzącego za pomocą MsgAddInboundTracker, co skutkuje tym, że wszyscy walidatorzy przetwarzają i głosują na wyemitowanie ZRC20 Sol na Zetachain. CCTX otrzymuje wystarczającą liczbę głosów, a niepoparte ZRC20 Sol na Zetachain jest emitowane.

Warunki wstępne: Każda strona wysyła nieudane transakcje do bramy z instrukcją wpłaty (lub wpłatą i połączeniem). Odbiorca ZRC20 Sol na Zetachain wypłaca go i otrzymuje lamporty na Solanie.

Ścieżka ataku: 1) Dowolna strona wysyła nieudane transakcje do bramy z instrukcją depozytu (lub depozytem i wywołaniem). 2) Złośliwy lub niedbały obserwator dodaje nieudaną transakcję Solana, która zawiera instrukcje bramy do śledzenia przychodzącego za pomocą MsgAddInboundTracker, co skutkuje tym, że wszyscy walidatorzy przetwarzają i głosują na wybicie ZRC20 Sol na Zetachain. 3) Zadanie ProcessInboundTrackers powoduje, że sfałszowane CCTX otrzymuje wystarczającą liczbę głosów, a niepoparte ZRC20 Sol na Zetachain jest wybite. 4) Odbiorca ZRC20 Sol na Zetachain wypłaca je i otrzymuje lamporty na Solanie.

Jaki jest wpływ? Wszystkie lamporty i tokeny SPL wpłacone w mostku Solana mogą zostać skradzione, ponieważ wpłaty mogą być fałszowane na dowolną kwotę (są przetwarzane mimo że program Gateway powoduje, że transakcje są odrzucane).

Łagodzenie: W procesie przetwarzania przychodzącego śledzenia Solana Observera sprawdź, czy transakcja zakończyła się sukcesem przed oddaniem na nią głosu.

Jesteśmy dumni, że mogliśmy pomóc zabezpieczyć @zetablockchain dzięki temu odkryciu. Kiedy bezpieczeństwo jest absolutnie konieczne, Sherlock to właściwy wybór.