Aller au contenu
Financial Context Wiki

Empoisonnement d'adresses

L'empoisonnement d'adresses insère un destinataire ressemblant dans l'historique des transactions ou une autre interface d'apparence fiable afin qu'un paiement ultérieur soit copié vers l'attaquant ; il exploite la vérification du destinataire sans modifier l'adresse réelle ni voler sa clé.

Mis à jour

À des fins éducatives uniquement ; ne constitue ni un conseil en investissement ni une recommandation d’investissement. Les investissements peuvent entraîner des pertes.

Réponse directe

L’empoisonnement d’adresses est une fraude par substitution du destinataire. L’attaquant génère une autre adresse dont le préfixe et le suffixe visibles ressemblent à ceux d’un destinataire de confiance, puis l’insère dans l’historique des transactions ou une autre interface d’apparence fiable. Il espère qu’un expéditeur copiera ensuite cette adresse ressemblante et signera un paiement valide à son profit. L’attaque ne modifie pas l’adresse légitime, ne compromet pas sa clé privée et ne conduit pas le consensus à détourner le transfert.

L’entrée insérée peut provenir d’une véritable transaction d’actif natif, d’un transfert de token de valeur nulle conforme au standard ou d’un log émis par un autre contrat de token. Les pages d’activité des wallets et explorateurs sont des vues dérivées : une ligne intitulée « envoyé » peut provenir de champs d’événement et non d’une transaction externe signée par l’adresse from affichée. Il faut vérifier séparément l’expéditeur et la destination de la transaction externe, le contrat appelé, le contrat émetteur de l’événement, les champs indexés et les variations réelles des soldes.

Le checksum ERC-55 aide à détecter certaines erreurs de saisie accidentelles, mais une autre adresse de l’attaquant peut être syntaxiquement valide et correctement checksummée. Les adresses EVM ordinaires de 20 octets n’identifient pas non plus à elles seules la chaîne prévue, l’actif, le rôle du destinataire, le memo de dépôt ou l’appel de contrat. Une instruction de paiement sûre lie tous ces éléments à la destination complète.

Empoisonnement d'adresses
0 / 5
0 articles examinés; 5 points toujours non résolus

La réalisation de cet examen ne prouve pas qu'un actif, une transaction ou un système est sûr.

Fonctionnement

L’attaquant observe un schéma de paiement public et recherche une vanity address correspondant aux caractères que le wallet affiche sous forme tronquée. Faire correspondre certains caractères hexadécimaux ne clone pas un compte : les octets invisibles restent différents et l’attaquant contrôle la nouvelle clé. Un transfert minime peut inscrire cette véritable adresse dans l’historique. Séparément, ERC-20 exige que les transferts de valeur nulle soient traités comme des transferts normaux et émettent Transfer ; un enregistrement de valeur nulle ne prouve donc à lui seul ni falsification, ni compromission, ni autorisation, ni perte économique.

Un contrat de token malveillant peut également émettre son propre log Transfer(victim, lookalike, 0). Ce log est une donnée réelle du reçu attribuable au contrat émetteur, mais ce n’est pas un événement du contrat canonique de l’actif et il ne prouve pas que la victime a signé la transaction externe. Un indexeur qui classe l’activité à partir des topics d’événements sans disposer d’un contexte suffisant sur le contrat et l’appel peut néanmoins afficher une ligne sortante trompeuse.

Le contrôle décisif porte sur l’intention finale de paiement. Elle doit lier chaîne et réseau, actif natif ou contrat de token exact, adresse complète et type du destinataire, montant et unités raw, ainsi que toute calldata, memo, destination tag ou durée de validité. Les adresses de dépôt d’exchanges, bridges, proxies et itinéraires à usage unique peuvent devenir obsolètes ou exiger davantage qu’une adresse. Les logiciels malveillants visant le presse-papiers et les QR codes compromis sont des attaques distinctes, mais la même vérification de la destination complète détecte la substitution avant la signature.

Les noms et paiements de test sont des contrôles complémentaires, non des preuves d’identité. Résolvez un nom ENS pour la chaîne et l’enregistrement prévus au moment de la signature ; si un nom inverse est affiché, effectuez une résolution directe vers la même adresse. Un petit test n’est utile que si le destinataire le confirme indépendamment et si le paiement principal réutilise la même destination épinglée. Copier à nouveau depuis l’historique supprime cette protection.

Suivez ce processus :

  1. Épinglez chaîne, réseau, actif et contrat de token exact, type de destinataire, format d’adresse, montant et tout memo, tag, calldata, version ou expiration provenant d’une source indépendante authentifiée.
  2. Résolvez une fois le nom ou le QR code, validez son format et son checksum et liez tous les octets de la destination à la chaîne prévue ; confirmez directement tout nom inverse plutôt que de traiter un libellé comme une identité.
  3. Comparez la destination à une allowlist contrôlée, un carnet d’adresses ou une facture signée, jamais à l’historique ; exigez une approbation indépendante ou double pour tout destinataire nouveau ou sensiblement modifié.
  4. Décodez l’exacte transaction non signée : distinguez le to natif d’un contrat de token ou de bridge et inspectez dans la calldata le destinataire, le token, le montant raw, l’approbation, la deadline et la sémantique de destination.
  5. Le cas échéant, envoyez un petit test à la destination épinglée et obtenez une confirmation indépendante du destinataire ; ne recopiez pas une adresse depuis l’historique pour le paiement principal.
  6. Signez le transfert principal uniquement depuis l’enregistrement vérifié, comparez la destination et le montant complets sur un écran fiable, puis vérifiez reçu, contrat émetteur, logs et variations de solde sur la bonne chaîne.
  7. En cas de suspicion d’empoisonnement ou d’erreur d’envoi, arrêtez les paiements ultérieurs, conservez hashes et preuves et contactez rapidement le service destinataire, l’émetteur ou les autorités le cas échéant ; considérez gel, restitution et récupération comme conditionnels, jamais garantis.

Exemples

  • La troncature masque la différence. L’adresse légitime 0x12ab1111111111111111111111111111111189ef et celle de l’attaquant 0x12ab9999999999999999999999999999999989ef sont toutes deux affichées comme 0x12ab...89ef. Elles partagent 4 + 4 = 8 caractères hexadécimaux affichés, mais diffèrent pour les 32 caractères centraux. Comparer uniquement les extrémités affichées produit une fausse correspondance ; comparer tous les octets n’en produit pas.
  • Travail de recherche vanity. Faire correspondre k = 8 caractères hexadécimaux choisis représente un travail attendu de 16^8 = 4,294,967,296 candidats. À une cadence supposée de 50,000,000 candidates/s, le temps attendu est 4,294,967,296 / 50,000,000 = 85.89934592 s. Cela illustre un espace de recherche, non une durée d’exécution promise ou un seuil d’alerte du wallet.
  • Log par rapport à l’état. Un contrat de token émet Transfer(victim, lookalike, 0). Le solde de la victime passe de 250,000.000000 à 250,000.000000, soit une variation de 0.000000 ; un index d’activité peut néanmoins afficher une ligne de transfert. Vérifiez le contrat émetteur et l’autorisation de l’appel : la ligne seule ne prouve ni mouvement de valeur ni signature de la victime.
  • Un test doit épingler la destination. Une trésorerie prévoit 50,000 USDC, envoie 1 USDC à une adresse vérifiée, reçoit une confirmation indépendante et envoie 49,999 USDC depuis le même enregistrement épinglé : 1 + 49,999 = 50,000 USDC. Si l’équipe recopie une adresse ressemblante depuis l’historique pour la seconde étape, le test ne protège plus le paiement de 49,999 USDC.

Risques

  • Un expéditeur copie une adresse ressemblante depuis un historique empoisonné.
  • Une interface tronquée masque les caractères centraux différents.
  • Un préfixe ou suffixe vanity est pris pour l’identité du destinataire.
  • Un transfert ERC-20 de valeur nulle crée une ligne d’historique trompeuse.
  • Un faux token ou son log est pris pour l’activité de l’actif canonique.
  • Un indexeur classe mal des champs d’événements ou les corrige trop tard.
  • Le nom, symbole ou icône d’un token spam imite un actif de confiance.
  • Un logiciel malveillant du presse-papiers remplace une adresse vérifiée avant la signature.
  • Un carnet d’adresses local ou synchronisé est empoisonné ou obsolète.
  • Une allowlist lie la mauvaise chaîne, le mauvais actif, rôle ou version d’adresse.
  • Un avertissement de checksum invalide ou absent est ignoré.
  • Un checksum valide est pris pour une preuve d’identité du destinataire.
  • La résolution ENS change, utilise le mauvais coin type ou devient obsolète.
  • Un nom inverse est affiché sans confirmation par résolution directe.
  • Après un paiement de test, l’adresse est recopiée depuis une source non fiable.
  • L’adresse de dépôt, le réseau, memo ou tag d’un exchange est erroné ou expiré.
  • La destination et la calldata exigée par un bridge, proxy ou contrat sont mal comprises.
  • Un signataire ne contrôle que du texte tronqué, même sur un appareil hardware.
  • Un transfert au mauvais destinataire devient canonique avant toute intervention.
  • La victime dépend d’un gel discrétionnaire de l’émetteur ou d’une escroquerie de récupération.

Idées fausses courantes

  • L’empoisonnement signifie que le wallet, la clé ou la blockchain a été piraté. L’attaque habituelle exploite la sélection du destinataire tandis qu’une cryptographie et un consensus valides exécutent la mauvaise intention signée.
  • Une ligne de valeur nulle doit être une fausse transaction on-chain. Des transferts conformes et des logs réels peuvent avoir une valeur nulle ; examinez leur source et leur effet sur l’état.
  • Des extrémités correspondantes plus un checksum prouvent le destinataire. Une autre adresse valide peut correspondre aux caractères visibles et posséder son propre checksum valide.
  • Un test réussi protège automatiquement le transfert suivant. La protection disparaît si le paiement principal ne réutilise pas la destination épinglée et confirmée.
  • Un wallet, validateur ou émetteur du token peut toujours annuler le paiement. Les pouvoirs et la coopération pour récupérer dépendent de l’actif, du service, de la juridiction, des preuves et du délai.

Sujets connexes

Sources

Navigation

Rechercher dans le wiki...