Backend supply chain de BigONE

Le 16 juillet 2025, l'échange de cryptomonnaies BigONE a perdu environ 27 millions de dollars depuis son hot wallet — mais dans un schéma technique inhabituel, aucune clé privée n'a été exposée. Au lieu de cela, les attaquants ont compromis l'infrastructure backend de l'échange et réécrit la logique de contrôle des risques afin que les propres systèmes de l'échange approuvent automatiquement toute demande de retrait que les attaquants émettaient.

Ce qui s'est passé

Les compromissions d'échanges traditionnelles suivent l'un des deux schémas :

1. Vol de clé privée — l'attaquant obtient l'autorité de signature sur les wallets et les draine.
2. Vol d'API/identifiants — l'attaquant utilise des interfaces programmatiques autorisées avec des droits de signature complets ou partiels.

BigONE n'était ni l'un ni l'autre. Les attaquants ont obtenu l'accès à l'infrastructure backend de l'échange (probablement via une compromission de la chaîne d'approvisionnement d'une dépendance, d'un système de build ou d'un pipeline CI/CD). Depuis l'intérieur du backend, ils ont modifié le code qui gouvernait la validation des comptes et la logique de contrôle des risques de BigONE — remplaçant les vérifications légitimes d'approbation de retrait par du code qui approuvait automatiquement toute demande de retrait correspondant à des critères contrôlés par l'attaquant.

Les systèmes de signature de l'échange ont alors traité les retraits malveillants via le chemin de signature normal, en utilisant les clés privées légitimes — parce que, du point de vue du système de signature, les retraits avaient été dûment autorisés par la logique (compromise) de contrôle des risques.

Total drainé : ~27 M$ sur plusieurs chaînes, avant que BigONE ne détecte l'anomalie et n'arrête les retraits.

Conséquences

• BigONE a couvert toutes les pertes clients depuis son fonds de réserve d'assurance.
• Programme de prime annoncé : jusqu'à 8 millions de dollars en récompenses pour aide à l'identification des attaquants ou à la récupération des fonds.
• L'échange a mis en pause les retraits le temps de restaurer l'intégrité du backend et de ré-auditer l'infrastructure.
• Aucune attribution publique à un acteur de menace spécifique ; le schéma de chaîne d'approvisionnement correspond à plusieurs opérations récentes ciblant les fournisseurs d'infrastructure d'échange.

Pourquoi c'est important

L'incident BigONE est l'un des cas les plus clairs de pourquoi le code backend fait partie de la frontière de confiance de la garde. Les clés de signature d'un échange peuvent être en cold storage ; ses HSMs peuvent être parfaitement configurés ; ses clés API peuvent avoir des limites de vélocité strictes — et toutes ces protections peuvent être contournées en réécrivant le code qui décide quelles actions de signature autoriser.

La leçon structurelle, de plus en plus centrale pour la sécurité des échanges en 2025 :

• Les contrôles d'intégrité du code (déploiements signés, vérification cryptographique des binaires en cours d'exécution, infrastructure immuable) sont aussi importants que les contrôles de gestion de clés.
• Les changements de code backend privilégiés doivent être soumis à la même discipline d'approbation que les opérations de wallet — revue multi-parties, vérification hors bande, traces d'audit.
• Le risque de la chaîne d'approvisionnement s'étend au-delà des relations vendeurs explicites à chaque dépendance, outil de build et environnement de développement touchant le code de production.

La réponse de BigONE — fonds d'assurance + prime + politique de client indemne — est ce sur quoi l'industrie s'est arrêtée comme réponse minimale crédible à une compromission majeure d'échange. Leçon au niveau classe d'actifs : la confiance en un échange est, en 2025, fonction de comment il répond à des incidents comme celui-ci, plus que du fait qu'il en ait.