L’exploit de DotSwap V1 entraîne la perte d’environ 8,5 BTC, pour un préjudice estimé à 685 000 dollars
L’exploit de DotSwap V1 entraîne la perte d’environ 8,5 BTC, pour un préjudice estimé à 685 000 dollars
Le 25 octobre, l’ancienne version de la plateforme de trading DotSwap, DotSwap V1, a été victime d’une attaque ayant entraîné le vol d’environ 8,5 BTC, soit près de 685 000 dollars au moment des faits.
Cet incident met en lumière un problème de sécurité grandissant au sein des applications reposant sur Bitcoin : même lorsque les utilisateurs interagissent avec des actifs décentralisés, les systèmes d’autorisation backend, les infrastructures de liquidité custodiales et les services de signature automatisée peuvent créer des points de défaillance centralisés.
Selon une mise à jour publiée par On Nexus au sujet de l’incident, la plateforme concernée a été mise hors ligne le temps que l’équipe enquête sur l’attaque, retrace les fonds volés et collabore avec des plateformes d’échange ainsi qu’avec des partenaires spécialisés dans l’analyse de la blockchain.
Que s’est-il passé sur DotSwap V1 ?
DotSwap V1 reposait sur un modèle de signature côté serveur pour gérer ses pools de liquidité. Son infrastructure de liquidité fonctionnait au moyen d’un dispositif multisignature custodial : les BTC déposés étaient donc contrôlés par le processus de signature de la plateforme, et non directement par chaque fournisseur de liquidité.
L’attaquant aurait exploité un ancien mécanisme de signature qui était toujours actif dans le backend de la version V1. Pendant environ quatre heures, des scripts automatisés ont interagi avec les interfaces disponibles de la plateforme et transféré progressivement des fonds depuis les pools de liquidité et les comptes utilisateurs de V1.
L’attaque ne s’est pas limitée à un seul token ou à un endpoint unique. Les scripts auraient testé les interfaces de la plateforme et ciblé des actifs associés à 99 tokens Runes, permettant à l’attaquant d’identifier et d’exploiter des failles dans un environnement applicatif plus vaste.
Le montant total des pertes est estimé à environ :
- 8,5 BTC volés
- Près de 685 000 dollars de fonds concernés
- Dépôts des fournisseurs de liquidité sur DotSwap V1 touchés
- Portefeuilles contrôlés par les utilisateurs en dehors de la plateforme non affectés
DotSwap V1 a depuis été fermée. On Nexus a indiqué travailler au rétablissement des services concernés et publier une analyse post-incident plus complète, ainsi qu’un plan destiné aux utilisateurs affectés.
Pourquoi les fournisseurs de liquidité ont-ils été les principales victimes ?
La distinction la plus importante dans cet incident concerne la différence entre les fonds gérés par la plateforme et les actifs conservés dans le portefeuille personnel d’un utilisateur.
Les fournisseurs de liquidité qui avaient déposé des BTC dans DotSwap V1 étaient exposés à l’architecture de conservation et de signature de la plateforme. Même si le système reposait sur des contrôles multisignatures, le processus de signature restait connecté à des services backend pouvant être interrogés et déclenchés via les interfaces applicatives.
La multisignature, à elle seule, n’a donc pas suffi à éliminer les risques opérationnels. Si la logique d’autorisation, les permissions des API, les politiques de signature ou les contrôles côté serveur sont mal conçus, un attaquant peut toujours trouver un moyen de générer des transactions valides.
À l’inverse, les utilisateurs qui conservaient leurs actifs dans des portefeuilles auto-hébergés et ne les avaient pas déposés dans les pools de V1 n’ont pas été affectés par l’incident. Leurs clés privées sont restées en dehors de l’environnement compromis de la plateforme.
Cette distinction est essentielle pour comprendre les risques liés aux pools de liquidité :
Un protocole peut utiliser la blockchain pour régler les transactions tout en dépendant d’une infrastructure centralisée pour la conservation, la signature, la tarification, le routage ou le contrôle des accès.
Les utilisateurs doivent donc évaluer non seulement si une application est « on-chain », mais aussi où se trouve l’autorité de signature, qui contrôle les droits de retrait et si les fonds déposés peuvent être gelés ou redirigés par un système backend.
Un exemple possible d’automatisation d’attaque assistée par l’IA
On Nexus a décrit l’incident comme s’inscrivant dans une tendance récente marquée par les attaques pilotées par l’IA ou fortement automatisées.
L’automatisation peut accroître considérablement la vitesse et l’ampleur d’un exploit. Plutôt que de tester manuellement une fonction après l’autre, un attaquant peut programmer :
- La découverte des endpoints d’API exposés
- L’envoi d’un grand nombre de requêtes
- La comparaison des réponses obtenues pour différents actifs
- La détection de comportements incohérents en matière d’autorisation
- L’identification de chemins inhabituels de signature ou de retrait
- L’exécution de transactions à très grande vitesse
Dans un environnement prenant en charge des dizaines de contrats de tokens et de routes de trading, l’automatisation facilite l’identification de petites différences d’implémentation qui pourraient passer inaperçues lors de tests manuels classiques.
La leçon générale est que les équipes de sécurité doivent désormais se préparer à des attaques combinant les scripts traditionnels avec des agents d’IA toujours plus performants. La découverte d’API, la classification des vulnérabilités, la construction des transactions et la surveillance peuvent toutes être accélérées par des outils automatisés.
Cette évolution rend de plus en plus importants la limitation du débit, l’isolation des endpoints, la détection des anomalies, l’application stricte des politiques de signature et la surveillance en temps réel des transactions sur les plateformes d’actifs numériques.
Ce que révèle l’incident sur l’infrastructure des Runes
L’écosystème Runes a élargi la gamme d’actifs fongibles pouvant être émis et échangés sur Bitcoin. Toutefois, l’infrastructure qui prend en charge ces actifs est encore en développement, et de nombreuses applications reposent sur une combinaison d’indexeurs, de services hors chaîne, de pools custodiaux et de mécanismes de trading spécialisés.
Cette configuration crée plusieurs zones de risque :
- Dépendance aux indexeurs : les soldes des portefeuilles et l’état des tokens peuvent dépendre de services d’indexation tiers.
- Autorisation backend : une plateforme peut utiliser des API centralisées pour déterminer si une transaction peut être signée.
- Liquidité custodiale : les utilisateurs peuvent déposer des BTC dans des portefeuilles mutualisés gérés par l’application.
- Complexité des contrats et des actifs : la prise en charge de nombreux actifs Runes augmente le nombre de routes, d’interfaces et de cas particuliers à tester.
- Concentration opérationnelle : la compromission d’un seul service de signature peut affecter plusieurs pools simultanément.
Les utilisateurs qui s’intéressent au trading de Runes ou à la fourniture de liquidité devraient examiner le modèle de conservation d’un projet avant d’y déposer des fonds. L’interface d’une plateforme peut sembler décentralisée alors que des fonctions essentielles de contrôle restent centralisées.
Pour obtenir davantage d’informations sur l’écosystème des actifs Bitcoin, les utilisateurs peuvent consulter la documentation destinée aux développeurs Bitcoin ainsi que la newsletter Bitcoin Optech, qui traite régulièrement des évolutions des protocoles, des portefeuilles et de l’infrastructure Bitcoin.
Leçons pratiques de sécurité pour les utilisateurs de cryptomonnaies
1. Vérifiez si les fonds restent sous votre contrôle
Avant de fournir de la liquidité ou de déposer des actifs, déterminez si la plateforme peut déplacer les fonds sans qu’une transaction soit signée directement depuis votre portefeuille.
Voici quelques questions à se poser :
- Les dépôts sont-ils envoyés vers une adresse contrôlée par l’utilisateur ou par la plateforme ?
- Qui détient les clés privées ?
- La signature est-elle effectuée localement, via un appareil matériel ou sur un serveur ?
- Les administrateurs peuvent-ils suspendre les retraits ou modifier les règles de signature ?
- Les limites de retrait et les dispositifs de surveillance sont-ils documentés publiquement ?
Les réponses peuvent modifier sensiblement le profil de risque du service.
2. Considérez les anciens produits comme des surfaces d’attaque potentielles
L’incident de DotSwap V1 montre pourquoi les anciennes versions d’une plateforme ne doivent pas rester connectées aux services actifs. Même si une nouvelle version dispose de contrôles renforcés, des API obsolètes, d’anciens chemins de signature ou des permissions de compte toujours actives peuvent rester exploitables.
Les projets devraient désactiver complètement les produits retirés en :
- Révoquant les identifiants d’API
- Supprimant les anciennes permissions de signature
- Désactivant les endpoints inutilisés
- Renouvelant les clés de service
- Séparant les bases de données historiques des systèmes de production
- Surveillant l’ancienne infrastructure afin de détecter toute activité inhabituelle
3. Évitez de concentrer vos actifs sur une seule application
Les fournisseurs de liquidité devraient envisager de diversifier leurs avoirs entre plusieurs portefeuilles, protocoles et modèles de conservation. Concentrer une grande quantité de BTC sur une seule application peut amplifier l’impact d’un exploit ou d’une défaillance opérationnelle.
Cette approche n’élimine pas le risque lié aux protocoles, mais elle peut réduire la probabilité qu’un incident unique affecte l’ensemble d’un portefeuille.
4. Surveillez l’activité de vos portefeuilles et les autorisations
Les utilisateurs devraient vérifier régulièrement les soldes de leurs portefeuilles, les applications connectées, les sessions ouvertes et l’historique des transactions. Les demandes de signature inattendues, les adresses de retrait inconnues ou les nouvelles connexions depuis un appareil inhabituel doivent être considérées comme des signaux d’alerte potentiels.
Pour les transactions de montant élevé, les utilisateurs devraient vérifier eux-mêmes :
- L’adresse de destination
- L’actif et le montant
- Le réseau
- Les frais de transaction
- Le domaine de l’application
- Les détails définitifs de la transaction affichés par le portefeuille
5. Comprenez que la multisignature n’est pas synonyme de décentralisation complète
Les dispositifs multisignatures peuvent renforcer la résilience, mais leur efficacité dépend de la répartition des signataires et de la manière dont les autorisations sont appliquées.
Si tous les signataires sont contrôlés par la même organisation, connectés au même backend ou soumis au même moteur de politiques défectueux, le système peut malgré tout présenter un point de défaillance centralisé important.
La sécurité dépend de l’ensemble de l’architecture de signature, et pas simplement de la présence de plusieurs signatures.
Ce que doivent surveiller les utilisateurs concernés
Les utilisateurs connectés à DotSwap V1 doivent se méfier des messages d’hameçonnage prétendant proposer un remboursement, une compensation ou un outil de retrait d’urgence. Les attaquants profitent souvent des incidents rendus publics pour usurper l’identité des équipes des projets et rediriger les victimes vers de faux sites.
Les utilisateurs concernés devraient :
- Suivre uniquement les canaux de communication vérifiés du projet
- Ne jamais saisir leur phrase de récupération ou leurs clés privées sur un site web
- Considérer comme suspect tout formulaire de remboursement non sollicité
- Conserver les identifiants de transaction et les justificatifs de dépôt
- Vérifier les informations directement sur la blockchain
- Surveiller les adresses de portefeuille associées afin de détecter tout mouvement
- Attendre la mise en place d’une procédure officielle de récupération ou de réclamation avant de signer quoi que ce soit
Une équipe d’assistance légitime ne demandera jamais la phrase de récupération d’un portefeuille pour vérifier sa propriété ou traiter un remboursement.
Pour obtenir des conseils généraux sur la protection des actifs numériques, le guide de cybersécurité de la CISA fournit des informations utiles sur l’hameçonnage, la sécurité des comptes et les activités malveillantes.
Les implications plus larges pour la DeFi et les applications Bitcoin
L’exploit de DotSwap V1 ne raconte pas seulement l’histoire d’une plateforme vulnérable. Il reflète une tension plus large dans le secteur des cryptomonnaies : les applications peuvent présenter aux utilisateurs une interface décentralisée tout en reposant, en coulisses, sur des composants centralisés.
À mesure que les applications financières basées sur Bitcoin gagnent en maturité, les audits de sécurité devront couvrir davantage que le simple code des smart contracts. Ils devront également examiner :
- L’authentification et l’autorisation des API
- Les services de signature côté serveur
- La gestion des clés et l’isolation des signataires
- Les permissions des bases de données
- Les systèmes d’indexation des actifs
- Les procédures de mise à niveau et d’arrêt
- La surveillance et la réponse aux incidents
- Les mécanismes de retrait d’urgence
En 2025, le recours croissant aux agents automatisés et au développement assisté par l’IA rend ce processus d’évaluation encore plus important. L’accélération du développement logiciel et des interactions automatisées peut élargir la surface d’attaque si les contrôles de sécurité n’évoluent pas au même rythme.
Pour les utilisateurs, la meilleure protection reste une compréhension claire du modèle de conservation. Les actifs détenus directement dans un portefeuille auto-hébergé sont exposés à des risques différents de ceux déposés dans un pool contrôlé par une plateforme. Aucun modèle n’est exempt de risques, mais leur origine est sensiblement différente.
La place des portefeuilles matériels dans une stratégie d’auto-conservation plus sûre
Un portefeuille matériel peut contribuer à réduire l’exposition aux compromissions côté serveur en conservant les clés privées à l’écart des applications connectées à Internet. Lorsqu’ils interagissent avec des applications décentralisées, les utilisateurs peuvent examiner et approuver les détails d’une transaction depuis un appareil de signature dédié, plutôt que de s’en remettre uniquement à l’interface d’un navigateur.
Les portefeuilles matériels OneKey sont conçus pour les usages reposant sur l’auto-conservation, notamment la protection hors ligne des clés et la confirmation des transactions directement sur l’appareil. Ils n’éliminent ni les risques liés aux smart contracts, ni l’hameçonnage, ni les interfaces malveillantes, ni la volatilité des marchés. Ils peuvent toutefois aider les utilisateurs à conserver le contrôle des actifs qu’ils ne souhaitent pas déposer intentionnellement sur des plateformes custodiales ou dans des pools de liquidité.
Le principe essentiel est simple : avant de fournir de la liquidité ou d’autoriser une transaction, les utilisateurs doivent comprendre qui contrôle les fonds, ce qu’ils signent et si la plateforme peut déplacer les actifs sans leur approbation directe.
La perte d’environ 8,5 BTC subie par DotSwap V1 rappelle pourquoi l’architecture de conservation, les permissions de signature et la sécurité opérationnelle méritent autant d’attention que l’utilité d’un token ou le volume des échanges. Dans un environnement crypto de plus en plus automatisé, une auto-conservation maîtrisée et une vérification rigoureuse des transactions restent des défenses essentielles.
