I client Ethereum correggono una vulnerabilità che potrebbe reindirizzare le ricompense ETH

Gli sviluppatori dei client Ethereum Teku e Besu hanno rilasciato aggiornamenti di sicurezza per affrontare una vulnerabilità dei certificati che potrebbe consentire agli attaccanti di impersonare i servizi utilizzati dai validatori e potenzialmente reindirizzare le loro ricompense di blocco.

Riepilogo

• I client Ethereum Teku e Besu hanno rilasciato aggiornamenti di sicurezza dopo che è stata trovata una vulnerabilità nei certificati che potrebbe consentire agli attaccanti di reindirizzare le ricompense di blocco dei validatori ai propri indirizzi.
• La vulnerabilità è originata da chiavi crittografiche deboli associate a otto autorità di certificazione gestite dalla società indiana eMudhra, che potrebbero consentire agli attaccanti di creare certificati fraudolenti.
• Teku ha avvertito che gli attaccanti potrebbero impersonare servizi esterni utilizzati dai validatori Ethereum e manipolare le proposte di blocco o ottenere firme sensibili dei validatori in determinate configurazioni.
• Le configurazioni predefinite della mainnet di Teku non sono state interessate e gli sviluppatori hanno confermato che non sono stati segnalati sfruttamenti della vulnerabilità.
• Gli operatori che utilizzano installazioni autonome di Teku o Besu devono aggiornare separatamente i propri ambienti Java, poiché le ultime correzioni dell'immagine Docker non aggiornano automaticamente i certificati Java installati localmente.

Secondo gli avvisi di sicurezza che accompagnano i rilasci, il problema è originato da chiavi di autorità di certificazione compromesse appartenenti al fornitore indiano di certificati digitali eMudhra, che ha lasciato alcune configurazioni dei nodi Ethereum esposte a connessioni HTTPS contraffatte.

Teku ha rilasciato la versione 26.10.3 il 27 ottobre, mentre Besu ha introdotto la versione 26.10.2 un giorno prima. Entrambi gli aggiornamenti rimuovono la fiducia nei certificati eMudhra compromessi dalle loro immagini Docker, che gli operatori utilizzano per distribuire e far funzionare il software del nodo Ethereum.

La vulnerabilità potrebbe influenzare i validatori che si affidano a servizi esterni per firmare transazioni, comunicare con i beacon node o ricevere informazioni sulla costruzione dei blocchi. Un attaccante dovrebbe intercettare una connessione interessata e presentare un certificato contraffatto che il software del validatore accetta come legittimo.

Gli sviluppatori di Teku hanno confermato che le configurazioni predefinite della mainnet non sono state interessate e hanno dichiarato che non ci sono stati sfruttamenti segnalati della vulnerabilità.

Vulnerabilità di sicurezza di Ethereum rintracciata ai certificati compromessi di eMudhra

Il problema di sicurezza è iniziato con un errore crittografico che coinvolgeva otto autorità di certificazione intermedie gestite da eMudhra, le cui chiavi private sono state trovate generate utilizzando una casualità insufficiente.

I ricercatori hanno identificato il problema il 17 ottobre, scoprendo che le chiavi private potevano essere recuperate matematicamente dalle informazioni disponibili nei certificati pubblici.

Secondo un avviso di sicurezza del 26 ottobre di Microsoft, sei dei certificati interessati erano utilizzati per proteggere le connessioni internet, mentre gli altri due erano associati alla firma del codice.

Le chiavi compromesse potrebbero consentire a qualcuno di creare certificati che apparivano genuini per le applicazioni che continuavano a fidarsi delle autorità di certificazione compromesse.

eMudhra ha revocato i certificati intermedi interessati il 18 ottobre, mentre i fornitori di tecnologia hanno iniziato a rimuovere la fiducia nelle catene di certificati compromesse dai loro software.

Microsoft ha successivamente bloccato le autorità di certificazione compromesse tramite un aggiornamento di sicurezza di Windows il 20 ottobre e ha rilasciato un altro aggiornamento il 26 ottobre per rimuovere sette certificati associati dalla sua lista di fiducia.

Tuttavia, il problema rimaneva rilevante per Ethereum perché Teku e Besu utilizzano Java, la cui validazione dei certificati non controlla lo stato di revoca per impostazione predefinita.

Di conseguenza, le installazioni Java interessate potrebbero continuare ad accettare certificati associati alle autorità compromesse anche dopo la loro revoca.

Come gli attaccanti potrebbero reindirizzare le ricompense dei validatori Ethereum

L'avviso di sicurezza di Teku ha identificato diversi possibili scenari di attacco che coinvolgono i validatori che comunicano con servizi esterni attraverso connessioni HTTPS.

Uno scenario prevede un attaccante che si spaccia per un nodo beacon remoto utilizzato da un validatore per coordinare i propri compiti su Ethereum.

Se l'attaccante riesce a intercettare la connessione e presenta un certificato contraffatto, il validatore potrebbe ricevere informazioni manipolate riguardo al blocco che stava preparando per la proposta.

Secondo Teku, un attacco di questo tipo potrebbe portare un validatore a proporre un blocco che dirige le commissioni di transazione a un indirizzo controllato dall'attaccante.

L'avviso ha identificato i servizi di firma esterni come un altro componente potenzialmente esposto. Questi servizi detengono le chiavi di firma del validatore separatamente dal software principale del nodo e forniscono firme su richiesta.

Un attaccante che si spaccia per un firmatario esterno potrebbe potenzialmente ottenere firme associate alle uscite dei validatori, a seconda della configurazione e delle protezioni disponibili.

Teku ha classificato questo scenario come particolarmente grave, sebbene le configurazioni che utilizzano l'autenticazione TLS mutua potrebbero limitare le conseguenze a un attacco di negazione del servizio.

Altre connessioni potenzialmente interessate includono client di esecuzione, costruttori di blocchi, relay e servizi utilizzati per recuperare informazioni sulla configurazione dei validatori.

La vulnerabilità non ha colpito i protocolli di rete peer-to-peer sottostanti di Ethereum, che non si basano sulle autorità di certificazione compromesse.

Teku e Besu rilasciano correzioni per i nodi Ethereum interessati

A seguito della divulgazione, Teku ha rilasciato la versione 26.10.3 per rimuovere quattro radici di certificato dalle sue immagini Docker, inclusi emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 e AAA Certificate Services.

Besu ha introdotto le stesse rimozioni di certificato nella versione 26.10.2, affrontando il rischio per gli operatori che utilizzano le sue immagini Docker aggiornate.

Tuttavia, i rilasci non aggiornano automaticamente le installazioni di Java mantenute separatamente dagli operatori di nodo.

Gli utenti che eseguono Teku o Besu tramite distribuzioni binarie autonome devono controllare il loro runtime Java installato e aggiornare i certificati di fiducia dove necessario.

Teku ha avvertito che gli operatori che utilizzano ancora Java 26 dovranno migrare a Java 25 poiché la prima versione ha raggiunto la fine della vita e non riceverà la build patch necessaria.

L'avviso ha ulteriormente identificato alcune configurazioni di testnet come potenzialmente esposte, inclusi i setup che scaricano il loro stato iniziale della blockchain tramite HTTPS.

Gli aggiornamenti di sicurezza seguono altre recenti preoccupazioni riguardanti l'infrastruttura dei validatori di Ethereum. All'inizio di questo mese, crypto.news ha riportato che MetaMask aveva iniziato a uscire dai validatori interessati a seguito di un incidente di sicurezza dell'infrastruttura separato divulgato il 30 settembre.

Più recentemente, gli sviluppatori di Ethereum hanno corretto un difetto nel deposito dei validatori nell'imminente aggiornamento Glamsterdam dopo che i ricercatori hanno identificato uno scenario in cui gli account dei costruttori potrebbero ricevere ETH destinato ai validatori.

L'aggiornamento Glamsterdam ha affrontato separatamente dei ritardi dopo che gli sviluppatori hanno posticipato l'attivazione della testnet Hoodi per indagare su preoccupazioni di compatibilità dei contratti intelligenti riguardanti l'EIP-8037.

Il rinvio del 26 ottobre ha rimosso l'attivazione programmata sia delle modifiche di esecuzione di Amsterdam che delle modifiche di consenso di Gloas, insieme a un aumento proposto del limite di gas di Hoodi a 200 milioni. Gli sviluppatori di Ethereum non hanno annunciato una nuova data di attivazione.

Questo contenuto è fornito a solo scopo informativo generale e non costituisce consulenza finanziaria, di investimento, legale o fiscale. Qualsiasi evento, ricompensa, promozione online o informazione correlata menzionata nel presente documento non deve essere considerata una raccomandazione, una sollecitazione o un invito ad acquistare, vendere, fare trading o altrimenti negoziare criptovalute. Le criptovalute sono altamente volatili e possono comportare perdite. La disponibilità dei servizi, dei prodotti e degli eventi correlati di WEEX può variare a seconda della regione. È tua responsabilità assicurarti che la tua partecipazione sia conforme alle leggi e ai regolamenti locali applicabili.