L’incident Binance à 6,3 milliards de dollars : ce qui s’est passé et comment réduire le risque

Les premières conclusions de Binance décrivent des compromissions d’ordinateurs d’employés en juin et en septembre, suivies d’une intrusion plus large via des outils internes d’IA le 20 octobre. Les attaquants ont atteint les ordinateurs de deux collègues et trouvé un jeton de déploiement de conteneurs. Le 29 octobre, ils l’ont utilisé pour déployer un code malveillant qui a atteint les systèmes de signature des portefeuilles et déclenché des transferts non autorisés.

Les attaquants ont aussi utilisé le service de signature pour créer une délégation EIP-7702, c’est-à-dire une permission permettant à un code qu’ils contrôlaient d’agir pour un portefeuille Ethereum. Cette permission existait sur la blockchain, indépendamment des systèmes de retrait de Binance. Suspendre les retraits ne pouvait pas la supprimer. Binance devait la révoquer séparément sur la chaîne.

Il faut distinguer l’arrêt d’une activité de la suppression de l’autorité qui la permet. Remplacer un appareil, révoquer un identifiant de déploiement et annuler une permission dans un autre système répondent chacun à une partie différente de l’intrusion.

Un ordinateur portable, un système de déploiement et un service sensible remplissent des fonctions différentes. Le risque augmente lorsque l’accès à l’un ouvre automatiquement le suivant. Un jeton volé peut permettre à un attaquant de remplacer un logiciel. Celui-ci peut ensuite agir avec des permissions que l’employé n’a jamais détenues directement.

Quatre questions permettent de repérer où interrompre cette progression :

1. Exposition des identifiants. Quels accès à la production un attaquant peut-il obtenir depuis l’appareil d’un employé ?
2. Privilèges de déploiement. Qui peut modifier le code exécuté avec ces accès ?
3. Autorisation du service. Quelles actions un service sensible acceptera-t-il de ce code ?
4. Accès persistant. Quelles nouvelles permissions pourraient subsister après la désactivation du compte d’origine ?

L’objectif est de limiter la transmission de l’autorité entre les systèmes, puis d’identifier et de révoquer tout accès supplémentaire créé pendant une intrusion. Les sections suivantes examinent quatre contrôles qui contribuent à cet objectif.

Contrôle 1. Réduire les identifiants qu’un ordinateur portable peut exposer

Un identifiant est utile à un attaquant parce qu’un autre système l’accepte comme preuve d’autorité. Conserver moins d’identifiants de production sur les appareils des employés réduit ce qui peut être volé lorsqu’un outil, un dépôt ou une session de navigateur est compromis.

Pour les opérations courantes, un employé a souvent besoin de l’autorisation de demander une opération, comme le redémarrage d’un service. L’identifiant qui l’exécute peut rester associé à une identité d’exécution distincte. Réduire l’exposition implique donc à la fois de supprimer les copies inutiles et de gérer les identifiants restants :

• Remplacez les accès directs courants par des opérations précisément définies lorsque c’est possible.
• Utilisez des identités distinctes pour des fonctions distinctes et limitez leur périmètre et leur durée de validité.
• Tenez un inventaire des identifiants, de leurs responsables et de leur procédure de révocation.

Cela applique le principe des recommandations d’OWASP sur la gestion des secrets : réduire la manipulation humaine des secrets et n’accorder à chaque identité que les accès nécessaires. Un poste compromis expose alors moins d’identifiants réutilisables, et les intervenants savent qui gère ceux qu’il reste à révoquer.

Contrôle 2. Traiter les droits de déploiement comme des privilèges de production

Un secret peut être caché à une personne tout en restant accessible au code qu’elle déploie. Quiconque peut modifier ce code pourrait lire le secret, appeler une API interne ou agir avec le compte de service de l’application. Les accès de déploiement doivent donc être évalués en fonction des permissions de la charge de travail résultante.

Les recommandations d’OWASP sur la sécurité CI/CD considèrent les modifications du dépôt, la configuration du pipeline et les hôtes d’exécution comme des composantes d’un même problème de sécurité. La protection doit couvrir le code avant le déploiement et ses permissions après celui-ci :

• Exigez une revue du code de production et protégez la branche du dépôt exécutée par l’automatisation.
• Contrôlez les modifications des définitions de tâches, des dépendances et des paramètres de lancement, ainsi que du script principal.
• N’accordez aux charges de travail que les identifiants et les accès réseau nécessaires à leur fonction.

Deux ensembles de contrôles doivent fonctionner ensemble. Les permissions du dépôt et du déploiement déterminent qui peut modifier le code. Des politiques distinctes portant sur les identités, les hôtes et le réseau limitent ce que ce code peut faire une fois exécuté. Le stockage centralisé des secrets réduit l’exposition, tandis que ces politiques restreignent le programme qui utilise le secret.

Contrôle 3. Autoriser l’opération, pas seulement l’appelant

Un service de signature peut garder sa clé privée secrète tout en acceptant une demande de signature nuisible. La même distinction s’applique à une base de données ou à une API cloud : l’authentification d’une charge de travail identifie l’appelant, tandis que l’autorisation décide de ce qu’il peut faire.

OWASP recommande de vérifier l’autorisation à chaque requête et de refuser l’accès s’il n’est pas explicitement autorisé. Pour le service destinataire, cela signifie vérifier à la fois l’action et sa cible : destinataires et montants de paiement autorisés, opérations sur la base de données ou modifications de l’infrastructure.

Le résultat attendu est un service qui évalue l’action demandée même si l’appelant est déjà digne de confiance. L’automatisation encadre la manière de demander le travail. Le service destinataire détermine les opérations qu’il accepte.

Contrôle 4. Révoquer les accès créés pendant l’intrusion

Un attaquant peut utiliser une identité légitime pour ajouter un identifiant ou accorder des permissions supplémentaires. MITRE ATT&CK décrit la manipulation de comptes comme un moyen de conserver ou d’étendre des accès, notamment en ajoutant des identifiants cloud et des clés SSH. Désactiver la session d’origine ne supprime pas nécessairement ces modifications.

La délégation sur la chaîne chez Binance montre pourquoi les intervenants doivent examiner les permissions dans le système affecté lui-même. L’endiguement doit couvrir à la fois le point d’entrée initial et l’autorité créée à partir de celui-ci :

• Limitez les identités d’automatisation autorisées à créer d’autres identifiants ou à accorder des permissions.
• Incluez les comptes, sessions et délégations nouvellement créés dans le plan de réponse.
• Vérifiez la révocation dans le système qui applique la permission, au lieu de considérer une tâche arrêtée comme une preuve d’endiguement.

Ces étapes donnent aux intervenants un ensemble défini d’identités et de permissions à examiner et à révoquer. Elles rendent aussi l’endiguement vérifiable : l’équipe peut contrôler que chaque voie connue vers le service affecté est réellement fermée.

Ces contrôles agissent à différents niveaux : l’appareil de l’employé, le système de déploiement, le service destinataire et le processus de réponse. Chacun exige un responsable et un moyen de vérifier que ses restrictions tiennent lorsqu’un autre niveau est compromis.

Les plateformes de gestion de l’automatisation traitent la partie de ce problème située entre la demande d’un employé et l’exécution en production. Dans Semaphore UI, une équipe peut préparer une tâche définie, contrôler qui peut l’exécuter ou la modifier, puis l’exécuter avec une identité distincte. L’autorisation dans le service cible et la révocation des permissions créées ailleurs restent la responsabilité de ces systèmes et de l’équipe de réponse.

Prenons un ingénieur d’astreinte qui doit redémarrer un service d’API. Un responsable de maintenance prépare un playbook et un Task Template qui fixent les hôtes cibles et le déroulement du redémarrage. L’ingénieur lance la tâche et consulte le résultat sans ouvrir de session SSH en production. Les deux chemins ci-dessous réalisent le même redémarrage, mais confient l’identifiant d’exécution à des acteurs différents.

Construire le flux de redémarrage demande quatre étapes liées : créer une identité d’exécution restreinte, définir ce que les utilisateurs peuvent exécuter ou modifier, choisir l’environnement d’exécution et rendre le résultat visible. Une fois ces étapes en place, la même approche peut être étendue aux déploiements.

Une session opérateur volée peut toujours demander les opérations que ce compte est autorisé à exécuter. Même un redémarrage autorisé peut perturber un service s’il est déclenché à répétition. Testez le flux configuré avec un compte opérateur réaliste en préproduction, en examinant à la fois ses possibilités et la réponse de l’équipe à un abus :

• Permissions sur les tâches et les paramètres. Essayez les rôles réels et les options de lancement, notamment les branches, inventaires et arguments alternatifs.
• Accès au-delà de l’opération prévue. Vérifiez les accès à d’autres modèles, identifiants et systèmes de production, y compris ce que le processus du runner peut atteindre.
• Détection et impact opérationnel. Confirmez qui reçoit les résultats, qui examine les activités inattendues et si des exécutions répétées peuvent entraîner des perturbations inacceptables.
• Révocation. Testez la révocation des sessions et des jetons, puis identifiez les permissions que l’identité d’exécution pourrait créer ailleurs.

Documentez les accès conservés par le compte de test et fermez toute voie qui dépasse l’objectif de l’opération. À l’issue de l’exercice, l’équipe doit savoir ce qu’une session volée pourrait faire et comment détecter et contenir ces abus.

Les contrôles d’accès complètent la protection des postes et une équipe qui sait réagir. Rendez le flux préparé assez pratique pour être utilisé sans revenir aux clés partagées ni aux raccourcis non documentés. Appuyez-le sur quelques habitudes quotidiennes :

• Exécutez les programmes d’installation inconnus et les exercices d’entretien dans des environnements jetables et isolés, sans identifiants d’entreprise, montages de l’hôte ni accès aux réseaux internes.
• Facilitez le signalement rapide des activités suspectes, sans chercher de coupable. Donnez aux personnes un contact clair et une procédure de réponse aux incidents.
• Réexaminez les accès lorsque les fonctions changent, maintenez une procédure contrôlée d’accès d’urgence et répétez les révocations avant un incident.

Ces pratiques relient la prévention, la détection et la récupération au travail quotidien. Elles contribuent à garder le modèle d’accès cohérent avec l’évolution des responsabilités et donnent à l’équipe une réponse connue lorsqu’un événement suspect survient.

La leçon centrale est de limiter l’autorité qu’une identité compromise peut accumuler. Moins d’identifiants sur les ordinateurs portables, une automatisation relue, des hôtes d’exécution restreints et une autorisation dans les services de production réduisent chacun les chemins qu’un attaquant peut emprunter.

Semaphore intègre plusieurs de ces contrôles dans un flux reproductible : tâches préparées, permissions distinctes pour l’exécution et la modification, identifiants fournis de façon centralisée et journaux d’exécution visibles. Les opérateurs disposent des actions nécessaires à leur travail, tandis que les responsables de maintenance gardent le contrôle du code et des identifiants sous-jacents.

Commencez par une opération de production fréquente : préparez son modèle de tâche, attribuez les permissions opérateur nécessaires et testez les accès obtenus avant de retirer la connexion directe qu’il remplace. Le bon indicateur de progrès est le peu de choses qu’un attaquant peut faire avec le prochain compte qu’il compromet.