Analisi dell'incidente del ponte nomade

Tl;dr: Costruire un ecosistema crittografico migliore significa costruire un futuro migliore e più equo per tutti noi. Ecco perché stiamo investendo nella comunità più ampia per assicurarci che chiunque voglia partecipare alla criptoeconomia possa farlo in modo sicuro. In questo post del blog condividiamo lezioni sulla natura della vulnerabilità, sulla metodologia di sfruttamento e sull'analisi a catena del comportamento degli aggressori durante l'incidente di Nomad Bridge.

Sebbene il compromesso del ponte Nomad non influisca direttamente su Coinbase, lo crediamo fermamente gli attacchi a qualsiasi attività di crittografia sono dannosi per l'industria nel suo insieme e spero che le informazioni nel blog aiutino a rafforzare e informare progetti simili sulle minacce e sulle tecniche utilizzate da attori malintenzionati.

Di: Peter Kacherginsky, Intelligence sulle minacce e Heidi Wilder, Investigazioni speciali

Il 1 agosto 2022 Nomad Bridge ha subito il quarto più grande hack DeFi con oltre 186 milioni di dollari rubati in poche ore. Come abbiamo descritto nel ns recente post sul blog, dal compromesso del Ronin Bridge da 540 milioni di dollari di marzo all'hacking del ponte Wormhole da 250 milioni di dollari nel febbraio del 2022, non è un caso che i bridge DeFi rappresentino alcuni degli incidenti più costosi nel nostro settore.

Ciò che rende unico il compromesso di Nomad Bridge è la semplicità dell'exploit e il gran numero di individui che ne approfittano per svuotare pezzo per pezzo tutti i beni immagazzinati.

Nomade è un protocollo ponte che supporta Ethereum, Moonbeam e altre catene. Il protocollo di bridging di Nomad è costruito utilizzando componenti sia on-chain che off-chain. I contratti intelligenti on-chain vengono utilizzati per raccogliere e distribuire fondi con ponte mentre gli agenti fuori-chain trasmettono e verificano i messaggi tra diversi blockchain. Ogni blockchain distribuisce un contratto Replica che convalida e archivia i messaggi in una struttura ad albero Merkle. I messaggi possono essere convalidati fornendo una prova con il provaEProcesso() call o per messaggi già verificati possono essere semplicemente inviati con il processi() chiamata. I messaggi verificati vengono inoltrati a un gestore Bridge (es. Router ERC20) che può distribuire asset con bridge.

Il 21 aprile 2022 Nomad schierato una replica contratto di delega per gestire l'elaborazione e la convalida delle affermazioni degli utenti sulle risorse collegate. Questo proxy consentirebbe a Nomad di modificare facilmente la logica di implementazione mantenendo lo spazio di archiviazione tra gli aggiornamenti. Nell'ambito della distribuzione del proxy, Nomad ha impostato i parametri del contratto iniziali definiti nello snippet seguente:

funzione inizializza(uint32 _dominio remoto,indirizzo _aggiornamento,bytes32 _commitRoot,uint256 _optimisticSeconds) inizializzatore pubblico {__NomadBase_initialize(_updater);// imposta le variabili di archiviazioneinserito = 1;dominio remoto = _dominio remoto;commitRoot = _committedRoot;confermaAt[_commitRoot] = 1;ottimisticiSecondi = _ottimisticiSecondi;emetti SetOptimisticTimeout(_optimisticSeconds);}

Notare l'evidenziato confermaA assegnazione della mappa che imposta una voce iniziale per il trusted _commitRoot al valore di 1. La variabile _commitRoot viene fornito come parametro di inizializzazione dal distributore del contratto di Nomad. Vediamo cosa è stato impostato durante l'inizializzazione:

$ cast run 0x99662dacfb4b963479b159fc43c2b4d048562104fe154a4d0c2519ada72e50bf --quick --rpc-url $MAINNET_RPC_URLTracce:[261514] → nuovo UpgradeBeaconProxy@"0x5d94…aeba"├─ [2160] UpgradeBeacon::fallback() [chiamata statica]│   └─ ← 0x0000000000000000000000007f58bb8311db968ab110889f2dfa04ab7e8e831b├─ [163890] Replica::initialize(1635148152, 0xb93d4dbb87b80f0869a5ce0839fb75acdbeb1b77, 0x0000000000000000000000000000000000000000000000000000000000000000, 1800) [delegato]│ ├─ emetti proprietà trasferita (proprietario precedente: 0x0000000000000000000000000000000000000000, nuovo proprietario: 0xa5bd5c661f373256c0ccfbc628fd52de74f9bb55)│ ├─ emetti NewUpdater(oldUpdater: 0x0000000000000000000000000000000000000000, newUpdater: 0xb93d4dbb87b80f0869a5ce0839fb75acdbeb1b77)│ ├─ emetti SetOptimisticTimeout(timeout: 1800)│ └─ ← ()└─ ← 439 byte di codice

Interessante il parametro di inizializzazione _radice impegnata era impostato su 0. Di conseguenza il confermaA mappa ora ha un valore di 1 per una voce 0 che da aprile a questo giorno:

$ cast chiamata 0x5d94309e5a0090b165fa4181519701637b6daeba "confirmAt(bytes32)" 0x0 --rpc-url $MAINNET_RPC_URL0x0000000000000000000000000000000000000000000000000000000000000001

Il 21 giugno 2022, Nomad ha eseguito una serie di aggiornamenti alla sua infrastruttura ponte, inclusa l'implementazione di Replica. Una delle modifiche includeva aggiornamenti alla logica di verifica dei messaggi nel file processi() funzione:

funzione processo(byte di memoria _messaggio) public restituisce (bool _success) {// assicurati che il messaggio fosse destinato a questo dominiobyte29 _m = _messaggio.ref(0);require(_m.destination() == localDomain, "!destination");// assicurati che il messaggio sia stato provatobytes32 _messageHash = _m.keccak();require(acceptableRoot(messages[_messageHash]), "!provato");// controlla la guardia di rientrorequire(inserito == 1, "!reentrant");inserito = 0;// aggiorna lo stato del messaggio come elaboratomessaggi[_messageHash] = LEGACY_STATUS_PROCESSED;// funzione di gestione delle chiamateIMessageRecipient(_m.recipientAddress()).handle(_m.origine(),_m.noce(),_m.mittente(),_m.body().clone());// emette i risultati del processoemit Process(_messageHash, true, "");// ripristina la protezione di rientroinserito = 1;// restituisce veroreturn true;}

Il flusso di verifica del messaggio ora include una chiamata al accettabileRoot() metodo che a sua volta fa riferimento confermaA mappa di cui abbiamo parlato sopra:

funzione radice accettabile(bytes32 _root) visualizzazione pubblica restituisce (bool) {// questa è la compatibilità con le versioni precedenti per i messaggi provati/elaborati// nelle versioni precedentise (_root == LEGACY_STATUS_PROVEN) restituisce true;se (_root == LEGACY_STATUS_PROCESSED) restituisce false;uint256 _time = confermaAt[_root];se (_ora == 0) {return false;}restituisce block.timestamp >= _time;}

La vulnerabilità compare in uno scenario in cui i messaggi fraudolenti non sono presenti nel trusted messaggi[] mappa, vengono inviati direttamente al processi() metodo. In questo scenario messaggi[_messageHash] restituisce un valore null predefinito per voci inesistenti, quindi il accettabileRoot() il metodo è chiamato come segue:

require(acceptableRoot(0), "!provato");

A sua volta, il accettabileRoot() il metodo eseguirà una ricerca contro confermaA[] mappa con un valore nullo come segue:

uint256 _time = confermaAt[0];se (_ora == 0) {return false;}restituisce block.timestamp >= _time;

Come accennato all'inizio di questa sezione, confermaA[] map ha una voce nulla definita risultante accettabileRoot() di ritorno I veri e autorizzare messaggi fraudolenti.

L'exploit sfrutta la vulnerabilità di cui sopra creando un messaggio che induce Nomad Bridge a inviare token archiviati senza un'adeguata autorizzazione. Di seguito è riportato un esempio processi() carico utile in a delle transazioni presentata da 0xb5c5…590e:

0x6265616d000000000000000000000000d3dfd3ede74e0dcebc1aa685e151332857efce2d000013d60065746800000000000000000000000088a69b4e698a4b090df6cf5bd7b2d47325ad30a3006574680000000000000000000000002260fac5e5542a773aa44fbcfedf7c193bc2c59903000000000000000000000000b5c55f76f90cc528b2609109ca14d8d84593590e00000000000000000000000000000000000000000000000000000002540be400e6e85ded018819209cfb948d074cb65de145734b5b0852e4a5db25cac2b8c39a

Il messaggio di replica ha la struttura seguente:

struct Messaggio {uint32 _originDomain,bytes32 _mittente,uint32 _non una volta,uint32 _destinationDomain,bytes32 _destinatario,byte di memoria _messageBody}

Il destinatario specifico _corpo del messaggio contiene dati di transazione che devono essere elaborati dal _destinatario. I destinatari nomadi accettano diversi tipi di transazioni e messaggi, ma ci concentreremo sul tipo di trasferimento:

struct BridgeMessage {dominio uint32;byte32 ID;tipo uint8;bytes32 destinatario;importo uint256;uint256 dettagliHash;}

La decodifica del payload di cui sopra illustra come 0xb5c55f76f90cc528b2609109ca14d8d84593590e sia stato in grado di rubare 100 WBTC inviando un payload appositamente predisposto per bypassare i controlli dei messaggi di Nomad.

Al fine di comprendere meglio la causa principale dell'exploit noi sviluppato un PoC per dimostrarlo prosciugando l'intero saldo del token sul bridge in poche transazioni:

Durante la stesura di un PoC abbiamo trovato curioso che gli aggressori abbiano scelto di estrarre fondi con incrementi minori quando avrebbero potuto drenare l'intero importo in una singola transazione. Ciò è probabilmente dovuto al fatto che gli aggressori non hanno creato messaggi bridge da zero, ma hanno invece riprodotto le transazioni esistenti con indirizzi di ricezione corretti.

Oltre 186 milioni di dollari in token ERC-20 sono stati rubati dal Nomad Bridge tra il 1 agosto 2022 alle 21:32 UTC e il 2 agosto 2022 alle 05:49 UTC. Il volume più alto di token rubati è stato principalmente USDC, seguito da WETH, WBTC e CQT. Entro la prima ora dall'exploit, sono stati rubati solo WBTC e WETH, poi seguiti da molti altri ERC-20.

Fonte: Cruscotto Dune

Nell'analizzare i dati blockchain, vediamo che c'erano vari indirizzi sulle spalle degli sfruttatori originali e che utilizzavano dati di input quasi identici con indirizzi di destinatari modificati per sottrarre lo stesso token per la stessa quantità. Una volta che il contratto WBTC è stato per lo più prosciugato, gli attaccanti hanno poi prosciugato il contratto WETH e così via.

Analizzando ulteriormente i primi attaccanti in blocco 15259101, scopriamo che i due indirizzi iniziali dell'attaccante hanno sfruttato un contratto di supporto per offuscare l'esatto exploit. Sfortunatamente, all'interno dello stesso blocco, diversi indici all'indirizzo di un altro sfruttatore sembrano aver avuto difficoltà a interagire con il contratto di supporto e hanno deciso di aggirarlo e di esporre pubblicamente i dati di input dell'exploit nel processo. Altri indirizzi nello stesso e negli ultimi blocchi hanno quindi seguito l'esempio e hanno utilizzato payload quasi identici per condurre l'exploit.

In seguito allo sfruttamento iniziale, e data la facilità di innescare l'exploit, centinaia di imitatori si sono uniti a un massiccio sfruttamento di un unico contratto. Durante l'analisi dei carichi utili di vari futuri attaccanti, abbiamo scoperto che non solo il riutilizzo degli stessi token veniva colmato e gli stessi importi, ma anche che i fondi venivano costantemente "colmati" da Moonbeam proprio come l'exploit originale.

L'attacco è avvenuto in tre fasi: il test di vulnerabilità il giorno prima dell'attacco, l'exploit iniziale mirato a WBTC archiviato sul bridge e la fase di copycat che ha coinvolto centinaia di indirizzi univoci. Immergiamoci in ciascuno di questi, inclusa la restituzione parziale dei beni rubati.

Per tutto il 31 luglio 2022, bitliq[.]eth è stato riscontrato che attiva la vulnerabilità utilizzando piccole quantità di WBTC e altri token. Ad esempio, il 31-lug-2022 11:19:39 +UTC ha inviato un delle transazioni Vai all’email processi() metodo su blockchain di Ethereum con il seguente payload:

0x617661780000000000000000000000005e5ea959686c73ed32c1bc71892f7f317d13a267000000390065746800000000000000000000000088a69b4e698a4b090df6cf5bd7b2d47325ad30a36176617800000000000000000000000050b7545627a5162f82a992c33b87adc75187b21803000000000000000000000000a8c83b1b30291a3a1a118058b5445cc83041cd9d000000000000000000000000000000000000000000000000000000000000f6088a36a47f8e81af64c44b079c42742190bbb402efb94e91c9515388af4c0669eb

Il carico utile può essere decodificato come segue:

• Catena originaria: “avax”
• Catena di destinazioni: "eth"
• Recipient: a8c83b1b30291a3a1a118058b5445cc83041cd9d (bitliq[.]eth)
• Indirizzo token: 0x50b7545627a5162F82A992c33b87aDc75187B218 (WBTC.e su Avalanche)
• Importo: 0.00062984 BTC

Ciò corrisponde a 0.00062984 BTC delle transazioni inviato al ponte sulla catena delle valanghe.

Il carico utile è stato inviato utilizzando il processi() metodo in contrasto con il più comune provaEProcesso() e non era presente nella mappa dei messaggi[] prima dell'esecuzione nel blocco 15249928 :

$ cast call 0x5d94309e5a0090b165fa4181519701637b6daeba "messages(bytes32)" "bc0f99a3ac1593c73dbbfe9e8dd29c749d8e1791cbe7f3e13d9ffd3ddea57284" --rpc-url $MAINNET_RPC_URL --block 152499280x0000000000000000000000000000000000000000000000000000000000000000

La transazione è riuscita anche senza fornire le prove necessarie innescando la vulnerabilità nel accettabileRoot() metodo fornendogli un valore hash di root 0x0 come illustrato nel debugger di seguito:

Fonte: Tenderly Debugger

Messaggi non presenti nel messaggi[] l'archiviazione può essere convalidata utilizzando il provaEProcesso() metodo; tuttavia, poiché l'indirizzo ha chiamato processi() direttamente hanno attivato la vulnerabilità.

Abbastanza interessante, sembra che bitliq[.]eth stesse probabilmente anche testando il contratto del bridge ERC-20 un'ora prima dell'exploit e avesse superato 0.01 WBTC su Moonbeam. [Tx]

Lo sfruttamento attivo è iniziato il 1 agosto 2022 all'interno dello stesso blocco 15259101 e ha portato al furto combinato di 400 BTC.

Tutte e quattro le transazioni hanno utilizzato payload di exploit identici ad eccezione dell'indirizzo di un destinatario come descritto in Vulnerabilità sezione sopra:

0x6265616d000000000000000000000000d3dfd3ede74e0dcebc1aa685e151332857efce2d000013d60065746800000000000000000000000088a69b4e698a4b090df6cf5bd7b2d47325ad30a3006574680000000000000000000000002260fac5e5542a773aa44fbcfedf7c193bc2c59903000000000000000000000000f57113d8f6ff35747737f026fe0b37d4d7f4277700000000000000000000000000000000000000000000000000000002540be400e6e85ded018819209cfb948d074cb65de145734b5b0852e4a5db25cac2b8c39a

Alcune osservazioni su quanto sopra:

• I primi tre indirizzi sono stati finanziati da Tornado Cash e hanno effettuato attivamente transazioni tra loro, il che indica un singolo gruppo di attori.
• A differenza delle prime due transazioni di exploit, 0xb5c5…590e ed bitliq[.]eth inviato il payload dell'exploit direttamente al contratto e senza l'uso di flashbot per nasconderlo dal mempool pubblico.
• bitliq[.]eth ha riprodotto una precedente transazione di exploit nello stesso blocco 15259101 di 0xb5c5…590e indicando una conoscenza precedente dell'exploit o l'apprendimento 0xb1fe…ae28 dal mempool.
• Tutte e quattro le transazioni utilizzavano payload identici, ciascuna rubando 100 WBTC alla volta.

In totale, l'88% degli indirizzi che hanno condotto gli exploit sono stati identificati come imitatori e insieme hanno rubato circa 88 milioni di dollari in token dal bridge.

La maggior parte dei copycat utilizzava una variazione dell'exploit originale modificando semplicemente token, importi e indirizzi dei destinatari mirati. Possiamo classificare i payload univoci raggruppandoli in base ai contratti che chiamano e al metodo univoco 4byte invocato come illustrato di seguito:

Sulla base della nostra analisi, oltre l'88% degli indirizzi univoci ha chiamato il contratto vulnerabile utilizzando direttamente il 928bc4b2 identificatore di funzione che corrisponde a processo (byte) metodo utilizzato nell'exploit originale. I restanti effettuano la stessa chiamata utilizzando contratti di intermediazione come 1cff79cd qual è eseguire (indirizzo, byte) metodo, batching multiplo processi() transazioni insieme e altre variazioni minori.

Dopo il compromesso iniziale, gli sfruttatori originali hanno dovuto competere contro centinaia di imitatori:

Mentre la maggior parte dei token di valore è stata rivendicata solo da due degli indirizzi originali degli sfruttatori, centinaia di altri sono stati in grado di rivendicare parte delle proprietà di Bridge:

Di seguito è riportato un grafico che mostra i token rubati nel tempo in USD. Diventa evidente che gli sfruttatori stavano andando segno per segno mentre stavano prosciugando il ponte.

Ad oggi, il 12% rubato dal contratto Nomad Bridge è stato restituito, compresi i resi parziali. La maggior parte dei resi è avvenuta nelle ore successive alla richiesta di Nomad Bridge di inviare fondi all'indirizzo di recupero il 3 agosto 2022. [Tweet, Tx]

Di seguito una ripartizione dei fondi restituiti, che include ETH e vari altri token, alcuni dei quali non sono mai stati nemmeno sul ponte:

I fondi continuano a essere rispediti all'indirizzo di recupero del ponte, anche se negli ultimi giorni più lentamente rispetto a quando l'indirizzo è stato inizialmente pubblicato:

La maggior parte dei fondi restituiti sembra essere in USDC, seguita da DAI, CQT, WETH e WBTC. Questo è notevolmente diverso dalla ripartizione dei token sfruttati. Il motivo è che gli sfruttatori originali iniziali hanno prosciugato principalmente il ponte di WBTC e WETH. A differenza degli sfruttatori della fase successiva, questi sfruttatori spostavano i fondi senza l'intenzione di restituirli.

È interessante notare che uno degli sfruttatori originali, bitliq[.]eth, ha restituito solo 100 ETH al contratto bridge, ma ha iniziato a incassare il resto dei proventi tramite renBTC e a bruciarlo in cambio di BTC.

Classificazione degli "sfruttatori"

Durante la valutazione degli sfruttatori di Nomad Bridge, gli aggressori sono stati classificati nei seguenti bucket:

• Cappelli neri: quelli che non restituiscono fondi e continuano a spostarli in avanti.
• Cappelli bianchi: quelli che rimandano completamente i fondi agli indirizzi di recupero
• Si prega di notare che mentre stiamo usando il termine cappello bianco a scopo esplicativo qui, il prelievo iniziale dei fondi non è stato autorizzato e non è un'attività che vorremmo approvare.
• Cappelli grigi: quelli che rimandano parzialmente i fondi agli indirizzi di recupero.
• Incognite sconosciute: quelle che devono ancora spostare fondi.

Circa il 24% dei fondi continua a rimanere intatto. Sospettiamo che si tratti o di aggressori che aspettano la fine del caldo o di scaltri degens che aspettano una taglia da Nomad. Tuttavia, il maggior volume di fondi è andato avanti. Al 5 agosto, stimiamo che circa il 64% sia andato avanti.

Per rimanere aggiornato con le ultime in termini di fondi restituiti, controlla questo cruscotto.

Approfondire i Blackhat

Di quei fondi che sono andati avanti, abbiamo identificato diversi grandi anelli di indirizzi che mescolano tutti i fondi. In particolare, un gruppo di indirizzi sembra aver accumulato oltre $ 62 milioni di volume. È interessante notare che un indirizzo all'interno di questo cluster è stato il primo indirizzo ad aver condotto l'exploit [hash tx].

Ad oggi, vediamo principalmente questi anelli seguendo uno dei modelli seguenti:

• Attività del bot MEV
• Mescolate e tenete premuto per aspettare che il calore si spenga
• Scambiare fondi ed eventualmente restituire un importo parziale di fondi all'indirizzo di recupero
• Scambiare fondi e investire in progetti DeFi o incassare in vari CEX
• Spostamento di fondi tramite Tornado Cash

Di seguito è riportato un esempio di come alcuni indirizzi hanno iniziato a trasferire fondi tramite Tornado Cash, che dall'8 agosto 2022 è un'entità sanzionata.

Attenzione alle truffe:

Diversi cappelli bianchi hanno già restituito oltre il 10% dei fondi al contratto bridge. Tuttavia, questo non è stato senza intoppi.

In origine, il team Nomad ha pubblicato su entrambi Twitter e la blockchain l'indirizzo Ethereum a cui inviare i fondi sfruttati

Tuttavia, i truffatori hanno abilmente seguito l'esempio e hanno creato vari domini ENS fraudolenti per fingere di essere il team Nomad e hanno chiesto di inviare fondi a indirizzi vanity con gli stessi caratteri iniziali dell'indirizzo di recupero legittimo.

Ad esempio, di seguito è riportato un messaggio inviato da uno dei truffatori. Nota l'indirizzo di recupero fraudolento, il dominio ENS e anche lo sconto del 10%. Da allora Nomad ha offerto che i cappelli bianchi rivendicano il 10% dei proventi sfruttati. [Tx]

Sebbene la maggior parte dei contratti sia controllata in modo approfondito da vari revisori blockchain, i contratti possono ancora contenere vulnerabilità ancora da scoprire. Anche se potresti voler fornire liquidità a un protocollo particolare o fare un ponte sui fondi, ecco alcuni suggerimenti da tenere a mente:

• Quando fornisci liquidità, non conservare tutti i tuoi fondi su un protocollo o archiviati nel bridge.
• Assicurati di rivedere e revocare regolarmente tutte le approvazioni contrattuali di cui non hai attivamente bisogno.
• Rimani aggiornato con i feed di intelligence sulla sicurezza per tenere traccia dei protocolli in cui hai investito.

Coinbase si impegna a migliorare la nostra sicurezza e la sicurezza del settore in generale, oltre a proteggere i nostri utenti. Riteniamo che exploit come questi possano essere mitigati e in definitiva prevenuti. Oltre a rendere le basi di codice open source per la revisione da parte del pubblico, consigliamo frequenti controlli del protocollo, implementa programmi di ricompense dei bug e collaboriamo attivamente con i ricercatori della sicurezza. Sebbene questo exploit sia stato un'esperienza di apprendimento difficile, riteniamo che capire come si è verificato l'exploit possa solo aiutare a far maturare ulteriormente la nostra giovane industria.