MetaMask ha confermato che un attacker ha brevemente dirottato le ricompense del execution layer di alcuni validator Ethereum che utilizzano il suo servizio di staking, sottraendo circa 0,385 ETH prima che la modifica venisse rilevata e annullata lo stesso giorno. I dettagli sono emersi in un aggiornamento sull'incidente del 5 novembre, l'ultima voce di un incidente di sicurezza identificato per la prima volta dall'azienda il 28 settembre. Sebbene l'importo dirottato fosse contenuto, l'episodio mette in luce un aspetto spesso trascurato del design di Ethereum: la distinzione tra dove va a finire l'ETH in staking di un validator e dove viene inviato il suo flusso continuo di ricompense.

Cosa Ha Rivelato Finora MetaMask

Secondo l'aggiornamento, l'attacker ha ottenuto accesso non autorizzato a una parte dell'infrastruttura alla base di MetaMask Staking, dove gli indirizzi che raccolgono le ricompense del execution layer dei validator erano archiviati in modo centralizzato. L'intruso ha modificato quegli indirizzi per un certo numero di validator. MetaMask afferma di aver rilevato e corretto la modifica lo stesso giorno, dopo che circa 0,385 ETH di ricompense erano stati dirottati. La società non ha reso noto quanti validator siano stati coinvolti né come l'attacker abbia ottenuto l'accesso.

Il lato dei prelievi è rimasto intatto. MetaMask Staking non detiene le chiavi di prelievo dell'ETH in staking dei clienti, e la società afferma di non aver trovato prove di compromissione del capitale in staking, delle chiavi di prelievo o dei wallet MetaMask. Gli utenti ordinari del wallet MetaMask non devono intraprendere alcuna azione.

I 0,385 ETH non rappresentano il costo totale dell'incidente. MetaMask ha effettuato l'exit di tutti i validator coinvolti per precauzione, e tutti gli exit sono ormai completati. Alcuni clienti hanno subito ritardi temporanei nei prelievi, e la società riconosce che alcune ricompense potrebbero essere andate perse mentre i validator uscivano o attendevano di essere di nuovo in staking. MetaMask non ha quantificato tali perdite né dichiarato se le ricompense dirottate verranno rimborsate, affermando solo che sta lavorando direttamente con i clienti e i partner coinvolti.

Il dirottamento delle ricompense appare solo nella voce del 5 novembre. Gli avvisi di MetaMask del 30 settembre e del 1° ottobre descrivevano l'incidente e gli exit precauzionali, affermando che a quella fase non vi erano indicazioni di compromissione dei wallet o dei fondi dei clienti. Il numero di validator coinvolti, il punto di accesso dell'attacker e la questione del rimborso restano i punti aperti da monitorare nei futuri aggiornamenti di MetaMask.

Perché lo Stake È Rimasto Intatto Ma il Reddito No

Ogni validator Ethereum risponde a due indirizzi impostati in luoghi diversi. Le indicazioni di Ethereum sui prelievi trattano le credenziali di prelievo e il fee recipient come impostazioni distinte, anche se entrambe possono puntare allo stesso wallet.

Le credenziali di prelievo sono registrate sulla beacon chain. Una volta che puntano a un indirizzo del execution layer, quell'indirizzo non può essere modificato, ed è lì che va l'ETH del validator quando effettua l'exit. Nessun server dell'operatore può ridirigerlo.

Il fee recipient funziona diversamente. È un'impostazione software fornita da chi gestisce il validator. In un servizio non-custodial, si tratta dell'operatore, che detiene anche le chiavi con cui il validator firma. L'impostazione indica alla rete dove inviare il reddito del execution layer ogni volta che il validator propone un blocco: le priority fee delle transazioni e i pagamenti dei block builder. La base fee, al contrario, viene bruciata e non arriva mai al validator. L'operatore può aggiornare il fee recipient in qualsiasi momento senza la chiave di prelievo dello staker. Questa è l'impostazione che MetaMask dichiara di aver archiviato centralmente — ed è quella modificata dall'attacker.

La stessa distinzione spiega perché la perdita è rimasta contenuta. Le ricompense del consensus layer restano nel saldo del validator o vengono trasferite automaticamente all'indirizzo di prelievo, quindi l'impostazione alterata non le ha mai toccate. Il reddito del execution layer arriva solo quando un validator propone un blocco, cosa che ogni singolo validator fa raramente, e MetaMask ha corretto la modifica entro un giorno. Solo le proposte effettuate in quell'arco temporale hanno pagato l'indirizzo errato.

La Stessa Esposizione Riguarda lo Staking in Pool

Nulla di questa esposizione è unico di MetaMask. Ovunque una terza parte gestisca il validator, il fee recipient si trova nella configurazione di quella terza parte, il che rende l'esposizione una caratteristica strutturale dello staking tramite terzi anziché un difetto limitato a un solo provider. Lido, i cui validator sono gestiti da node operator indipendenti, affronta il rischio tramite regole: la sua attuale politica MEV richiede che ogni validator Lido designi l'Execution Layer Rewards Vault del protocollo come fee recipient, e le violazioni dispongono già di un processo dedicato di gestione.

Il vault è un contratto. Secondo la documentazione di Lido, raccoglie il reddito del execution layer, inclusi MEV e priority fee, e solo il contratto principale di Lido può prelevare da esso, spostando l'ETH nella contabilità del protocollo per i detentori di stETH. Un pagamento inviato altrove non entra mai in quella contabilità.

I detentori di stETH si trovano a un ulteriore grado di distanza da queste impostazioni rispetto ai clienti di MetaMask Staking. Possiedono un token trasferibile anziché credenziali di prelievo per uno specifico validator, quindi la loro protezione si basa interamente sui contratti di Lido e sulle regole per gli operatori.

ePBS Garantirebbe il Pagamento, Non l'Indirizzo

Il 4 novembre, Lido ha pubblicato una proposta per aggiornare quella politica MEV in vista della enshrined proposer-builder separation, o ePBS, il design specificato nella EIP-7732. I validator che oggi affidano la costruzione dei blocchi a terzi dipendono dai relay, intermediari di cui si ha fiducia perché garantiscano che il builder vincitore paghi effettivamente. Lido descrive ePBS come una riduzione della necessità di tale fiducia, con il protocollo che garantisce esso stesso i pagamenti dei builder.

La garanzia ha limiti. Nel design descritto da Lido, una singola bid può combinare un valore trustless, dovuto non appena il proposer include la bid anche se il builder non rivela mai il suo blocco, con un pagamento trusted opzionale regolato al di fuori del protocollo, che comporta lo stesso rischio di controparte dell'attuale mercato. Lido permetterebbe a qualsiasi builder registrato di vincere i suoi slot con bid completamente trustless, ma solo i builder nella sua Allowed List approvata potrebbero aggiungere pagamenti trusted.

Più rilevante per gli staker, la garanzia copre quanto viene pagato, non dove finisce. Secondo il design, i validator trasmettono preferenze firmate che designano il proprio fee recipient per gli slot a venire, e il valore trustless va al fee recipient indicato nella bid. Quell'indirizzo proviene comunque dall'operatore. Un fee recipient alterato nel modo descritto da MetaMask riceverebbe pagamenti garantiti con la stessa certezza di quello corretto.

La bozza di Lido mantiene la regola del fee recipient al suo centro. Entrambi i tipi di pagamento devono raggiungere l'EL Rewards Vault, e la politica vincolerebbe ogni nodo in grado di proporre per Lido, incluse le macchine di backup e failover. Lido afferma che la proposta andrà al voto a novembre e avrà effetto solo dopo che l'aggiornamento Glamsterdam sarà arrivato sulla mainnet di Ethereum. Fino ad allora, l'attuale politica MEV — con la sua regola del vault — resta lo standard a cui sono tenuti i validator Lido.

Cosa Rileverebbero i Controlli di Lido

Poiché ePBS apre ulteriori vie per la consegna di un blocco, la proposta amplia il monitoraggio di Lido. Un validator verrebbe segnalato per aver designato un indirizzo diverso dal vault, o per aver accettato un pagamento trusted da un builder fuori dalla Allowed List. Le segnalazioni coprirebbero anche i pagamenti trusted che non arrivano integralmente entro il periodo di regolamento, e i blocchi costruiti localmente proposti mentre erano disponibili bid esterne idonee sopra la soglia minima.

Il controllo sul valore della bid confronta ogni bid selezionata con la bid idonea più alta osservata dal monitoraggio di Lido, segnalando tutto ciò che scende sotto una soglia iniziale del 90–95%. La soglia è uno spunto per domande, non una quota di reddito garantita. La bozza consente agli operatori di scartare la bid migliore per legittimi motivi operativi e di affidabilità, e il confronto copre solo le bid osservate dal sistema di Lido stesso.

Una segnalazione non riporta indietro il denaro. Le violazioni del fee recipient restano soggette all'attuale processo di Lido, mentre le altre segnalazioni seguirebbero il percorso di contatto ed escalation della Sezione E del suo Standard Node Operator Protocol. Lido prevede inoltre di aggiornare la sua pubblica Fees Monitoring Dashboard per mostrare quale percorso ha seguito ogni blocco Lido.

Come Verificare il Proprio Setup di Staking

I pagamenti del execution layer sono registrati on-chain, ed è così che gli indirizzi alterati presso MetaMask sono diventati visibili. Uno staker che conosce i propri indici dei validator può aprire su un explorer della beacon chain ogni blocco proposto da quei validator e verificare quale indirizzo abbia ricevuto il pagamento del proposer. Per Lido, la dashboard delle fee è la vista pubblica del monitoraggio del pool.

Anche gli exit meritano la stessa attenzione. Come nota l'aggiornamento di MetaMask, l'exit di un validator e il prelievo del suo ETH sono processi distinti: un validator che ha effettuato l'exit deve comunque completare l'elaborazione dei prelievi di Ethereum prima che l'ETH sia spendibile, come descritto nella documentazione di staking di Ethereum. Dall'aggiornamento Pectra, la EIP-7002 consente al titolare dell'indirizzo di prelievo del execution layer di un validator di attivarne direttamente l'exit, senza passare dall'operatore.

Quattro domande da porre a qualsiasi provider di staking coprono le lacune esposte da questo incidente:

Chi può modificare il mio fee recipient? Cercate ruoli designati, un'approvazione prima di qualsiasi modifica e un registro di ogni cambiamento, anziché una singola impostazione archiviata centralmente.

Quanto velocemente individuereste un indirizzo errato? Cercate controlli automatizzati su ogni blocco proposto, con avvisi invece di revisioni manuali periodiche.

Quali pagamenti dei builder sono garantiti? Con ePBS, aspettatevi una suddivisione tra valore imposto dal protocollo e pagamenti trusted, e una spiegazione di come vengono perseguiti gli importi non pagati.

Posso effettuare l'exit senza di voi? Verificate che le vostre credenziali di prelievo supportino gli exit auto-attivati, e chiedete chi copre le ricompense perse durante un exit precauzionale.