Nel 1993, i crittografi lo definirono "l'attacco più semplice del libro": prendere un messaggio valido, aspettare e inviarlo di nuovo. Nessuno costruisce una cassaforte aspettandosi che la chiave venga riutilizzata.
Ma è esattamente ciò che è successo quando Ethereum ed Ethereum Classic si sono separati: la stessa transazione firmata, trasmessa su due blockchain, ha spostato fondi reali due volte. Nessun attacco hacker, nessuna password rubata, nessun link di phishing.
Un attacco ripetitivo che fa quello che ha sempre fatto, usando la legittimità come arma.
Unisciti a UEEx
Scopri la piattaforma di gestione patrimoniale digitale leader al mondo
Che cos'è un attacco di replay (replaying attack)?
Un attacco di replay è un tipo di violazione della sicurezza di rete in cui un aggressore intercetta trasmissioni di dati valide e le riutilizza o le reinvia in modo dannoso per ingannare un sistema.
A differenza degli attacchi che alterano o falsificano i dati, un attacco di riproduzione si limita a ritrasmettere informazioni precedentemente acquisite, come credenziali di accesso, token di autenticazione o richieste di transazione, per indurre il sistema a credere di ricevere un comando nuovo e legittimo.
Nota bene: Un attacco di replay (replaying attack) può verificarsi sulla stessa catena o su catene incrociate.
Qual è la differenza tra un attacco di replay sulla stessa catena e un attacco di replay tra catene diverse?
Un attacco di replay sulla stessa blockchain si verifica all'interno di una singola blockchain: la stessa transazione o lo stesso messaggio firmato vengono inviati più volte alla stessa rete.
Il meccanismo del nonce impedisce che ciò accada nelle transazioni Ethereum standard; una volta che un nonce (numero utilizzato una sola volta) viene consumato, la transazione corrispondente viene rifiutata.
Gli attacchi di replay cross-chain si verificano tra due blockchain che condividono formati di indirizzo e logica di firma, più comunemente dopo un hard fork.
Il nonce (numero utilizzato una sola volta) non è utile in questo caso, perché le due blockchain tracciano i nonce in modo indipendente. Una transazione con nonce 5 su Ethereum e una con nonce 5 su Ethereum Classic sono record diversi su sistemi diversi, ma i dati della transazione firmata sono identici.
L'ID della catena di EIP-155 è la soluzione specifica per la riproduzione tra catene. Per la verifica della firma degli smart contract, il separatore di dominio di EIP-712 gestisce sia le varianti sulla stessa catena che quelle tra catene diverse.
Unisciti a UEEx
Scopri la piattaforma di gestione patrimoniale digitale leader al mondo
Quando gli attacchi di replay si sono effettivamente verificati: tre casi documentati
Gli attacchi di replay nella blockchain non sono teorici. Hanno causato perdite finanziarie documentate in diversi casi.
La biforcazione tra Ethereum ed Ethereum Classic — 2016
Quando la rete Ethereum si è divisa in Ethereum (ETH) ed Ethereum Classic (ETC) in seguito all'attacco hacker alla DAO, ogni transazione firmata prima della biforcazione era valida su entrambe le catene.
Le due blockchain condividevano spazi di indirizzamento, formati di transazione e logica di verifica della firma identici.
Una transazione firmata da qualsiasi portafoglio era contemporaneamente una transazione valida sia su ETH che su ETC.
Gli exchange che detenevano fondi degli utenti in ETH e ETC sono diventati immediatamente bersaglio di attacchi.
Gli hacker hanno intercettato transazioni di prelievo di ETH valide e le hanno riprodotte sulla blockchain di ETC, svuotando i saldi di ETC che gli utenti non avevano alcuna intenzione di utilizzare.
Oltre 40,000 ETC sono stati prelevati dagli exchange nel periodo successivo al fork, prima che la protezione contro i replay fosse ampiamente implementata.
Questo evento ha portato direttamente alla creazione dell'EIP-155.
La fusione di Ethereum — 2022
Quando Ethereum è passato da Proof of Work a Proof of Stake (The Merge), una catena biforcuta chiamata Ethereum PoW (ETHW) è stato creato.
Nel giro di pochi giorni, un hacker ha sfruttato il contratto cross-chain Omni Bridge, che non disponeva di una protezione specifica contro gli attacchi di replay per ETHW, e ha riprodotto transazioni che hanno trasferito 200 ETHW dal contratto bridge.
Nell'ambito dell'attacco, l'attaccante ha utilizzato i dati di prezzo dell'oracolo della rete principale di ETH sulla blockchain di ETHW, dove risultavano obsoleti e manipolabili.
Il furto del token Optimism OP — 2022
In un incidente di replay cross-chain, 20 milioni di dollari in token OP sono stati rubati a Optimism durante una sequenza di transazioni multisig contestate.
L'attacco ha sfruttato la lacuna tra i contesti delle blockchain L1 (Ethereum) e L2 (Optimism), dove la riproduzione di uno specifico messaggio firmato sulla blockchain sbagliata ha permesso di spostare token senza autorizzazione.
Non si tratta di episodi isolati. Rappresentano uno schema documentato: ogni volta che un nuovo fork o un'implementazione L2 crea due ambienti che condividono indirizzi o formati di firma senza un collegamento specifico alla blockchain, esiste un rischio di replay.
Pensate all'ultima volta che è stata lanciata una nuova blockchain che condivideva il vostro indirizzo Ethereum. Avete verificato se le vostre autorizzazioni firmate esistenti fossero valide su quella nuova blockchain? Avete controllato se lo schema di firma del vostro wallet includesse EIP-155? La maggior parte delle persone non l'ha fatto. La maggior parte delle persone non ha avuto problemi. Ma chi non ha avuto problemi ha perso fondi reali, e nessuno di loro se lo aspettava.
EIP-155: La soluzione che ha fatto seguito al fork del 2016
La direttiva EIP-155, introdotta dal co-fondatore di Ethereum Vitalik Buterin nel 2016, è stata creata specificamente per impedire che le transazioni vengano replicate su blockchain derivate da fork.
La soluzione era in linea di principio semplice: incorporare l'identificativo univoco della catena (chainId) in ogni firma di transazione.
Prima dell'EIP-155, la firma di una transazione comprendeva sei campi dati: nonce, prezzo del gas, limite del gas, indirizzo del destinatario, valore e dati.
La firma era valida su qualsiasi blockchain compatibile con EVM che utilizzasse la stessa logica di verifica, poiché nessuno di quei campi identificava la specifica blockchain a cui la transazione era destinata.
Dopo l'EIP-155, le transazioni includono tre campi aggiuntivi nell'hash della firma: chainId e due valori segnaposto vuoti.
Una transazione firmata per Mainnet Ethereum (chainId = 1) non è una firma valida su Optimism (chainId = 10), Polygon (chainId = 137) o qualsiasi altra catena EVM.
Il nodo che riceve la transazione confronta il chainId con il proprio e rifiuta qualsiasi discrepanza.
Questa singola modifica ha ridotto significativamente gli attacchi di replay cross-chain per le transazioni standard.
La limitazione importante: La direttiva EIP-155 protegge solo le transazioni Ethereum non elaborate.
Non protegge le firme a livello di applicazione, ovvero i messaggi firmati che gli smart contract verificano internamente utilizzando la funzione ecrecover.
Un contratto che convalida le firme off-chain senza controllare il chainId rimane vulnerabile agli attacchi di replay anche se l'EIP-155 viene implementato completamente a livello di transazione. È qui che entra in gioco l'EIP-712.
Il Nonce: come previene la riproduzione nella stessa catena
Il nonce (numero utilizzato una sola volta) è il meccanismo che previene gli attacchi di replay all'interno della stessa blockchain. Ogni account Ethereum mantiene un contatore che parte da 0 e viene incrementato di 1 a ogni transazione inviata.
Quando invii una transazione con nonce = 5, la rete la accetta solo se il nonce del tuo conto corrente è esattamente 5.
Una volta elaborato, il nonce del tuo account diventa 6 e qualsiasi tentativo di riprodurre la transazione con nonce-5 fallisce perché la rete ora si aspetta il nonce 6.
Ecco perché non è possibile inviare la stessa transazione Ethereum due volte sulla stessa blockchain: il nonce lo impedisce. Il problema individuato dall'analisi di Gate.io del marzo 2026 è il seguente: il nonce da solo impedisce la ripetizione delle transazioni sulla stessa blockchain, ma non su blockchain diverse, perché le diverse blockchain mantengono conteggi di nonce separati.
Il nonce del tuo account sulla rete principale di Ethereum e il nonce del tuo account su Ethereum Classic vengono tracciati in modo indipendente.
Una transazione con nonce = 5 su Ethereum potrebbe avere nonce = 5 anche su Ethereum Classic se hai effettuato lo stesso numero di transazioni su entrambe le blockchain. La proposta EIP-155 colma questa lacuna rendendo il chainId parte integrante della firma stessa.
Unisciti a UEEx
Scopri la piattaforma di gestione patrimoniale digitale leader al mondo
EIP-155 ha risolto gli attacchi di replay a livello di transazione. Non è d'aiuto per la verifica della firma degli smart contract.
Quando uno smart contract utilizza ecrecover per convalidare una firma off-chain, sta verificando un messaggio, non una transazione. La protezione chainId di EIP-155 si applica alla transazione Ethereum che trasporta il messaggio, non al contenuto del messaggio stesso.
Se uno sviluppatore crea un contratto che convalida le firme senza includere l'ID della catena, l'indirizzo del contratto e il nonce nei dati firmati, tali firme possono essere riutilizzate da chiunque le intercetti.
EIP-712 (Typed Structured Data Signing) affronta questo problema. Definisce un metodo standard per strutturare i messaggi firmati, che include un separatore di dominio, un hash contenente il chainId, l'indirizzo del contratto di verifica, il nome e la versione del contratto stesso.
Una firma creata ai sensi dell'EIP-712 è vincolata a un contratto specifico presso un indirizzo specifico all'interno di una catena specifica.
Non può essere riprodotto su una blockchain diversa o con un contratto diverso, anche se il bytecode è identico.
Per gli sviluppatori: prima di implementare qualsiasi contratto che verifichi firme off-chain, assicuratevi che il vostro schema di firma includa tutti e tre gli elementi: nonce (impedisce il riutilizzo dello stesso messaggio), chainId (impedisce la riproduzione tra blockchain) e indirizzo del contratto (impedisce la riproduzione tra contratti). La libreria ECDSA di OpenZeppelin, dalla versione 4.7.3 in poi, implementa correttamente tutti e tre gli elementi.
Sistemi e protocolli vulnerabili agli attacchi di replay
Sistema/protocollo di destinazione
Perché è vulnerabile
Esempi comuni e difetti
Reti wireless
La trasmissione in campo aperto rende i dati facilmente intercettabili e ritrasmettibili.
Wi-Fi obsoleto (WEP/WPA debole) privo di sequenziamento dei pacchetti; dispositivi Bluetooth privi di convalida del nonce o di accoppiamento di sessione.
Protocolli crittografici
Si basa su chiavi statiche o non dispone di controlli di attualità contestualizzati.
Kerberos o OAuth quando i token di sessione o le credenziali non dispongono di timestamp e regole di scadenza rigorose.
Internet of Things (IoT)
Privilegia il basso consumo energetico e la praticità rispetto a una sicurezza robusta.
Serrature e telecamere intelligenti che utilizzano protocolli IoT (MQTT, CoAP) senza protezione integrata contro gli attacchi di replay a causa della limitata potenza di calcolo.
Sistemi di pagamento
Vulnerabile se le transazioni non dispongono di codici di autenticazione dinamici e monouso.
Carte contactless e terminali POS più vecchi privi di crittogrammi EMV o token per transazione.
1. Validazione del timestamp e monitoraggio dei log
Gli attacchi di replay spesso riutilizzano i dati senza modificarne la data e l'ora originali.
Monitorando e convalidando i timestamp, i sistemi possono rilevare quando i messaggi subiscono ritardi imprevisti o arrivano al di fuori di un intervallo di tempo accettabile.
Implementare rigorosi controlli di validità basati sul tempo per token, transazioni e chiamate API.
Segnala i messaggi che sembrano essere stati ritardati o elaborati al di fuori della normale durata della sessione.
Eseguire il controllo incrociato dei registri di sistema per identificare le richieste con timestamp identici che compaiono più di una volta.
2. Rilevamento di messaggi duplicati
Una caratteristica fondamentale degli attacchi di replay è la ripetizione di messaggi o pacchetti identici.
I sistemi dovrebbero monitorare tali schemi, in particolare in aree critiche come l'autenticazione, le transazioni finanziarie e la gestione delle sessioni.
Utilizzare l'hashing o l'impronta digitale per rilevare pacchetti o richieste duplicati.
Confronta i dati in arrivo con le voci elaborate di recente per verificare la presenza di contenuti ripetuti.
Registra e analizza token di sessione ripetuti, chiamate API o payload crittografati.
3. Tracciamento del numero di sequenza e del nonce
I sistemi sicuri spesso si affidano a numeri di sequenza o nonce (numeri utilizzati una sola volta) per tracciare e convalidare l'unicità dei dati.
I messaggi riprodotti in genere riutilizzano lo stesso nonce o numero di sequenza, che può essere segnalato.
Conservare una memoria a breve termine (cache o database) dei nonce o dei numeri di sequenza utilizzati di recente.
Eliminare o registrare le richieste contenenti valori riutilizzati.
Avviso sui token di sessione o sugli identificatori di richiesta che sono già stati elaborati.
4. Rilevamento di anomalie comportamentali
Gli attacchi di replay non sono sempre repliche tecniche; a volte, il contesto comportamentale può rivelare la minaccia.
Ad esempio, un utente che esegue la stessa identica transazione due volte in pochi secondi potrebbe destare sospetti.
Monitorare il comportamento degli utenti e creare profili di base per le attività normali.
Segnala modelli anomali, come azioni ripetute ad alta frequenza, richieste identiche da IP diversi o più accessi tramite lo stesso token.
Integrare sistemi di rilevamento delle anomalie in grado di apprendere e adattarsi ai modelli di traffico tipici.
5. Analisi del traffico di rete
Strumenti di rilevamento avanzati possono analizzare il traffico di rete in tempo reale per individuare schemi sospetti, soprattutto negli ambienti wireless o IoT in cui gli attacchi di riproduzione sono comuni.
Utilizzare sistemi di rilevamento delle intrusioni (IDS) o sistemi di prevenzione delle intrusioni wireless (WIPS) per rilevare ritrasmissioni di pacchetti sospetti.
Analizza le intestazioni dei pacchetti per individuare identificatori, nonce o parametri di crittografia riutilizzati.
Prestare attenzione ai payload crittografati ripetitivi che non variano tra le sessioni.
6. Analisi del token di sessione e del registro di autenticazione
Gli attacchi di tipo "replay" spesso coinvolgono token di autenticazione riutilizzati. I sistemi dovrebbero verificare e analizzare i registri di emissione e utilizzo dei token per identificare quelli che sembrano essere stati riutilizzati o utilizzati in modo improprio.
Tieni traccia della durata dei token di sessione e delle informazioni IP/dispositivi associate.
Registra i tentativi di riutilizzo delle credenziali di autenticazione scadute o già utilizzate.
Esaminare i tentativi di accesso che riutilizzano intestazioni, metadati o dettagli di sessione.
Qual è la differenza tra un attacco Replay e un attacco MITM?
Un attacco di tipo replay consiste nell'acquisizione e nel reinvio di dati validi per ingannare un sistema, mentre un attacco man-in-the-middle (MitM) intercetta e altera attivamente la comunicazione tra due parti in tempo reale.
Quali sono i tipi più comuni di pacchetti catturati in un attacco di replay?
I tipi più comuni di pacchetti catturati in un attacco di replay includono richieste di autenticazione, token di sessione, messaggi di transazione e comandi di controllo utilizzati nelle comunicazioni wireless o di rete.
In che modo TLS previene un attacco di replay?
TLS impedisce gli attacchi di riproduzione utilizzando chiavi di sessione univoche, numeri di sequenza e codici di autenticazione dei messaggi (MAC) per garantire che ogni messaggio sia aggiornato e non possa essere reinviato o modificato senza essere rilevato.
Che cos'è un attacco di replay Kerberos?
Un attacco di tipo Kerberos replay si verifica quando un aggressore cattura e invia nuovamente un messaggio di autenticazione Kerberos valido per indurre il sistema a concedere un accesso non autorizzato senza riautenticarsi.
Unisciti a UEEx
Scopri la piattaforma di gestione patrimoniale digitale leader al mondo
Gli attacchi di replay possono sembrare semplici, ma il loro impatto può essere grave, spaziando dall'accesso non autorizzato alla perdita di denaro e all'interruzione del servizio.
È fondamentale riconoscere i sistemi vulnerabili, comprendere il funzionamento di questi attacchi e applicare difese a più livelli come nonce, timestamp e crittografia.
Poiché le minacce continuano a colpire i punti deboli dei processi di verifica, la prevenzione e la rilevazione tempestive diventano fondamentali.
Rafforzare i sistemi contro gli attacchi di replay non significa solo proteggerli; significa garantire fiducia, integrità dei dati e un servizio coerente in ambienti digitali in cui la sicurezza non può essere compromessa.
Akindele T. Francis è una content writer versatile con una vasta esperienza in diversi settori. Specializzata in post di blog, contenuti per siti web, pagine di servizi, testi di vendita accattivanti, ecc., Akindele ha collaborato con numerose agenzie per realizzare contenuti accattivanti ed efficaci. Con un occhio attento ai dettagli e una passione per la creazione di narrazioni d'impatto, Akindele supera costantemente le aspettative dei clienti, ottenendo risultati e migliorando la comunicazione del brand su diverse piattaforme.
Negazione di responsabilità: Questo articolo ha scopo puramente informativo e non deve essere considerato un consiglio di trading o di investimento. Nulla di quanto contenuto nel presente documento deve essere interpretato come consulenza finanziaria, legale o fiscale. Il trading o l'investimento in criptovalute comporta un rischio considerevole di perdite finanziarie. Si prega di effettuare sempre la due diligence prima di prendere qualsiasi decisione di trading o di investimento.
