Comment lire une transaction avant de la signer

Deux des plus grandes pertes de notre Registre des incidents partagent un même mécanisme, et ce n’est pas celui auquel on s’attend. Personne n’a deviné de clé. On a montré une transaction aux signataires et ils en ont approuvé une autre.

Ce guide porte sur l’écart entre ce qu’un site web annonce qu’une transaction va faire et ce que la transaction fait réellement — et sur l’écran qui tranche ce désaccord.

Pourquoi cet écart existe

Lorsque vous interagissez avec une application web qui souhaite faire signer une transaction, plusieurs choses se produisent en même temps. La page construit une transaction. Votre portefeuille la reçoit. Votre portefeuille — ou un appareil matériel connecté — en affiche une représentation. Vous approuvez.

La description que vous lisez sur la page est rédigée par la page. C’est un argumentaire commercial pour la transaction. Elle n’est pas dérivée de la transaction, et rien n’oblige les deux à concorder.

Dans l’incident Bybit, la défaillance rapportée était exactement celle-ci : un transfert de routine dont la charge utile exécutée différait de ce qu’affichait l’interface de signature. Env. 1,5 milliard de dollars américains ont été déplacés, selon l’annonce du FBI lui-même. Plusieurs signataires ont approuvé. Chacun a vu la même représentation erronée, si bien qu’en avoir plusieurs n’a rien apporté.

La hiérarchie des écrans

Tous les affichages ne méritent pas la même confiance. Par ordre décroissant :

1. L’écran propre à un portefeuille matériel. Il est généré par l’appareil à partir de la transaction qu’on lui a réellement demandé de signer. C’est l’élément de la chaîne le plus difficile à influencer pour une page web compromise — et c’est exactement la raison pour laquelle l’appareil possède un écran.
2. La fenêtre de confirmation de votre logiciel de portefeuille. Mieux que la page, mais elle s’exécute sur la même machine et, dans le cas d’une extension de navigateur, dans un environnement que la page partage.
3. La description de la page web. Utile pour comprendre l’intention. Sans valeur comme vérification.

La compromission de Ledger Connect Kit illustre le point avec précision. Du code malveillant a été injecté dans une bibliothèque chargée par de nombreuses applications décentralisées, et il présentait aux utilisateurs une transaction de siphonnage. Les utilisateurs qui lisaient l’écran de l’appareil avant d’approuver pouvaient voir un transfert qu’ils n’avaient pas demandé. Ceux qui confirmaient d’après la description de la page ne le pouvaient pas.

Ce qu’il faut réellement examiner

Sur l’écran de l’appareil, pour un transfert :

• L’adresse de destination — en entier, pas les quatre premiers et quatre derniers caractères. Les attaques par empoisonnement d’adresse fonctionnent précisément en produisant des adresses dont les extrémités correspondent à une adresse que vous avez déjà utilisée.
• Le montant et l’actif. Confirmez les deux, y compris la position de la virgule décimale.
• Le réseau. La bonne transaction sur la mauvaise chaîne reste une perte.

Pour une interaction avec un contrat :

• La fonction appelée, lorsque l’appareil peut la décoder. Un approve, setApprovalForAll ou permit inattendu alors que vous pensiez jalonner ou réclamer est le signal qu’il faut s’arrêter.
• L’adresse dépensière ou opératrice dans une autorisation : c’est l’adresse que vous autorisez — pas le contrat que vous croyez utiliser.
• Les avertissements de signature à l’aveugle. Si l’appareil indique qu’il ne peut pas décoder ce qu’on lui demande de signer, c’est une information, pas un obstacle.

La confirmation par un canal distinct

Pour tout ce qui a des conséquences, confirmez la destination par un canal autre que celui qui propose la transaction. Si une page fournit une adresse et que la même page confirme que cette adresse est correcte, vous n’avez rien vérifié. C’est la version organisationnelle du même contrôle : si les procédures de transfert de montants importants exigent une confirmation par une voie distincte, c’est parce qu’un canal compromis à lui seul peut être parfaitement cohérent avec lui-même.

Ce contre quoi cela ne vous protège pas

• Une autorisation que vous avez déjà accordée. Lire attentivement vos transactions à partir d’aujourd’hui ne change rien à une allocation permanente accordée l’an dernier. Voir comment vérifier vos autorisations.
• Une phrase de récupération compromise. Aucun soin apporté au moment de la signature n’aide si quelqu’un d’autre peut reconstituer le compte.
• Un protocole lui-même défaillant. Une transaction parfaitement légitime vers un contrat vulnérable reste exposée à cette vulnérabilité. La plupart des incidents de notre registre concernent des utilisateurs qui ont signé exactement ce qu’ils voulaient.
• La lassitude. C’est la vraie limite. Personne ne lit la centième autorisation de routine avec le soin apporté à la première, et les attaques sont conçues autour de cela.

Le résumé honnête

Lire ce que vous signez est le seul contrôle qui aurait évité plusieurs des pertes que nous consignons, et il est aussi véritablement difficile à tenir dans la durée. Traitez-le de manière proportionnée : les petites interactions de routine n’exigent aucun cérémonial, et toute transaction dont la perte compterait pour vous mérite l’écran de l’appareil, l’adresse complète et un temps d’arrêt.