L'Arbitrum Security Council ha spostato 8.425 ETH e 74,6 milioni di ARB da un wallet collegato a un exploit verso un indirizzo che termina con 0DA0 durante un'azione di emergenza il 30 ottobre. L'operazione ha utilizzato un override dell'Inbox che permetteva alla rete di accettare transazioni apparentemente provenienti dall'exploiter, senza utilizzare la chiave privata dell'exploiter.

Secondo la divulgazione dell'azione di emergenza del Security Council, l'operazione è stata eseguita alle 8:08 ora di Hong Kong. Il council ha dichiarato che i fondi o le applicazioni di nessun altro utente sono stati interessati. Le stime della stampa valutano gli asset bloccati quasi 30 milioni di dollari, a confronto con i circa 6,3 miliardi di dollari che Binance dichiara siano stati prelevati dai suoi wallet.

I fondi possono lasciare l'indirizzo 0DA0 solo tramite un voto di governance di ArbitrumDAO. L'azione ha quindi coinvolto tre poteri distinti: il council non poteva firmare transazioni per il wallet dell'exploiter, ma poteva modificare il modo in cui Arbitrum One accetta le transazioni. Decidere chi riceve infine gli asset rimane responsabilità della DAO e, come ha dimostrato un precedente blocco, può coinvolgere anche un tribunale statunitense.

Come ha funzionato l'override dell'Inbox

I messaggi da Ethereum arrivano ad Arbitrum One attraverso il contratto Inbox sull'Ethereum mainnet. In condizioni normali, una transazione cross-chain trasporta l'identità del proprio mittente, impedendo a un account Ethereum di utilizzare il percorso standard per agire come un altro account su Arbitrum.

Per l'azione di emergenza, il council ha aggiornato l'Inbox con una funzione chiamata sendUnsignedTransactionOverride. La divulgazione ha descritto la funzione come l'aggiunta della capacità di "impersonare il mittente della transazione". Due messaggi creati con la funzione indicavano l'indirizzo dell'exploit come mittente e indirizzavano i suoi ETH e ARB verso l'indirizzo di deposito. Il council ha poi ripristinato il codice originale dell'Inbox.

L'aggiornamento, i trasferimenti e il ripristino sono avvenuti tutti all'interno di una singola transazione Ethereum alle 00:08:35 UTC. Arbitrum One ha elaborato il risultato circa 10 minuti dopo, e il trasferimento di ARB si è concluso alle 00:18:20 UTC. La transazione pertinente è registrata su Etherscan, mentre la corrispondente transazione Arbitrum appare su Arbiscan.

Combinare l'aggiornamento e il ripristino in una singola transazione può nascondere la modifica ai sistemi di monitoraggio che confrontano l'indirizzo di implementazione dell'Inbox prima e dopo ogni blocco. Un tale osservatore vedrebbe la stessa implementazione su entrambi i lati della transazione. La società di sicurezza Zealynx ha segnalato questo problema in una ricostruzione tecnica pubblicata tramite Ethereum Magicians.

L'aggiornamento rimane visibile negli eventi di upgrade del contratto e nella traccia di esecuzione della transazione. Nessuna crittografia è stata violata: la chiave privata dell'attaccante è rimasta sotto il controllo dell'attaccante, mentre il council ha modificato quale mittente la rete avrebbe accettato.

Cosa rivela la transazione ARB

Il trasferimento di ARB in sé appare simile a una transazione ordinaria da wallet. L'indirizzo dell'exploit compare nel campo "from", e l'indirizzo che termina con 0DA0 compare nel campo "to". Il dettaglio significativo è il tipo di transazione, registrato come 101, ovvero 0x65. Arbitrum utilizza quel tipo per una transazione non firmata entrata da Ethereum.

L'indirizzo dell'exploit non ha prodotto una firma perché questo percorso non la richiedeva. Di conseguenza, gli strumenti che interpretano ogni trasferimento in uscita come una decisione del proprietario del wallet potrebbero attribuire erroneamente il movimento all'exploiter. Servizi di etichettatura dei wallet, sistemi di screening per la compliance e riepiloghi degli explorer potrebbero tutti registrare l'exploiter come autore dello spostamento dei fondi, anche se il council ha avviato l'azione.

Dal punto di vista del contratto del token, l'evento appariva anch'esso ordinario. Zealynx ha notato che il contratto ARB ha registrato un trasferimento standard e non aveva modo di distinguere l'azione del council da un normale trasferimento. Il tipo di transazione da solo non è conclusivo, perché gli account Ethereum utilizzano legittimamente transazioni non firmate per raggiungere Arbitrum dal mainnet. La prova distintiva è il messaggio Ethereum alla base della transazione e se l'implementazione dell'Inbox è cambiata durante quella stessa transazione.

Lo stesso meccanismo è stato usato in aprile

Il blocco legato a Binance ha seguito un meccanismo utilizzato il 21 aprile, quando il council ha trasferito 30.766 ETH dall'exploiter di KelpDAO dopo un attacco al percorso bridge rsETH di KelpDAO. Quell'azione ha utilizzato la stessa funzione e lo stesso indirizzo di deposito, secondo la divulgazione dell'azione di emergenza di aprile.

L'autorità deriva dalla costituzione di ArbitrumDAO, che conferisce alla DAO e al Security Council privilegi di chain-owner su Arbitrum One. Tali privilegi includono il controllo sugli upgrade dei contratti principali e sulle impostazioni di sistema. Nove dei 12 membri del council possono approvare un'azione di emergenza senza ritardi.

La costituzione limita tale autorità alle vere emergenze di sicurezza e richiede successivamente un rapporto di trasparenza. ArbitrumDAO può anche ridurre o rimuovere i poteri tramite una proposta costituzionale.

I blocchi delle stablecoin operano a un livello diverso. Circle e Ripple hanno bloccato i token collegati al furto di Binance utilizzando controlli integrati nei rispettivi asset. Coindoo ha riferito su come l'attaccante abbia aggirato quei controlli prendendo a prestito ETH contro stablecoin rubate. ETH non ha un emittente che possa metterlo in blacklist, ma gli ETH su Arbitrum One sono registrati in un ledger il cui sistema sottostante il council può aggiornare. La divulgazione di ottobre non specifica se gli ETH bloccati provenissero da quei prestiti.

L'azione di aprile ha suscitato un dibattito sull'ambito della capacità di impersonificazione. Robby Greenfield di Tokedex ha scritto che essa non era "limitata al recupero". Il delegate MconnectDAO ha chiesto al council di pubblicare una politica sulle azioni di emergenza che definisca quando può bypassare la governance. Il delegate deakeegroup ha assunto la posizione opposta, sostenendo che poteri di emergenza pre-autorizzati e con ambito ristretto erano preferibili sia all'assenza di un percorso di emergenza sia all'affidamento su chiavi amministrative senza restrizioni e senza accountability. L'11 ottobre, un partecipante alla stessa discussione chiedeva ancora se il lavoro su tale politica fosse iniziato.

Per chi detiene asset su Arbitrum One, l'episodio separa due domande: chi controlla la chiave privata, e chi può modificare le regole sotto cui quella chiave opera. Su Arbitrum One, quest'ultimo potere riposa su nove dei 12 firmatari del council, nei limiti della costituzione. Le catene costruite con la tecnologia Arbitrum hanno risposte separate perché ogni catena ha i propri amministratori.

Spostare i fondi richiede un altro voto

La divulgazione di ottobre non ha identificato il destinatario finale. Ha solo affermato che sarebbe stato necessario un voto di governance per spostare gli asset e che il processo era in coordinamento con le parti interessate. Il recupero di aprile fornisce un esempio di come può funzionare tale processo.

Il 25 aprile, Aave Labs, KelpDAO, LayerZero, EtherFi e Compound hanno pubblicato una Constitutional AIP. La proposta indicava un multisig di recupero come destinatario, collegava gli ETH al ripristino della copertura di rsETH e impegnava Aave Labs a indemnizzare l'Arbitrum Foundation, Offchain Labs e i membri del council.

La proposta prevedeva il seguente calendario:

• Discussione nel forum: una settimana
• Temperature check su Snapshot: una settimana
• Ritardo dopo la presentazione onchain: tre giorni
• Voto onchain: 14 giorni, estendibili a 16
• Periodo di attesa Arbitrum: otto giorni
• Finalizzazione del messaggio da Arbitrum a Ethereum: tipicamente almeno una settimana
• Periodo di attesa Ethereum: tre giorni

Gli autori stimavano che il processo avrebbe richiesto circa 49 giorni dalla pubblicazione all'esecuzione.

Successivamente un tribunale ha modificato il destinatario proposto. I querelanti nel caso Kim v. Democratic People's Republic of Korea, titolari di una sentenza statunitense non saldata contro la Corea del Nord, avevano notificato un'avvertenza di restrizione ad "Arbitrum DAO". Un ordine federale depositato l'8 maggio consentiva un voto onchain per inviare gli ETH bloccati a un wallet controllato da Aave LLC. Esso vincolava inoltre Aave LLC alla restrizione una volta ricevuti i fondi e riservava ogni altra questione relativa agli asset.

La proposta è stata emendata per indicare Aave LLC come destinatario ed è apparsa tra i voti onchain attivi di Arbitrum entro il 26 maggio, secondo il riepilogo di governance. Durante quel dibattito, il delegate DZack23 ha scritto che anche eliminando le fasi di discussione e temperature check ne resterebbero almeno 35. A suo avviso, utilizzare un'altra azione di emergenza per accelerare un rilascio violerebbe la costituzione, perché la velocità di un recupero non è in sé un'emergenza di sicurezza.

I fondi di Binance presentano un'attribuzione simile a quella associata agli ETH di KelpDAO. TRM Labs e Chainalysis hanno collegato il furto di Binance a hacker nordcoreani, come riferito da BleepingComputer. Binance ha dichiarato che coprirà le perdite dei clienti con propri fondi, rendendo il richiedente in questo caso un singolo exchange anziché la coalizione di protocolli coinvolta nel recupero di aprile.

I prossimi passi sarebbero visibili in tre documenti: una proposta di rilascio sul forum di governance di Arbitrum che indichi un destinatario, il rapporto di trasparenza richiesto dalla costituzione per l'azione di ottobre, e qualsiasi deposito giudiziario che identifichi il saldo detenuto all'indirizzo 0DA0, che è elencato su Arbiscan. La call di governance aperta di Arbitrum del 3 novembre è stata la prima discussione di proposta programmata dopo il blocco. Se il rilascio segue il percorso di aprile, tale calendario stabilirebbe il momento più precoce in cui i fondi potrebbero muoversi, mentre un'avvertenza di restrizione potrebbe modificare il destinatario prima di allora.