Vai al contenuto
Financial Context Wiki

Address poisoning

L'address poisoning inserisce un destinatario somigliante nella cronologia delle transazioni o in un'altra interfaccia dall'aspetto affidabile, affinché un pagamento successivo venga copiato verso l'attaccante; sfrutta la verifica del destinatario senza modificare l'indirizzo reale né rubarne la chiave.

Aggiornato

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

Risposta diretta

L’address poisoning è una frode basata sulla sostituzione del destinatario. L’attaccante genera un indirizzo diverso, il cui prefisso e suffisso visibili somigliano a quelli di un destinatario fidato, quindi lo inserisce nella cronologia delle transazioni o in un’altra interfaccia dall’aspetto affidabile. Confida che un mittente copi in seguito quell’indirizzo somigliante e firmi un pagamento valido a suo favore. L’attacco non modifica l’indirizzo legittimo, non ne viola la chiave privata e non induce il consenso a deviare il trasferimento.

Il record inserito può derivare da una vera transazione di un asset nativo, da un trasferimento di token di valore zero conforme allo standard o da un log emesso da un altro contratto di token. Le pagine di attività di wallet ed explorer sono viste derivate: una riga etichettata «inviato» può provenire dai campi di un evento, non da una transazione esterna firmata dall’indirizzo from visualizzato. Occorre verificare separatamente mittente e destinazione della transazione esterna, contratto chiamato, contratto che emette l’evento, campi indicizzati ed effettive variazioni dei saldi.

Il checksum ERC-55 aiuta a rilevare alcuni errori di digitazione accidentali, ma un indirizzo diverso dell’attaccante può essere sintatticamente valido e avere un checksum corretto. I normali indirizzi EVM di 20 byte, inoltre, non identificano la chain prevista, l’asset, il ruolo del destinatario, il memo di deposito o la chiamata al contratto. Un’istruzione di pagamento sicura vincola tutti questi elementi alla destinazione completa.

Address poisoning
0 / 5
0 elementi recensiti; 5 elementi ancora irrisolti

Il completamento di questa revisione non dimostra che una risorsa, una transazione o un sistema siano sicuri.

Come funziona

L’attaccante osserva un modello di pagamento pubblico e cerca un vanity address che corrisponda ai caratteri mostrati in forma troncata dal wallet. Far corrispondere determinati caratteri esadecimali non clona un account: i byte non visibili restano diversi e l’attaccante controlla la nuova chiave. Un trasferimento minimo può inserire quell’indirizzo reale nella cronologia. Separatamente, ERC-20 richiede che i trasferimenti di valore zero siano trattati come trasferimenti normali ed emettano Transfer; pertanto, un record di valore zero non dimostra da solo falsificazione, compromissione, autorizzazione o perdita economica.

Un contratto di token malevolo può anche emettere un proprio log Transfer(victim, lookalike, 0). Quel log è un dato reale della ricevuta attribuibile al contratto emittente, ma non è un evento del contratto canonico dell’asset e non dimostra che la vittima abbia firmato la transazione esterna. Un indicizzatore che classifica l’attività dai topic degli eventi senza sufficiente contesto del contratto e della chiamata può comunque mostrare un’ingannevole riga in uscita.

Il controllo decisivo è l’intento finale di pagamento. Deve vincolare chain e rete, asset nativo o esatto contratto del token, indirizzo completo e tipo del destinatario, importo e unità raw, nonché eventuali calldata, memo, destination tag o periodo di validità. Gli indirizzi di deposito di exchange, bridge, proxy e percorsi monouso possono diventare obsoleti o richiedere più di un indirizzo. Malware della clipboard e codici QR compromessi sono attacchi distinti, ma la stessa verifica della destinazione completa rileva la sostituzione prima della firma.

Nomi e pagamenti di prova sono controlli di supporto, non prove d’identità. Risolvere un nome ENS per la chain e il record previsti al momento della firma; se viene mostrato un nome inverso, eseguire la risoluzione diretta verso lo stesso indirizzo. Una piccola prova aiuta solo se il destinatario la conferma in modo indipendente e il pagamento principale riutilizza la stessa destinazione fissata. Copiare nuovamente dalla cronologia elimina tale protezione.

Utilizzare questo processo:

  1. Fissare chain, rete, asset ed esatto contratto del token, tipo di destinatario, formato dell’indirizzo, importo e qualsiasi memo, tag, calldata, versione o scadenza ricavati da una fonte indipendente autenticata.
  2. Risolvere una volta nome o QR, validarne formato e checksum e vincolare tutti i byte della destinazione alla chain prevista; confermare mediante risoluzione diretta ogni nome inverso invece di trattare un’etichetta come identità.
  3. Confrontare la destinazione con un’allowlist controllata, una rubrica o una fattura firmata, mai con la cronologia; richiedere approvazione indipendente o doppia per un destinatario nuovo o sostanzialmente modificato.
  4. Decodificare l’esatta transazione non firmata: distinguere il to nativo da un contratto di token o bridge e verificare nella calldata destinatario, token, importo raw, approvazione, deadline e semantica della destinazione.
  5. Quando opportuno, inviare una piccola prova alla destinazione fissata e ottenere conferma indipendente dal destinatario; non copiare nuovamente un indirizzo dalla cronologia per il pagamento principale.
  6. Firmare il trasferimento principale solo dal record verificato, confrontare destinazione e importo completi su un display affidabile, quindi verificare ricevuta, contratto emittente, log e variazioni dei saldi sulla chain corretta.
  7. Se si sospetta poisoning o un invio errato, interrompere i pagamenti successivi, conservare hash e prove e contattare tempestivamente il servizio destinatario, l’emittente o le autorità quando pertinente; considerare congelamento, restituzione e recupero condizionali, mai certi.

Esempi

  • Il troncamento nasconde la differenza. L’indirizzo legittimo 0x12ab1111111111111111111111111111111189ef e quello dell’attaccante 0x12ab9999999999999999999999999999999989ef sono entrambi visualizzati come 0x12ab...89ef. Condividono 4 + 4 = 8 caratteri esadecimali visibili, ma differiscono in tutti i 32 caratteri centrali. Confrontare solo le estremità visualizzate produce una falsa corrispondenza; confrontare tutti i byte no.
  • Lavoro della ricerca vanity. Far corrispondere k = 8 caratteri esadecimali scelti richiede un lavoro atteso di 16^8 = 4,294,967,296 candidati. A un’ipotetica velocità di 50,000,000 candidates/s, il tempo atteso è 4,294,967,296 / 50,000,000 = 85.89934592 s. Ciò illustra uno spazio di ricerca, non un tempo di esecuzione promesso o una soglia di avviso del wallet.
  • Log rispetto allo stato. Un contratto di token emette Transfer(victim, lookalike, 0). Il saldo della vittima passa da 250,000.000000 a 250,000.000000, quindi la variazione è 0.000000; un indice delle attività può comunque mostrare una riga di trasferimento. Verificare contratto emittente e autorizzazione della chiamata: la riga da sola non dimostra né movimento di valore né firma della vittima.
  • Una prova deve fissare la destinazione. Una tesoreria pianifica 50,000 USDC, invia 1 USDC a un indirizzo verificato, riceve conferma indipendente e invia 49,999 USDC dallo stesso record fissato: 1 + 49,999 = 50,000 USDC. Se il personale ricopia dalla cronologia un indirizzo somigliante per la seconda parte, la prova non protegge più il pagamento di 49,999 USDC.

Rischi

  • Un mittente copia un indirizzo somigliante da una cronologia avvelenata.
  • Un’interfaccia troncata nasconde i caratteri centrali differenti.
  • Un prefisso o suffisso vanity viene scambiato per identità del destinatario.
  • Un trasferimento ERC-20 di valore zero crea una riga di cronologia ingannevole.
  • Un token contraffatto o il suo log viene scambiato per attività dell’asset canonico.
  • Un indicizzatore classifica male i campi degli eventi o li corregge troppo tardi.
  • Nome, simbolo o icona di un token spam imita un asset fidato.
  • Un malware della clipboard sostituisce un indirizzo verificato prima della firma.
  • Una rubrica locale o sincronizzata è avvelenata o obsoleta.
  • Un’allowlist vincola chain, asset, ruolo o versione dell’indirizzo errati.
  • Un avviso di checksum non valido o mancante viene ignorato.
  • Un checksum valido viene scambiato per prova dell’identità del destinatario.
  • La risoluzione ENS cambia, usa il coin type sbagliato o è obsoleta.
  • Un nome inverso viene visualizzato senza conferma mediante risoluzione diretta.
  • Dopo un pagamento di prova si copia di nuovo da una fonte non affidabile.
  • Indirizzo di deposito, rete, memo o tag di un exchange è errato o scaduto.
  • Destinazione e calldata richiesta da bridge, proxy o contratto sono fraintese.
  • Un firmatario controlla solo testo troncato, persino su un dispositivo hardware.
  • Un trasferimento al destinatario sbagliato diventa canonico prima dell’intervento.
  • La vittima fa affidamento sul congelamento discrezionale dell’emittente o su una recovery scam.

Errori comuni

  • L’address poisoning significa che wallet, chiave o blockchain sono stati violati. L’attacco usuale sfrutta la selezione del destinatario mentre crittografia e consenso validi eseguono l’intento firmato errato.
  • Una riga di valore zero deve essere una transazione on-chain falsa. Trasferimenti conformi e log reali possono avere valore zero; verificarne origine ed effetto sullo stato.
  • Estremità corrispondenti più checksum dimostrano il destinatario. Un altro indirizzo valido può corrispondere nei caratteri visibili e avere un proprio checksum valido.
  • Una prova riuscita protegge automaticamente il trasferimento successivo. La protezione si perde se il pagamento principale non riutilizza la destinazione fissata e confermata.
  • Wallet, validatore o emittente del token possono sempre annullare il pagamento. Poteri e cooperazione per il recupero dipendono da asset, servizio, giurisdizione, prove e tempistica.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...