Le piratage de Liquid Network vide 320 millions de dollars, puis restitue la majeure partie des Bitcoin
Le piratage de Liquid Network a retiré près de 4 000 BTC du portefeuille de fédération de la sidechain le 6 septembre, soit environ 95 % de ses réserves déclarées. Les acteurs non identifiés se sont présentés comme des white hats et ont exigé un correctif logiciel avant de restituer les fonds.
Cette affirmation offrait initialement peu de réconfort. Le retrait avait déjà converti des Liquid Bitcoin apparemment non garantis en véritables bitcoin via un processus de peg-out autorisé. Liquid a suspendu l'activité du réseau, tandis que les plateformes d'échange ont interrompu les dépôts et retraits impliquant son actif adossé au Bitcoin.
La situation a ensuite évolué. Les acteurs ont restitué 3 400 BTC après que Blockstream a déclaré que les nœuds de pont concernés avaient été corrigés. Toutefois, environ 598,5 BTC, évalués à près de 47 millions de dollars au moment des faits, restaient sous leur contrôle le 8 septembre.
Il ne s'agissait pas d'une compromission du réseau Bitcoin lui-même. Il s'agissait d'une défaillance au sein de Liquid, une sidechain fédérée qui utilise des logiciels et des opérateurs désignés pour relier son actif interne à Bitcoin. Cette distinction protège la couche de base de Bitcoin de l'incident, mais elle met aussi en lumière la promesse centrale que Liquid doit désormais réparer.
Le piratage de Liquid Network a transformé un retrait valide en ponction des réserves
Le fait déterminant n'est pas simplement que des bitcoin ont été déplacés, mais que le mécanisme normal de remboursement de Liquid aurait approuvé ce mouvement.
Liquid Network a révélé qu'environ 4 000 BTC, alors évalués à près de 320 millions de dollars, avaient été retirés de son portefeuille de fédération. Avant l'incident, ce portefeuille aurait contenu environ 4 200 BTC.
Le retrait a donc soustrait près de 95 % du solde de ce portefeuille. Selon les premiers rapports sur l'incident de sécurité, Liquid a désactivé les nœuds de pont et coordonné avec les plateformes d'échange l'arrêt des dépôts et retraits de L-BTC.
Liquid Bitcoin, généralement écrit L-BTC ou LBTC, représente des bitcoin transférés sur la sidechain Liquid. La documentation de Liquid indique que chaque LBTC devrait être garanti par un montant équivalent de BTC détenu par la fédération.
Le processus de conversion est appelé un peg bidirectionnel. Un peg-in verrouille des bitcoin et crée les LBTC correspondants. Un peg-out détruit des LBTC et libère des bitcoin depuis le portefeuille de la fédération.
Les acteurs ont apparemment attaqué la comptabilité avant le retrait, plutôt que de dérober les clés de signature du portefeuille. SideSwap a déclaré que 4 000 LBTC étaient arrivés à son service de peg-out avec une autorisation valide. Le service a brûlé ces jetons, et la fédération a libéré environ 3 996 BTC vers l'adresse Bitcoin fournie.
SideSwap a indiqué que ses systèmes et sa Peg-out Authorization Key n'avaient pas été compromis. Une Peg-out Authorization Key, ou PAK, limite les retraits aux opérateurs enregistrés et aux formats de destination approuvés.
Cette distinction importe car la transaction est passée par les canaux attendus. La fédération n'a pas nécessairement constaté une demande de retrait manifestement falsifiée. Elle aurait plutôt traité des jetons qui n'auraient jamais dû exister sans collatéral correspondant.
Les acteurs non identifiés ont ensuite inséré un court message dans une transaction Bitcoin. Ils ont affirmé : « we are whitehats. contact us on chain. »
Le champ OP_RETURN de Bitcoin permet à une transaction de transporter une petite quantité de données arbitraires. Dans ce cas, il est devenu un canal de communication public entre les acteurs et Blockstream.
Blockstream a répondu avec des instructions de contact, suivies de messages chiffrés et signés cryptographiquement. Les acteurs ont ensuite déclaré qu'ils rendraient l'argent après que chaque nœud concerné aurait reçu un correctif.
Cette séquence a rendu l'exploit de Liquid Network particulièrement visible. N'importe qui pouvait examiner les transactions et les messages, alors même que l'identité et les intentions des acteurs restaient inconnues.
La ponction a donc produit deux séries d'enregistrements simultanées. Liquid et SideSwap ont décrit la réponse opérationnelle, tandis que Bitcoin a conservé le retrait, les messages ultérieurs et l'éventuelle restitution partielle.
Le logiciel a accepté des Bitcoin qui n'avaient jamais été déposés
La défaillance signalée a rompu le lien entre l'offre de LBTC et la réserve de bitcoin sans compromettre les clés de la fédération.
SideSwap a déclaré que Blockstream avait attribué l'incident à un bug dans Elements, le logiciel open source sous-jacent à Liquid. Selon ce récit, la vulnérabilité a permis aux acteurs de créer des LBTC non garantis.
Ce mécanisme attaque l'invariant le plus important de tout pont d'actifs. Un système ne doit jamais libérer davantage de son actif de réserve que les utilisateurs n'en ont auparavant verrouillé.
La documentation sur le peg de Liquid décrit un modèle strictement un pour un. Chaque LBTC devrait correspondre à des bitcoin détenus par la fédération. La destruction d'un LBTC devrait libérer un BTC.
Si un logiciel accepte une transaction invalide qui augmente l'offre de la sidechain, cette garantie échoue avant même le début du peg-out. L'attaquant peut ensuite présenter les LBTC nouvellement créés à un service de retrait légitime.
Le service de retrait voit des jetons autorisés. Il les brûle comme prévu et demande à la fédération de libérer de véritables bitcoin. Chaque composant peut sembler remplir le rôle qui lui est assigné, alors même que le résultat à l'échelle du système est invalide.
C'est le renversement central du piratage de Liquid Network. Les contrôles d'autorisation auraient fonctionné, mais ils ont autorisé une créance fondée sur une comptabilité de l'offre corrompue.
La conception multisignature du portefeuille de fédération n'a pas empêché ce résultat. Le multisignature signifie que plusieurs détenteurs de clés désignés doivent approuver une transaction avant que la réserve puisse être déplacée.
Cette disposition protège contre une clé dérobée ou un signataire malveillant. Elle ne détecte pas automatiquement une défaillance en amont du consensus ou de la validation qui présente un retrait comme légitime.
Une analyse on-chain publiée par Bitquery a retracé deux petits peg-ins avant le retrait massif. Les chercheurs ont également identifié une activité de test et des motifs cryptographiques répétés sur Liquid avant la transaction finale.
Leur reconstruction de la transaction a fait état d'un paiement de 3 996 BTC par la fédération à 14 h 28 UTC le 6 septembre. L'analyse a également documenté les messages échangés après le retrait.
Ces éléments suggèrent une préparation plutôt qu'une transaction accidentelle. Toutefois, les acteurs ne se sont pas publiquement identifiés et n'ont pas fourni de divulgation technique complète.
Certains rapports ont lié la défaillance à la validation des range proofs. Une range proof est une preuve cryptographique qu'un montant masqué dans une transaction confidentielle reste valide et ne crée pas indûment des actifs.
Liquid utilise les Confidential Transactions, qui dissimulent les actifs et les montants transférés tout en permettant aux nœuds du réseau de vérifier la validité des transactions. Une faille dans ce processus de vérification peut être particulièrement grave, car les nœuds s'appuient sur des preuves plutôt que sur des montants visibles.
La cause racine exacte nécessite encore un postmortem détaillé de Blockstream. Les informations publiques étayent la conclusion générale selon laquelle des LBTC non garantis sont entrés dans le parcours de peg-out, mais elles n'établissent pas chaque étape technique.
Cette lacune de vérification doit rester explicite. Une reconstruction plausible n'équivaut pas à une divulgation complète du fournisseur, à un correctif audité ou à une reproduction indépendante.
La sécurité de Liquid Bitcoin dépend désormais de bien plus que l'intégrité des clés. Blockstream doit montrer pourquoi les nœuds ont accepté l'état invalide, quelles versions étaient affectées et comment le correctif bloque les variantes associées.
La promesse un pour un de Liquid est désormais sous pression
L'incident met Liquid sous pression car la promesse de son produit dépend à la fois de la validation cryptographique et du jugement opérationnel de la fédération.
Liquid est conçu pour offrir un règlement plus rapide et une plus grande confidentialité des transactions que le réseau de base de Bitcoin. Il prend également en charge des actifs tels que les stablecoins et les titres tokenisés.
Ces fonctionnalités proviennent d'une blockchain distincte avec des hypothèses de confiance différentes. Les mineurs de Bitcoin ne valident pas les transactions Liquid, et les règles de consensus de Bitcoin ne garantissent pas l'offre de LBTC.
Liquid s'appuie plutôt sur une fédération de functionaries pour signer les blocs et gérer le peg bidirectionnel. D'autres participants de la fédération peuvent fournir des services, mais la sécurité du système ne reproduit pas le minage de Bitcoin.
Ce modèle n'est pas intrinsèquement défectueux. Chaque sidechain ou pont introduit des hypothèses supplémentaires en matière de logiciels, de gouvernance et de garde. Les utilisateurs acceptent ces hypothèses en échange de capacités indisponibles sur la couche de base.
L'incident a révélé comment ces hypothèses interagissent en cas de défaillance. Liquid a pu suspendre son réseau, désactiver les nœuds de pont, coordonner avec les plateformes d'échange, distribuer un correctif et négocier avec les acteurs.
Ces actions ont limité les dommages supplémentaires. Elles ont également montré que la réponse d'urgence de Liquid dépend d'opérateurs identifiables capables d'arrêter l'infrastructure et d'influer sur le mouvement des actifs.
Bitcoin lui-même n'a pas été suspendu. Ses mineurs ont continué à traiter des blocs, y compris les transactions contenant les messages des acteurs et les fonds restitués.
Ce contraste ne signifie pas que chaque application devrait fonctionner directement sur Bitcoin. Il signifie que les utilisateurs doivent distinguer la sécurité de Bitcoin de celle des actifs représentant des bitcoin ailleurs.
La vue d'ensemble technique de Liquid décrit les nœuds de pont, le matériel des functionaries, les contrôles de signature et les mécanismes de récupération d'urgence. L'architecture combine la cryptographie et la coordination institutionnelle.
La pression s'exerce désormais sur Blockstream et la fédération afin qu'ils expliquent comment ces couches ont échoué ensemble. Dire qu'aucune clé privée n'a été compromise ne répond qu'à une partie de la question.
Les utilisateurs doivent aussi savoir pourquoi les signataires ont libéré des bitcoin contre des LBTC créés de manière inappropriée. Les plateformes d'échange ont besoin de preuves que la reprise des dépôts ne peut pas les exposer à un écart d'offre non résolu.
Les émetteurs d'actifs font face à une préoccupation connexe. Liquid a déclaré que les autres actifs émis n'avaient pas été affectés, mais la suspension du réseau a tout de même interrompu l'infrastructure partagée qui les transporte.
Un actif peut rester techniquement intact tout en devenant temporairement difficile à transférer ou à rembourser. La disponibilité opérationnelle devient donc une composante de l'évaluation de la sécurité.
La récupération partielle a amélioré la position des réserves, mais n'a pas effacé l'événement. Un système présenté comme garanti un pour un a brièvement perdu la majeure partie des bitcoin soutenant cette affirmation.
Les 598,5 BTC restants soulèvent aussi une question comptable. Blockstream doit expliquer comment le montant en circulation affecte la garantie des LBTC, les passifs et tout engagement de récupération.
Un actif restitué n'annule pas la perte de disponibilité, l'incertitude du marché ou la nécessité de contrôles par les plateformes d'échange. Il ne prouve pas non plus qu'aucune vulnérabilité associée ne subsiste ailleurs.
Les opérateurs de Liquid font face à la fois à un audit technique et à un test de crédibilité. Le premier demande si le bug est corrigé. Le second demande si les utilisateurs peuvent vérifier cette réponse de manière indépendante.
Une restitution partielle ne tranche pas la question du white hat
La restitution de 3 400 BTC soutient l'intention déclarée des acteurs, mais la conservation de près de 600 BTC empêche toute conclusion nette sur leur statut de white hats.
Après que Blockstream a déclaré que ses nœuds de pont avaient été corrigés, les acteurs ont transféré 3 400 BTC vers l'adresse de la fédération. La transaction a restauré environ 85 % du montant retiré.
Un point de situation du 8 septembre sur la récupération indiquait que près de 47 millions de dollars en bitcoin restaient introuvables. Les discussions concernant ce solde se poursuivaient.
Les acteurs avaient auparavant demandé à Blockstream de corriger d’abord le bug. Ils affirmaient que tous les nœuds devaient disposer du correctif avant qu’ils ne puissent restituer les fonds en toute sécurité.
Ce message correspond à un aspect du travail de sécurité white hat. Publier ou démontrer une vulnérabilité avant sa correction peut exposer d’autres utilisateurs à des attaques par imitation.
Toutefois, une divulgation responsable conventionnelle commence normalement par un signalement privé et des tests coordonnés. Elle ne débute pas par le retrait de 95 % de la réserve d’un système sans autorisation documentée.
L’étiquette revendiquée par les acteurs constitue donc une affirmation, et non un statut professionnel vérifié. L’emploi initial par Liquid de l’expression « prétendus hackers white hat » préservait à juste titre cette incertitude.
Les fonds restants rendent la question plus aiguë. Aucun élément public examiné pour cet article n’établit que Blockstream a approuvé une prime de 598,5 BTC.
Sans une telle approbation, conserver les pièces peut s’apparenter à des frais imposés unilatéralement, à un levier de négociation ou à la détention continue d’actifs détournés. Le retour partiel ne permet à lui seul de déterminer ni le mobile ni la responsabilité juridique.
Il n’existe pas non plus d’identité publique permettant aux lecteurs d’évaluer l’expérience, l’autorisation ou les antécédents des acteurs. Une signature on-chain prouve le contrôle d’une adresse, non le caractère éthique de la personne qui la contrôle.
Cette ambiguïté a un précédent historique. En 2021, un attaquant a retiré plus de 600 millions de dollars de Poly Network avant d’en restituer la majeure partie.
Poly Network a qualifié cet attaquant de white hat et lui a proposé une prime. La couverture contemporaine de Poly Network a montré comment une restitution importante peut modifier le récit public sans éliminer les questions juridiques ou de gouvernance.
Le cas de Liquid n’est pas identique. Le mécanisme signalé, les actifs, les opérateurs et les communications diffèrent. Néanmoins, les deux incidents illustrent la rapidité avec laquelle « hacker » devient « white hat » lorsque la récupération dépend de la coopération.
Ce langage peut avoir une utilité pratique pendant les négociations. Attaquer publiquement une contrepartie coopérative pourrait réduire les chances de récupérer les fonds.
Mais la diplomatie opérationnelle ne doit pas se substituer à une qualification de sécurité. Un chercheur autorisé, un exploitant opportuniste et un maître-chanteur peuvent tous restituer des fonds pour des raisons différentes.
Les éléments utiles viendront du règlement final des BTC restants et de tout accord rendu public. Un rapport technique complet pourrait aussi préciser si les acteurs avaient tenté un contact privé antérieur.
D’ici là, la description la plus exacte reste celle de white hats autoproclamés ou prétendus. Qualifier l’opération de test de sécurité approuvé dépasserait les éléments disponibles.
L’exploit relance un vieux problème pour les ponts Bitcoin
L’architecture de Liquid diffère de celle de nombreux ponts crypto, mais la défaillance suit un schéma familier : une fausse créance a franchi la barrière menant à une réserve détenant des actifs réels.
Les systèmes cross-chain concentrent le risque parce qu’ils traduisent des activités entre des environnements soumis à des règles de sécurité différentes. Un système doit décider si un événement sur un autre système justifie la libération de valeur.
Pour Liquid, cette décision relie les LBTC de la sidechain aux BTC détenus sur Bitcoin. Le portefeuille de la fédération constitue la réserve, tandis que les règles de validation de Liquid régissent les créances correspondantes.
Le bug signalé a créé une divergence entre ces deux registres. La sidechain a accepté des LBTC sans bitcoin correspondant, puis le processus de peg-out a honoré cette fausse créance.
Un schéma économique similaire est apparu dans d’autres incidents liés aux ponts. L’exploit de Wormhole en 2022 a permis à un attaquant de créer des actifs enveloppés sans le dépôt qui aurait dû les garantir.
Le pont de Ronin a échoué par une autre voie. Les attaquants ont obtenu suffisamment de clés de validateurs pour autoriser des retraits depuis sa réserve.
Ces mécanismes diffèrent techniquement, mais ils convergent vers le même point de pression. Le pont doit préserver une relation stricte entre les créances émises et les garanties bloquées.
Les données historiques expliquent pourquoi cette frontière fait l’objet d’un examen soutenu. Chainalysis a estimé que des attaquants avaient volé 2 milliards de dollars lors de 13 piratages de ponts durant une partie de 2022.
Son analyse des risques liés aux ponts indiquait que ces incidents représentaient 69 % des cryptomonnaies dérobées cette année-là au moment de la publication. Ces chiffres décrivent 2022, et non le marché actuel, mais la leçon architecturale reste pertinente.
Les ponts accumulent des actifs à des emplacements prévisibles. Leur code de validation et leurs politiques de signature créent également des voies étroites par lesquelles d’importantes réserves peuvent circuler.
La fédération de Liquid offre un ensemble d’opérateurs plus structuré qu’un pont de smart contracts anonyme. Elle peut coordonner les mises à niveau, interrompre les services et communiquer directement avec les plateformes d’échange.
Ces avantages ont aidé la réponse. Ils n’ont pas empêché le drainage initial de la réserve, car la vulnérabilité signalée se trouvait dans la logique déterminant quelles transactions étaient valides.
Cette distinction doit orienter les futurs audits. Tester uniquement la garde des clés et les contrôles d’accès ne détectera pas les défaillances d’inflation, de validation des preuves et de cohérence d’état.
Les auditeurs devraient également tester l’intégralité du parcours de rachat. Ce parcours comprend la création d’actifs, la validation, l’autorisation, la destruction, la signature de la fédération et le paiement final sur Bitcoin.
L’exploit de Liquid Network montre pourquoi une exactitude locale ne suffit pas. SideSwap affirme que sa clé d’autorisation est restée sécurisée, mais son service valide a tout de même contribué à un résultat système invalide.
Les signataires de la fédération semblent également avoir suivi les règles attendues. Le défaut aurait modifié les informations reçues par ces règles.
Les opérateurs ont donc besoin de contrôles comparant plusieurs sources de vérité. Les changements d’offre, l’historique des peg-in, le volume des peg-out et les mouvements de réserve devraient être rapprochés avant qu’un retrait exceptionnel ne soit effectué.
Une demande unique impliquant la majeure partie des réserves devrait aussi faire l’objet d’un examen exceptionnel, même si les règles du protocole la considèrent valide. La validité logicielle et la plausibilité opérationnelle sont deux vérifications distinctes.
Cette approche introduit des frictions, que Liquid a été conçu en partie pour réduire. Ce compromis de sécurité est inévitable lorsqu’un règlement plus rapide peut faire passer presque toute une réserve par une seule voie.
Trois signaux détermineront si Liquid a contenu les dégâts
La prochaine étape dépend du bitcoin restant, d’une explication technique reproductible et d’un retour contrôlé aux opérations normales.
Le premier signal concerne les 598,5 BTC restants. Une restitution complète renforcerait le récit white hat des acteurs, même si elle n’établirait pas rétrospectivement une autorisation.
Une prime négociée pourrait également régler le solde, mais uniquement si Blockstream divulgue suffisamment d’informations pour distinguer un accord d’une rétention unilatérale. Un silence prolongé ou un déplacement vers des adresses sans rapport affaiblirait l’interprétation white hat.
Le deuxième signal sera le rapport technique post-mortem de Blockstream. Il devrait identifier les versions vulnérables d’Elements, la règle de validation défaillante, le parcours de transaction affecté et la protection précise apportée par le correctif.
Une divulgation utile devrait également expliquer si des développeurs indépendants ont reproduit le bug. La reproduction est importante, car une description fermée laisse les utilisateurs dépendants de la même organisation dont le logiciel a échoué.
Le rapport devrait aborder le moment de la détection. L’analyse publique des transactions suggère qu’une activité préparatoire a précédé le principal peg-out, soulevant des questions sur la surveillance et les seuils d’anomalie.
Le troisième signal concerne le processus de redémarrage de Liquid. Les plateformes d’échange et les utilisateurs ont besoin d’un parcours clairement défini pour les dépôts, les retraits et la vérification des réserves avant la reprise de l’activité courante.
Redémarrer les nœuds du pont n’équivaut pas à restaurer la confiance. Les opérateurs doivent rapprocher l’offre de LBTC des bitcoins détenus par la fédération après le retour partiel.
Ils doivent également expliquer comment le déficit restant est couvert. Cette réponse déterminera si les détenteurs supportent une exposition résiduelle ou si une autre partie l’absorbe.
Un redémarrage prudent inclurait des vérifications de version sur l’ensemble des functionaries et des nœuds du pont. Il fournirait aussi une confirmation visible que les logiciels obsolètes ne peuvent pas se reconnecter au réseau de production.
La question plus large de la sécurité de Liquid Bitcoin subsistera après la reprise des services. La fédération devra démontrer qu’elle a ajouté des défenses contre le défaut divulgué comme contre des défaillances de validation comparables.
Pour les développeurs, la leçon consiste à suivre les garanties de sécurité à travers les frontières entre composants. Une clé protégée ne peut pas sauver un système qui autorise la mauvaise transaction.
Pour les plateformes d’échange, la leçon est de surveiller les garanties de manière indépendante. L’apparence normale d’un token ne garantit pas que son lien avec la réserve reste intact.
Pour les détenteurs d’actifs, la question immédiate est plus simple. Ils devraient surveiller les avis officiels de service, les données de réserve et l’état des retraits sur les plateformes avant de considérer l’incident comme clos.
Le retour partiel a transformé une perte catastrophique en crise récupérable. Il n’a pas, à lui seul, rétabli la promesse d’un rapport un pour un.
Le piratage de Liquid Network ne sera contenu que lorsque le solde restant sera réglé, que le bug sera compris de manière indépendante et que les retraits normaux reprendront sur des réserves rapprochées. Tant que ces conditions ne seront pas visibles, « la plupart des fonds ont été restitués » restera une mise à jour, pas une conclusion.
