Après avoir lu le rapport d’enquête de Binance, j’avoue que ça m’a donné des sueurs froides.
Un ingénieur voulait installer un outil d’IA populaire pour programmer. Dans ses recherches, il est tombé sur un programme d’installation Homebrew trafiqué. Un autre a reçu une invitation sur une plateforme de recrutement légitime. Il a d’abord passé un appel vidéo avec une vraie personne des RH, puis un entretien avec le « PDG ». Le compte de ce dernier sur les réseaux sociaux contenait même des photos et des vidéos de sa vie quotidienne. Ce n’est qu’à la fin qu’on lui a demandé de télécharger un « exercice d’entretien » contenant du code malveillant.
Face à un lien inconnu ou à un paquet d’installation douteux, je pense que tout le monde se méfierait. Mais après avoir pris autant de précautions pour gagner leur confiance, à leur place, je ne pourrais pas affirmer que je saurais forcément déceler la supercherie.
Plutôt que de me demander comment des employés ont pu se faire piéger aussi facilement, je veux surtout savoir : une fois l’ordinateur d’un employé compromis, jusqu’où les attaquants peuvent-ils aller en s’en servant ?
Dans le rapport, deux voies d’attaque distinctes finissent par se rejoindre dans les systèmes internes. Les attaquants se servent d’un outil d’IA interne pour prendre le contrôle des appareils d’autres ingénieurs, obtenir des jetons de déploiement et, finalement, atteindre l’étape d’autorisation des transactions du portefeuille.
Comment la compromission d’un seul terminal peut-elle dégénérer en une perte de contrôle des accès d’une telle ampleur ? C’est ça qui donne des sueurs froides.
En repensant à ma façon de travailler au quotidien, je me rends compte que moi aussi, je choisis souvent la facilité. Je laisse traîner des clés API, je garde des identifiants de serveur actifs pendant longtemps et j’oublie parfois de révoquer les accès temporaires une fois le travail terminé.
Les outils d’IA me parlent encore plus, parce que je m’y reconnais. Lui faire lire des fichiers, exécuter des commandes, se connecter à des serveurs, déployer automatiquement… À chaque fois, il y a une bonne raison d’ajouter des permissions. Et une fois accordées, l’IA travaille vraiment plus vite. Après avoir bataillé pendant des heures pour faire enfin tourner le projet, lorsqu’une nouvelle demande d’autorisation apparaît, on a vite fait de cliquer machinalement sur « Autoriser ».
Le rapport de Binance indique qu’un outil d’IA interne a servi de point d’appui pour poursuivre l’intrusion, mais les détails du mécanisme n’ont pas encore été rendus publics. Pourtant, en lisant cela, j’ai déjà envie de vérifier : à quels fichiers mon IA peut-elle accéder ? Quels identifiants peut-elle utiliser ? Quand j’essaie un nouveau projet, est-ce que les ressources de mes autres projets risquent aussi d’être exposées ?
On aimerait que l’IA pose moins de questions et puisse faire davantage de choses toute seule. Mais pour éviter quelques confirmations, on risque de lui accorder des permissions qui dépassent largement les besoins de la tâche en cours.
Je ne peux pas garantir que je ne me ferai jamais piéger. Mais je peux au moins prendre quelques précautions à l’avance : séparer mon environnement de travail de celui où j’essaie des outils, stocker les portefeuilles et les clés à part, et révoquer les accès temporaires dès qu’ils ne sont plus nécessaires.
Ne laissons pas une seule autorisation se transformer en confiance permanente.
$BNB #币安10·30安全事件调查报告
Un ingénieur voulait installer un outil d’IA populaire pour programmer. Dans ses recherches, il est tombé sur un programme d’installation Homebrew trafiqué. Un autre a reçu une invitation sur une plateforme de recrutement légitime. Il a d’abord passé un appel vidéo avec une vraie personne des RH, puis un entretien avec le « PDG ». Le compte de ce dernier sur les réseaux sociaux contenait même des photos et des vidéos de sa vie quotidienne. Ce n’est qu’à la fin qu’on lui a demandé de télécharger un « exercice d’entretien » contenant du code malveillant.
Face à un lien inconnu ou à un paquet d’installation douteux, je pense que tout le monde se méfierait. Mais après avoir pris autant de précautions pour gagner leur confiance, à leur place, je ne pourrais pas affirmer que je saurais forcément déceler la supercherie.
Plutôt que de me demander comment des employés ont pu se faire piéger aussi facilement, je veux surtout savoir : une fois l’ordinateur d’un employé compromis, jusqu’où les attaquants peuvent-ils aller en s’en servant ?
Dans le rapport, deux voies d’attaque distinctes finissent par se rejoindre dans les systèmes internes. Les attaquants se servent d’un outil d’IA interne pour prendre le contrôle des appareils d’autres ingénieurs, obtenir des jetons de déploiement et, finalement, atteindre l’étape d’autorisation des transactions du portefeuille.
Comment la compromission d’un seul terminal peut-elle dégénérer en une perte de contrôle des accès d’une telle ampleur ? C’est ça qui donne des sueurs froides.
En repensant à ma façon de travailler au quotidien, je me rends compte que moi aussi, je choisis souvent la facilité. Je laisse traîner des clés API, je garde des identifiants de serveur actifs pendant longtemps et j’oublie parfois de révoquer les accès temporaires une fois le travail terminé.
Les outils d’IA me parlent encore plus, parce que je m’y reconnais. Lui faire lire des fichiers, exécuter des commandes, se connecter à des serveurs, déployer automatiquement… À chaque fois, il y a une bonne raison d’ajouter des permissions. Et une fois accordées, l’IA travaille vraiment plus vite. Après avoir bataillé pendant des heures pour faire enfin tourner le projet, lorsqu’une nouvelle demande d’autorisation apparaît, on a vite fait de cliquer machinalement sur « Autoriser ».
Le rapport de Binance indique qu’un outil d’IA interne a servi de point d’appui pour poursuivre l’intrusion, mais les détails du mécanisme n’ont pas encore été rendus publics. Pourtant, en lisant cela, j’ai déjà envie de vérifier : à quels fichiers mon IA peut-elle accéder ? Quels identifiants peut-elle utiliser ? Quand j’essaie un nouveau projet, est-ce que les ressources de mes autres projets risquent aussi d’être exposées ?
On aimerait que l’IA pose moins de questions et puisse faire davantage de choses toute seule. Mais pour éviter quelques confirmations, on risque de lui accorder des permissions qui dépassent largement les besoins de la tâche en cours.
Je ne peux pas garantir que je ne me ferai jamais piéger. Mais je peux au moins prendre quelques précautions à l’avance : séparer mon environnement de travail de celui où j’essaie des outils, stocker les portefeuilles et les clés à part, et révoquer les accès temporaires dès qu’ils ne sont plus nécessaires.
Ne laissons pas une seule autorisation se transformer en confiance permanente.
$BNB #币安10·30安全事件调查报告
