Comment annuler des approbations malveillantes et bloquer…

Révoquer des approbations malveillantes signifie soumettre une transaction sur la chaîne qui réécrit l'autorisation d'un jeton, généralement en la définissant à 0 pour le dépensier qui peut appeler transferFrom sur votre solde.

Principaux enseignements

• Une approbation de jeton est une autorisation permanente au contrat de jeton, et elle persiste jusqu'à ce que vous la changiez sur la chaîne.
• Pour révoquer une approbation, vous envoyez une transaction qui fixe l'autorisation du dépensier à 0 ou à un montant inférieur, et vous payez le gaz.
• Les approbations illimitées sont la version explosive des autorisations car un dépensier compromis peut vider ce solde de jeton jusqu'à l'autorisation.
• Permit2 peut cacher le risque derrière des signatures : vous pourriez ne voir qu'une seule approbation sur la chaîne pour Permit2 alors que le véritable danger est de signer une autorisation EIP-712 malveillante.

Pourquoi les approbations de jetons peuvent être dangereuses

Une approbation malveillante n'est pas « une connexion dApp ». C'est une autorisation active sur un contrat de jeton qui dit qu'un dépensier spécifique peut déplacer vos jetons avec transferFrom.ERC-20les transferts délégués fonctionnent sur trois fonctions : approve(spender, amount), allowance(owner, spender) et transferFrom(from, to, amount). Une fois que cette autorisation existe, le dépensier n'a plus besoin de votre portefeuille. Il lui suffit que l'autorisation soit toujours non nulle.

Cette persistance est tout le problème. Les autorisations restent actives jusqu'à ce qu'elles soient explicitement modifiées, c'est pourquoi les boutons « déconnecter le portefeuille » et les listes de connexion de portefeuille donnent un faux sentiment de sécurité. Se déconnecter supprime la capacité d'un site à solliciter votre portefeuille. Cela ne change rien à l'état du contrat de jeton qui autorise réellement les dépenses.

C'est pourquoile phishing d'approbationfonctionne : l'objectif de l'attaquant est d'obtenir une approbation de jeton (ou une signature de style permis) une fois, puis de l'utiliser plus tard lorsque la victime ne fait plus attention.

Les approbations illimitées sont là où réside le risque de queue. De nombreuses interfaces utilisateur par défaut à « infini » car cela réduit les frictions futures, mais approuver le montant maximum uint256 remet effectivement un chèque en blanc pour ce jeton au dépensier. Si le contrat de dépensier est malveillant aujourd'hui, ou est exploité plus tard, l'autorisation est le chemin de drainage.

Pour les traders, le modèle mental qui tient est « ligne de crédit permanente ». Chaque approbation de jeton est un élément de ligne : jeton → dépensier → limite. Si le lecteur ne peut pas pointer vers le contrat exact qui a actuellement la permission d'appeler transferFrom (soit directement, soit via Permit2), l'exposition réelle est inconnue. C'est l'une des mécaniques fondamentales derrière les escroqueries de portefeuille crypto et comment les éviter.

Comment fonctionne la révocation d'une approbation

Révoquer n'est pas un simple bouton de réglage. C'est un changement d'état sur la chaîne, ce qui signifie que cela coûte du gaz et laisse un enregistrement de transaction.

Mécaniquement, une révocation d'approbation consiste simplement à réécrire la cartographie des autorisations au contrat de jeton afin que l'autorisation du dépensier devienne 0 (ou un nombre plus petit si l'objectif est de continuer à utiliser l'application avec une limite plafonnée).

Deux détails opérationnels comptent plus que la plupart des guides ne l'admettent.

L'une des raisons est que "révoquer l'approbation de jeton" est spécifique au jeton. Révoquer l'USDC pour un dépensier n'affecte pas les approbations de WETH pour le même dépensier. Le registre des allocations est par contrat de jeton.

L'autre est que les mises à jour de l'allocation peuvent avoir un cas limite de condition de concurrence lors du changement d'une allocation non nulle N à une autre allocation non nulle M. Le modèle le plus sûr est celui de Speedrun.Ethereumappelle “approuver-à-zéro-puis-définir.” L'idée est simple : définir l'allocation à 0 d'abord, attendre la confirmation, puis définir le nouveau montant.

Cela supprime la fenêtre où un dépensier pourrait potentiellement utiliser à la fois les anciennes et les nouvelles valeurs d'allocation.

Si un portefeuille ou une dApp génère des erreurs telles que « Échec de l'approbation à zéro » ou « Échec de l'approbation à un nouveau montant », ce n'est généralement pas un signe que la révocation est impossible. C'est un signe que le comportement d'approbation du token est particulier ou que l'interface utilisateur ne gère pas correctement les règles du token.

La solution consiste à utiliser un outil d'allocation différent ou l'interface d'approbation de token d'un explorateur de blocs, puis à réessayer le même changement on-chain.

Le cadrage clé reste cohérent : révoquer, c'est simplement réécrire la permission sur la chaîne. Si le lecteur ne peut pas identifier le dépensier qui détient la permission, la révocation ne peut pas être ciblée correctement.

Révocation étape par étape en utilisant Revoke.cash

Revoke.cash est un flux de travail courant car il affiche les approbations dans un tableau de bord unique et permet à l'utilisateur de soumettre la transaction de révocation on-chain depuis le même écran. Les étapes ci-dessous reflètent le flux dans le portefeuille que documente Bifrost Wallet, mais la séquence est globalement la même à travers les portefeuilles.

1. Ouvrez un navigateur de portefeuille de confiance et naviguez vers Revoke.cash. Utiliser un navigateur intégré au portefeuille réduit le risque de tomber sur un domaine similaire à cause des publicités ou des messages directs. 2. Connectez le portefeuille et sélectionnez le réseau correct.

Les approbations sont spécifiques à la chaîne, donc une approbation Ethereum ne s'affichera pas lorsque l'outil est réglé sur Flare, Base ou une autre chaîne EVM. 3. Ouvrez la vue des approbations de jetons et triez par risque. Commencez par les autorisations illimitées et les jetons avec des soldes significatifs, car ce sont les chemins de drainage à impact le plus élevé. 4. Identifiez le dépensier pour chaque ligne à risque.

Le dépensier est le contrat qui peut appeler transferFrom. Si le nom du dépensier semble inconnu, considérez-le comme hostile jusqu'à preuve du contraire. 5. Cliquez sur révoquer pour les approbations sélectionnées. Cela soumet une transaction qui fixe l'autorisation à 0 pour ce jeton et ce dépensier. 6. Confirmez la transaction dans le portefeuille et payez les frais de gaz.

Si les frais de gaz sont élevés, révoquer d'abord les plus grandes autorisations reste un trade d'« assurance » rationnel. 7. Vérifiez à nouveau la liste des approbations après confirmation. L'autorisation devrait maintenant s'afficher comme 0, ou la ligne devrait disparaître selon l'interface de l'outil.

Ceci est la réponse fondamentale à la manière de révoquer des autorisations : l'utilisateur ne "dissocie" rien. L'utilisateur modifie l'allocation dans le contrat de jeton. Si ledrain de portefeuille a déjà obtenu l'approbation, c'est l'action qui ferme le chemin.

Approbations Permit et Permit2 à vérifier

Fin 2022 est le point d'inflexion que la plupart des utilisateurs ont manqué.Uniswap’s Routeur Universel a fait de Permit2 le chemin d'approbation par défaut, ce qui a déplacé beaucoup de « risque d'approbation » des transactions approve() évidentes vers les signatures EIP-712.

Permit2 est un contrat d'approbation singleton de Uniswap Labs : les utilisateurs approuvent Permit2 une fois par jeton, puis les applications demandent des autorisations signées qui incluent le dépensier, le montant, la date limite et le nonce.

Cela crée deux registres pour auditer.

Le premier registre est celui des allocations ERC-20 classiques : jeton → dépensier. C'est ce que la plupart des tableaux de bord « d'approbation de jetons » montrent, et c'est là que résident généralement les approbations illimitées pour des contrats aléatoires.

Ledger deux est Permit2 : token → autorisation Permit2 on-chain, plus les autorisations signées hors chaîne que les applications demandent. Permit2 prend en charge à la fois le mode d'autorisation permanente et le mode de transfert unique, et ses autorisations sont soumises à des délais.

Les délais peuvent réduire l'exposition aux autorisations dormantes car les autorisations peuvent expirer automatiquement, mais ils ne résolvent pas le vol de signatures. Les campagnes de phishing d'approbation ciblent de plus en plus les invites de signature de permis et de Permit2 car un seul message signé peut suffire à déplacer des fonds.

L'implication pratique est inconfortable mais claire : « Je ne me souviens pas d'avoir approuvé quoi que ce soit » n'est pas un signal de sécurité. Un utilisateur peut être exposé après avoir signé des données tapées qui n'ont jamais ressemblé à une transaction approve() dans son historique.

Lors du nettoyage après une alerte, l'audit doit répondre à une question par token : quel contrat peut actuellement provoquer un transferFrom de ce token depuis ce portefeuille ? Parfois, c'est un dépensier direct. Parfois, c'est Permit2 car le token est approuvé au singleton et l'utilisateur continue de signer des invites aveuglément.

L'habitude qui empêche les incidents répétés est la même que celle abordée dans la manière de vérifier une transaction avant de signer : traiter chaque demande de signature comme une autorité de dépense jusqu'à preuve du contraire.

Liste de contrôle de prévention après avoir révoqué

Après la confirmation des transactions de révocation, l'objectif est d'arrêter de recréer la même exposition la prochaine fois qu'une interface de swap, de pont ou de staking demande une autorisation. La posture propre est de traiter les approbations comme une taille de position : la limite doit correspondre à l'action prévue, et non au maximum possible.

1. Préférez les approbations de montant exact lorsque l'interface le permet. Les approbations illimitées sont pratiques, mais elles sont également le mode de défaillance à impact le plus élevé si le dépensier est compromis. 2. Si une autorisation doit être modifiée d'une valeur non nulle à une autre, utilisez « approuver-à-zéro-puis-définir ». C'est une petite habitude opérationnelle qui réduit un risque de condition de course connu. 3.

Passez en revue les approbations périodiquement avec un tracker d'autorisation. Les outils mentionnés dans les conseils de sécurité des utilisateurs incluent Etherscan Token Approvals, Revoke.cash, Debank et Unrekt. 4. Traitez les invites de Permit et Permit2 comme des moments à haut risque.

Permit2 utilise des signatures EIP-712 avec des délais et des nonces, mais le phishing de signature est toujours le principal moyen par lequel les utilisateurs se font vider. 5. Gardez le modèle des « deux livres » sur le bureau : autorisations classiques et Permit2. Révoquer un dépensier aléatoire n'aide pas si le token est toujours approuvé à Permit2 et que le portefeuille continue de signer des autorisations d'un site non vérifié.

C'est ici que la discipline plus large des escroqueries de portefeuilles crypto et comment les éviter devient opérationnelle : réduire les autorisations permanentes, vérifier ce qui est signé, et payer le gaz pour fermer les anciennes lignes lorsqu'elles cessent d'être utiles.

Le point

J'ai vu des gens faire la version coûteuse de ce nettoyage : ils déconnectent un site dans leur portefeuille, se sentent en sécurité, puis se font frapper à nouveau car l'autorisation au contrat de token n'a jamais changé. La seule question qui compte est de savoir si un dépensier peut toujours appeler transferFrom sur ce token. Si la réponse est « oui », le chemin de drainage est toujours ouvert.

L'habitude qui garde cela bon marché est de traiter les approbations comme des lignes de marge. Dimensionnez-les par rapport à la transaction, et lorsque quelque chose semble suspect, révoquez d'abord les illimitées même si le gaz est moche. Si Permit2 est dans le flux depuis fin 2022, la deuxième habitude est de refuser de signer des invites EIP-712 que vous ne pouvez pas lire. C'est là que le phishing d'approbation se trouve maintenant.

Sources

• Speedrun Ethereum
• Support du portefeuille Bifrost
• Support écologique