Bentornati al Vulnerability Spotlight di Sherlock, dove mettiamo in evidenza una vulnerabilità significativa scoperta durante un audit di Sherlock. Questa settimana, abbiamo il Deposit Spoofing. È stata scoperta da @0xalpharush & @bernd_eth nel Contest Cross-Chain di @zetablockchain. 🧵

Ecco il riassunto della vulnerabilità di @bernd_eth: 1. Gli osservatori di ZetaChain monitorano le transazioni su catene esterne (ad es., Ethereum, Solana) e le aggiungono a un tracker inbound centralizzato per elaborarle come depositi e prelievi, assumendo il successo della transazione. 2. A differenza dell'integrazione EVM, l'implementazione di Solana salta i controlli di successo delle transazioni, consentendo a un osservatore malevolo di aggiungere depositi falliti, coniando SOL ZRC20 non garantiti e drenando i fondi trasferiti. 3. Nonostante gli osservatori siano esplicitamente autorizzati da ZetaChain, è fondamentale garantire che nessuna singola parte possa compromettere la catena o drenare asset.

Normalmente, gli osservatori non elaborano le transazioni fallite, ma questo percorso di codice non esegue la stessa validazione del suo equivalente EVM. Sebbene ciò richieda un ruolo "privilegiato", ogni validatore è un osservatore, e il consenso BFT dovrebbe essere tollerante ai guasti, cioè tollerare <1/3 di parti malevole. Pertanto, un osservatore malevolo non dovrebbe essere in grado di falsificare un deposito e indurre validatori onesti a votare per coniare ZRC20 Sol per transazioni fallite attraverso il tracker in entrata, che manca di validazioni per la sua implementazione su Solana.

La causa principale di questa vulnerabilità: La funzione ProcessInboundEvents non richiede che una transazione sia andata a buon fine, a differenza dell'osservatore inbound EVM, che lo fa correttamente qui. Poiché l'istruzione viene decodificata come se fosse andata a buon fine, un osservatore malevolo può simulare un deposito per l'intero saldo ZRC20-SOL e poi ritirare l'SOL bloccato sul lato Solana del ponte, rubando tutti i lamports nel ponte. Questo attacco potrebbe essere utilizzato anche per ritirare token SPL o eseguire depositi e chiamate arbitrari. Ad esempio, rimuovere la proprietà scrivibile dal PDA del gateway nell'istruzione di deposito porta a una transazione fallita (vedi l'errore di vincolo dell'ancora nel POC), e può comunque essere elaborata una volta aggiunta al tracker inbound tramite MsgAddInboundTracker.

Condizioni preliminari interne: Un osservatore malevolo o negligente aggiunge una transazione Solana fallita che contiene istruzioni Gateway al tracker in entrata utilizzando MsgAddInboundTracker, risultando in tutti i validatori che elaborano e votano per coniare ZRC20 Sol su Zetachain. Il CCTX riceve voti sufficienti e ZRC20 Sol non garantito su Zetachain viene coniato.

Condizioni preliminari esterne: Qualsiasi parte invia una transazione fallita al gateway con un'istruzione di deposito (o deposito e chiamata). Il destinatario del ZRC20 Sol su Zetachain lo ritira e riceve lamports su Solana.

Il percorso dell'attacco: 1) Qualsiasi parte invia una transazione fallita al gateway con un'istruzione di deposito (o deposito e chiamata). 2) Un osservatore malevolo o negligente aggiunge una transazione Solana fallita che contiene istruzioni del Gateway al tracker in entrata utilizzando MsgAddInboundTracker, risultando in tutti i validatori che elaborano e votano per coniare ZRC20 Sol su Zetachain. 3) Il compito ProcessInboundTrackers fa sì che il CCTX falsificato riceva voti sufficienti, e ZRC20 Sol non garantito su Zetachain viene coniato. 4) Il destinatario dello ZRC20 Sol su Zetachain lo ritira e riceve lamports su Solana.

Qual è l'impatto? Tutti i lamport e i token SPL depositati nel ponte Solana possono essere rubati, dato che i depositi possono essere falsificati per qualsiasi importo (vengono elaborati nonostante il programma Gateway faccia annullare le transazioni).

La Mitigazione: Nel processo di tracciamento in entrata dell'Osservatore di Solana, controlla se la transazione è riuscita prima di votare su di essa.

Siamo orgogliosi di aver contribuito a garantire @zetablockchain attraverso questa scoperta. Quando è assolutamente necessario essere sicuri, Sherlock è la scelta giusta.