Vai al contenuto
Financial Context Wiki

Attacco alla governance

Un attacco alla governance ottiene potere di voto o esecuzione sufficiente per approvare modifiche dannose tramite il percorso autorizzato.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono causare perdite.

Risposta diretta

Un attacco alla governance ottiene potere sufficiente per votare, proporre, annullare o eseguire e induce il protocollo a compiere un’azione dannosa tramite il percorso di governance autorizzato. Le chiamate possono superare ogni controllo degli smart contract. Il difetto consiste nel rendere il controllo troppo economico, rapido o privo di responsabilità rispetto al valore posto sotto quel controllo.

Il potere di voto può provenire da token propri, voti delegati, token presi a prestito, elettori corrotti, chiavi compromesse o ruoli privilegiati del Governor e del timelock. I checkpoint storici impediscono allo stesso saldo di votare di nuovo dopo un trasferimento e possono bloccare prestiti successivi allo snapshot. Non fermano voti ottenuti prima, deleghe concentrate, quorum deboli o un esecutore compromesso.

Non ogni proposta impopolare è un attacco: la governance serve a cambiare le regole. Occorre capire se un soggetto ha ottenuto controllo sproporzionato o temporaneo, ha nascosto o travisato l’effetto eseguibile oppure ha superato un limite di autorità dichiarato. Vanno esaminati le chiamate effettive, il percorso meno costoso verso il potere decisivo, il tempo di reazione e il massimo valore o controllo raggiungibile dopo l’esecuzione.

Come funziona

  1. Tracciare l’autorità dall’asset di voto, attraverso deleghe e checkpoint, fino a Governor, timelock, amministratore del proxy, tesoreria, ruoli di emergenza e contratti di destinazione. L’interfaccia di governance non è il grafo dei permessi.
  2. Fissare rete, indirizzi, versioni dell’implementazione, modalità dell’orologio, snapshot, soglia di proposta, calcolo del quorum, regola di conteggio, ritardo e periodo di voto, ritardo della coda, scadenza, diritti di annullamento e ruoli di esecuzione.
  3. Ricostruire il potere di voto allo snapshot esatto con letture storiche come getPastVotes. Raggruppare indirizzi controllati o coordinati dallo stesso soggetto e separare il saldo di token dal peso delegato.
  4. Decodificare ogni azione: targets, values, calldatas e descriptionHash. Risolvere proxy e selettori, esaminare chiamate in batch e confrontare il payload eseguibile con la descrizione leggibile.
  5. Riprodurre su un fork creazione, voto, inserimento in coda ed esecuzione. Confrontare prima e dopo saldi, proprietà, ruoli, autorizzazioni, implementazioni, impostazioni degli oracoli, parametri delle garanzie e funzioni appena raggiungibili.
  6. Valutare il percorso di controllo meno costoso tra acquisti spot, mercati di prestito, liquidità flash, prestiti fuori borsa, delega, incentivi di voto, coperture con derivati, compromissione delle chiavi e cattura di ruoli privilegiati. Includere commissioni, slippage, garanzie, perdite di chiusura e tempo di immobilizzo del capitale.
  7. Provare la risposta. Verificare chi può annullare o sospendere, quali prove servono, se l’azione rientra nel ritardo, dove gli utenti ricevono avvisi ufficiali e come riprendere la governance senza lasciare una chiave di emergenza illimitata.

Un Governor di token tipico attraversa proposta, ritardo, snapshot, voto, approvazione o sconfitta, coda, timelock ed esecuzione. Le regole esatte dipendono dall’implementazione. Con checkpoint simili a ERC-5805 è possibile interrogare il peso delegato in un momento passato; l’orologio può usare blocchi o timestamp. Occorre usare l’orologio e la configurazione distribuiti, senza presumere che la durata mostrata o il saldo siano vincolanti.

Il timelock crea un periodo minimo di preavviso, ma non giudica l’intento né rende sicuro il payload. Anche i ruoli di proponente, esecutore, annullatore e amministratore sono critici. Se un amministratore esterno può aggirare il ritardo, il timelock non è l’autorità finale. Se nessuno può annullare un’azione dannosa in coda, rilevarla non ne impedisce l’esecuzione.

Esempi calcolati

  • Cattura con bassa partecipazione. Un protocollo ha 100 million token totali e 40 million in circolazione. Una proposta richiede 2 million voti partecipanti, più favorevoli che contrari e un timelock di 6-hour. Un soggetto compra 1.2 million voti e ne riceve 1 million delegati. I contrari sono 0.8 million, quindi i suoi 2.2 million voti favorevoli approvano una chiamata capace di trasferire 15 million USDC dalla tesoreria. Controlla 2.2 / 100 = 2.2% dell’offerta totale e 2.2 / 40 = 5.5% di quella circolante, ma 2.2 / 3.0 = 73.3% dei voti espressi. I parametri decisivi sono partecipazione, delega, quorum, autorità del payload e ritardo, non lo slogan 51%.
  • Confine dello snapshot. Se il peso viene letto dal saldo attuale e l’esecuzione è immediata, una transazione può prendere token, votare, eseguire e restituirli. Leggere il peso storico immutabile di un momento precedente blocca questo percorso atomico. Resta possibile usare capitale preso o delegato prima dello snapshot; il ritardo della proposta e la finestra osservabile di acquisizione rimangono quindi difese essenziali.
  • Beanstalk il 17 aprile 2022. Beanstalk Farms ha riferito che un aggressore usò un flash loan per sfruttare la governance del protocollo e sottrasse circa $77 million in asset di utenti diversi da Beanstalk. Il caso mostra che la liquidità flash finanzia l’attacco, mentre la debolezza decisiva è consentire a un potere economico temporaneo di raggiungere preziosi permessi di esecuzione.

Rischi e controlli

  • Potere effettivo concentrato. Misurare delegati ed entità coordinate, non solo indirizzi. Pubblicare quota dei principali delegati, distribuzione della partecipazione e dipendenze da fondazioni, custodi, market maker e rappresentanti.
  • Regole deboli per proposta e quorum. Confrontare le soglie con potere attivo, offerta mutuabile ed esposizione della tesoreria. Separare i requisiti per parametri ordinari e aggiornamenti o trasferimenti ad alto impatto.
  • Snapshot non sicuri. Usare checkpoint storici immutabili e un orologio comune a token e Governor. Lasciare sufficiente ritardo prima dello snapshot per rendere visibili accumuli o deleghe anomali.
  • Voto tardivo o a sorpresa. Valutare un’estensione minima quando il quorum arriva vicino alla scadenza e monitorare grandi cambi di delega per tutto il ciclo.
  • Payload opachi. Pubblicare chiamate decodificate e simulazioni indipendenti. Separare azioni rischiose non correlate affinché una voce innocua non nasconda un cambio di amministratore o un trasferimento.
  • Ritardo di esecuzione insufficiente. Adeguare il timelock all’impatto e pubblicare le operazioni in coda. Il ritardo deve consentire revisione, allerta, annullamento o pausa e un’uscita credibile per gli utenti.
  • Ruoli di emergenza eccessivi. Limitare i guardian per funzione, valore, durata e criterio di revisione. Rendere noti membri, soglie, rotazione, prove richieste e processi di rimozione e ripresa.
  • Percorsi di aggiornamento non verificati. Seguire amministratori di proxy, beacon, inizializzatori, deployment metamorfici e contratti aggiornabili dopo aver ricevuto autorità.
  • Rischio di esecuzione tra reti. Autenticare Governor e messaggio di origine, impedire replay, limitare le funzioni di destinazione, aggiungere ritardi locali e definire il comportamento durante guasti o sospensioni del bridge.
  • Monitoraggio inadeguato. Avvisare su creazione di proposte, concentrazione dei voti, cambi di quorum, coda e annullamento, cambi di stato decodificati, upgrade, assegnazioni di ruoli, autorizzazioni e deflussi dalla tesoreria.
  • Risposta agli incidenti inefficace. Esercitare proposte dannose, perdita dei firmatari, compromissione del frontend, interruzione del bridge e pause errate. Registrare chi decide, comunica, firma, verifica e ripristina in sicurezza.
  • Valore a rischio illimitato. Limitare trasferimenti singoli e cumulativi, portata degli upgrade, emissione, modifiche alle garanzie e autorizzazioni. Un voto approvato non deve concedere automaticamente autorità illimitata.

Il risultato deve essere un registro di controllo riproducibile: ogni azione privilegiata, il controllore, voti o chiavi richiesti, primo momento di esecuzione, percorso di annullamento, fonte di monitoraggio e massimo valore raggiungibile. Ricalcolarlo dopo upgrade, distribuzioni di token, cambi di delega, migrazioni di bridge o variazioni rilevanti di liquidità e partecipazione.

Errori comuni

  • “L’aggressore deve possedere il 51% dell’offerta totale.” La maggior parte dei sistemi dipende da voti delegati o partecipanti, quorum e regola di approvazione. Il controllo decisivo può costare molto meno della metà dell’offerta.
  • “Gli snapshot eliminano gli attacchi alla governance.” Impediscono certi riusi di voti o prestiti all’ultimo momento, non prestiti precedenti, acquisti, concentrazione delle deleghe, corruzione o compromissione di chiavi privilegiate.
  • “Un voto on-chain approvato dimostra legittimità.” Dimostra solo che le condizioni del codice sono state soddisfatte, non che descrizione e payload coincidano o che l’esito sia sicuro, equo e conforme agli impegni pubblici.
  • “Un timelock più lungo è sempre più sicuro.” Serve solo se consente monitoraggio, analisi, annullamento o pausa, comunicazione e uscita. Un ritardo eccessivo può ostacolare la manutenzione urgente.
  • “Aggiungere un consiglio di sicurezza risolve il rischio.” Può accelerare la risposta, ma crea un altro percorso di controllo. Autorità, responsabilità, rimozione e guasti devono entrare nello stesso modello di minaccia.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...