Liquid Network : 4 000 BTC retirés via un bug d’Elements

Ce qui s’est passé

Le mécanisme. Liquid est une sidechain de Bitcoin. Les utilisateurs y déposent des bitcoin (peg-in) et reçoivent des L-BTC ; à l’inverse, un peg-out détruit des L-BTC et libère des bitcoin sur la chaîne principale depuis le portefeuille de la fédération. L’invariant central est simple : il ne doit jamais exister plus de L-BTC que de bitcoin en réserve.

6 septembre. Un bug d’Elements a permis de créer des L-BTC sans bitcoin réel en face. Ces jetons ont ensuite été convertis par un peg-out passant par la clé d’autorisation de peg-out de SideSwap. Selon les informations publiées, ni cette clé ni les systèmes de SideSwap n’ont été compromis : le problème se situait en amont, dans la création des jetons. Blockstream, qui fournit la technologie de Liquid, n’a pas détaillé la faille. Le réseau a été mis en pause.

7 septembre. Les deux parties ont communiqué par messages inscrits dans des transactions. Le groupe a exigé la correction de la faille et la mise à jour des nœuds avant toute restitution. Blockstream a répondu par un message signé confirmant le correctif sur ses nœuds de pont. Une transaction contenant un message chiffré en PGP a précédé de 38 minutes le renvoi de 3 400 BTC vers l’adresse de la fédération.

Ensuite. Environ 598,5 BTC n’ont pas été rendus. Blockstream a préparé un redémarrage coordonné et demandé de ne plus envoyer de fonds vers les adresses de peg-in d’ici là. Les autres actifs émis sur Liquid (USDT, DePix) n’ont pas été affectés. Le directeur technique de Ledger a qualifié l’épisode d’extorsion plutôt que de divulgation responsable.

La faille, sans le vocabulaire crypto

Un composant chargé de garantir une propriété de sécurité (« tout jeton est adossé à un bitcoin ») avait un défaut qui permettait de la violer. Le reste du système faisait confiance au composant et n’a pas vérifié la propriété de façon indépendante. La perte s’est comptée en heures, bien avant qu’une revue humaine ait pu la repérer.

Le même schéma existe dans des produits SaaS ordinaires :

• un système de crédits, de points ou de bons d’achat qui peut créditer un solde sans paiement associé ;
• un module de facturation qui émet un avoir sans facture d’origine ;
• une bibliothèque de génération de jetons qui produit des jetons valides sans contrôle d’identité ;
• un portefeuille ou un compte de paiement dont le solde affiché n’est jamais rapproché des fonds réels.

Les incidents Coldcard et la porte dérobée d’xz-utils relèvent de la même famille : la garantie reposait sur une brique que personne ne revérifiait.

Comment le tester dans votre produit

1. Écrire les invariants : listez les propriétés qui ne doivent jamais être violées (somme des soldes égale aux fonds encaissés, nombre de jetons émis égal aux dépôts, aucun crédit sans transaction d’origine).
2. Les vérifier indépendamment : écrivez une requête de rapprochement qui calcule chaque invariant à partir des données brutes, sans passer par le code métier. Lancez-la sur la production en lecture seule.
3. Chercher les chemins de création : listez tous les endpoints, tâches et scripts d’administration qui créent ou augmentent un solde. Pour chacun, vérifiez qu’il exige une contrepartie.
4. Tester les cas limites : avec un compte de test, rejouez une requête de crédit, envoyez des montants négatifs, des valeurs très grandes, des requêtes simultanées. Vérifiez l’invariant après chaque essai.
5. Mesurer le délai de détection : simulez un écart sur un environnement de test et mesurez combien de temps il faut pour qu’une alerte se déclenche.
6. Tester l’arrêt d’urgence : vérifiez que vous pouvez geler un flux sensible (retraits, émissions, exports) en quelques minutes, et qui a le droit de le faire.

Comment corriger

• Rapprochement automatique des invariants, en continu, avec alerte et gel automatique au-delà d’un seuil.
• Plafonds de retrait ou de création par période, qui limitent la perte maximale avant détection.
• Validation à plusieurs parties pour les mouvements importants.
• Revue de sécurité des composants auxquels vous déléguez une garantie, et suivi de leurs correctifs.
• Procédure d’incident qui traite tout acteur gardant une partie des fonds comme un attaquant.

Ce que ça change avec des agents IA

Des agents IA commencent à recevoir des outils de paiement, de remboursement ou de transfert. Un agent qui peut créditer un compte ou initier un retrait est un nouveau chemin de création de valeur, piloté par le contenu qu’il lit. Une demande de remboursement contenant une instruction cachée peut lui faire dépasser les règles métier si celles-ci ne sont appliquées que dans son prompt. Les plafonds, les invariants et la validation humaine doivent s’appliquer côté serveur, hors du modèle, comme l’illustrent aussi les méthodes du groupe Lazarus. Le Red Team Agent Express teste en cinq jours si votre agent peut être poussé à créer ou déplacer de la valeur sans contrepartie.