Voir la table des matières Ne plus voir la table des matières
Un portefeuille multisignature est censé être l’inverse d’un point de défaillance unique : plusieurs personnes doivent approuver chaque transaction pour qu’elle parte, de sorte qu’aucune clé volée ne suffise à vider les caisses. C’est exactement le dispositif que la plateforme indienne WazirX avait mis en place, avec un partenaire spécialisé dans la garde d’actifs numériques, Liminal, en position d’ultime contrôleur.
Le 18 juillet 2024, ce portefeuille a pourtant été siphonné de quelque 230 millions de dollars en bitcoin, ether et stablecoins. Dans les heures qui ont suivi, WazirX et Liminal ont publié chacun leur version, et chacune désignait l’autre. Comment un mécanisme conçu pour rendre le vol impossible a-t-il pu être franchi sans qu’aucun des six signataires ne s’en aperçoive ?
Quatre signatures sur six, et un arbitre final
Le portefeuille compromis fonctionnait en 4 sur 6 : six signataires étaient enregistrés, quatre approbations étaient nécessaires pour exécuter une transaction. Cinq signataires appartenaient à l’équipe de WazirX, chacun opérant depuis un portefeuille matériel Ledger, ce qui plaçait les clés hors de portée d’une compromission purement en ligne. Le sixième était Liminal.
La chaîne d’approbation n’était pas symétrique. Trois signataires de WazirX devaient d’abord valider l’opération, puis Liminal contrôlait sa conformité aux règles définies par le client avant de donner l’approbation finale et de l’exécuter. Une politique de liste blanche complétait le tout : les fonds ne pouvaient partir que vers des adresses préalablement approuvées, configurées et gérées depuis l’interface de Liminal. Le principe même de la multisignature voulait que cette architecture rende une fuite unilatérale impossible.
La discordance que WazirX met en avant
La plateforme a publié une autopsie quelques heures après l’attaque. Son explication tient en une phrase technique : il existait « une incompatibilité entre les informations affichées sur l’interface de Liminal et ce qui était réellement signé ». Autrement dit, les signataires croyaient valider une opération banale pendant que leurs appareils apposaient leur signature sur tout autre chose.
Ce que cette formulation implique est lourd. Un portefeuille matériel protège la clé privée, pas le jugement de son porteur : il signe fidèlement ce qu’on lui présente, et son petit écran ne suffit pas toujours à décoder une transaction complexe. La protection matérielle devient alors inopérante si l’interface qui prépare la transaction ment sur son contenu.
WazirX a par ailleurs insisté sur un point de responsabilité : le portefeuille concerné « était exploité en utilisant les services de garde d’actifs numériques et d’infrastructure de portefeuille de Liminal à partir de février 2023 ». La mention de la date n’est pas anodine : elle place l’outil incriminé dans le périmètre contractuel du prestataire depuis un an et demi.
La réponse de Liminal, et ce qu’elle contourne
Le prestataire de garde a répliqué par un communiqué plus court, dans lequel il déplace le cadre. Le portefeuille compromis aurait été « créé en dehors de l’écosystème Liminal », sa plateforme n’aurait pas été piratée, et son infrastructure comme ses actifs resteraient sécurisés. Liminal ajoute que les transactions malveillantes ont eu lieu hors de sa plateforme, formule qui met à distance sans rien expliquer.
Cette défense laisse une zone d’ombre béante. Si le signataire de Liminal a bien apposé la quatrième signature, celle qui débloque l’exécution, alors la transaction malveillante a franchi le pare-feu et la liste blanche que le prestataire vend précisément comme sa valeur ajoutée. Dire que l’attaque venait de l’extérieur n’explique pas pourquoi le contrôle interne l’a laissée passer.
Les clients ne s’y sont pas trompés. Le renvoi de responsabilité publié à chaud, alors que les fonds étaient déjà partis et que les retraits venaient d’être gelés, a été reçu comme une manœuvre de communication plutôt que comme une explication technique.
Huit jours de répétition avant le passage à l’acte
L’élément le plus instructif ne vient d’aucune des deux entreprises. Mudit Gupta, responsable de la sécurité des systèmes d’information de Polygon Labs, a analysé la chaîne publiquement dès le jour de l’attaque. Selon lui, les assaillants s’entraînaient depuis au moins huit jours, sur des contrats de test qu’ils avaient déployés eux-mêmes, avant d’exécuter le scénario sur WazirX.
Le mode opératoire retenu éclaire les moyens réels des attaquants. Plutôt que de transférer directement les fonds, ils ont fait passer une mise à jour du portefeuille vers une version malveillante qui n’exigeait plus aucune signature, puis ont vidé le contrat.
Vider le portefeuille prend du temps et plusieurs transactions. Ils n’avaient probablement pas accès à toutes les clés privées requises et dépendaient du hameçonnage de signature, qu’ils ne peuvent pas répéter plusieurs fois sans se faire repérer.
Mudit Gupta, responsable de la sécurité des systèmes d’information de Polygon Labs, publication sur X du 18 juillet 2024 analysant le déroulé de l’attaque
Ce raisonnement est le cœur du dossier. Un attaquant qui détiendrait toutes les clés n’aurait aucune raison de s’infliger la complexité d’un changement d’implémentation : il attendrait une période creuse et transférerait. Le détour par la mise à jour trahit une capacité partielle, obtenue par tromperie de signature plutôt que par vol de clés.
Les questions que le duel laisse sans réponse
Le débat public s’est cristallisé sur la répartition des torts, ce qui a détourné l’attention des points réellement décisifs. Plusieurs restent ouverts à ce stade de l’enquête.
- L’interface consultée par les signataires était-elle compromise, ou les postes de travail de WazirX l’étaient-ils ;
- pourquoi le pare-feu et la liste blanche de Liminal n’ont pas identifié la mise à jour comme anormale ;
- comment trois signataires distincts ont pu valider la même opération sans qu’aucun ne détecte l’écart ;
- quelle part des fonds reste traçable après un blanchiment engagé dans les minutes suivant le vol.
La signature de l’attaque oriente les soupçons vers le groupe Lazarus, structure nord-coréenne déjà mise en cause dans le détournement du réseau Ronin. La préparation longue, l’exécution en quelques minutes et le blanchiment immédiat correspondent à un mode opératoire documenté.
WazirX, de son côté, n’a rien dit de l’impact du vol sur ses opérations, se bornant à affirmer qu’elle surmonterait ce défi et en sortirait plus forte et plus résiliente.
Ce que la garde déléguée coûte vraiment
Le dossier WazirX rejoint la longue série des vols records sur les plateformes, mais il s’en distingue par un détail : rien n’a cédé techniquement. Les clés n’ont pas fuité, le matériel a fonctionné, la multisignature a fait ce pour quoi elle était programmée. C’est la couche humaine et logicielle intermédiaire qui a rompu, celle que personne n’audite parce qu’elle est censée être l’auditeur.
Déléguer la garde à un tiers spécialisé revient à échanger un risque contre un autre. On se débarrasse du risque de conservation en interne, on acquiert celui de dépendre d’un prestataire dont on ne contrôle ni le code de l’interface, ni la configuration du pare-feu, ni la discipline des équipes. Le partage des responsabilités écrit dans un contrat ne survit pas toujours à sa première mise à l’épreuve, et le spectacle offert par WazirX et Liminal en donne la mesure. La question qui se pose désormais à toute plateforme dépeint mal une réponse simple : qui vérifie le vérificateur, et à quel moment.
