Comment perdre 1,3 To de secrets, à la manière de Novo Nordisk.

Ce mois-ci, Novo Nordisk — le géant pharmaceutique danois à l'origine d'Ozempic et Wegovy — a confirmé que des attaquants avaient pénétré dans ses systèmes [1]. La porte d'entrée, selon les chercheurs, était un jeton d'accès à haut privilège présent dans le JavaScript d'un sous-domaine oublié et accessible au public : un secret livré au navigateur, lisible par quiconque ouvrait View Source [2]. Négligent, oui. Mais une entreprise de cette taille n'est pas négligente en matière d'identifiants en général — elle exploite très certainement une gestion sérieuse des identifiants, la machinerie d'accès privilégié qui régit qui peut se connecter où. Rien de tout cela n'a compté, car tout cela protège le mauvais côté de la maison.

Ce qui s'est réellement passé

Ce premier jeton était suffisamment privilégié pour cloner les dépôts privés de Novo Nordisk. Et les dépôts regorgeaient d'autres identifiants — car c'est là que vivent les identifiants machine, dans presque toutes les entreprises du monde : codés en dur dans le code source, présents dans la configuration, intégrés aux pipelines CI, commis une fois puis oubliés. Cloner les dépôts n'a pas seulement livré le code source aux attaquants. Cela leur a donné le jeu de clés suivant, puis celui d'après.

C'est ainsi qu'un jeton négligent devient une compromission totale. Un groupe se faisant appeler FulcrumSec affirme avoir pivoté de cette manière pendant deux mois et demi et être parti avec plus de 700 000 fichiers — environ 1,3 téraoctet — comprenant du code source, des données de médicaments commercialisés et non commercialisés, des dossiers d'essais cliniques, des technologies de fabrication et les modèles d'IA internes de l'entreprise [3]. Lorsqu'une rançon annoncée à 25 millions de dollars a été refusée, le groupe a commencé à publier le butin. (Novo Nordisk a confirmé un accès non autorisé à un nombre limité de systèmes ; l'ampleur complète relève de la déclaration des attaquants, et n'a pas encore été vérifiée de manière indépendante [1][3].)

Un jeton divulgué était la poignée de porte. Les dépôts pleins d'identifiants permanents étaient le bâtiment déverrouillé derrière elle.

Il ne s'agit pas de négligence. Il s'agit d'une lacune de catégorie.

La gestion des identifiants en entreprise — les coffres de niveau CyberArk, les outils d'accès privilégié que chaque grande entreprise exploite — a été conçue pour les personnes : comptes humains, sessions de connexion, qui peut atteindre quoi. Elle fonctionne, pour cela. Les identifiants qui ont cascadié à travers cette intrusion se trouvaient de l'autre côté, entièrement. Le jeton dans le JavaScript, les secrets dans les dépôts, les clés dans le pipeline CI sont des identifiants machine — ceux que les applications, les services et désormais les agents utilisent pour s'authentifier entre eux, sans intervention humaine. Ce côté n'a jamais eu de coffre.

Et c'est le côté qui explose. Chaque nouvelle intégration, chaque microservice, chaque agent d'IA que vous déployez multiplie les identifiants machine permanents que personne ne gouverne. Le danger a migré vers le côté applications-et-agents, et les outils ne l'ont pas suivi. Les post-mortems en resteront donc à « ne pas mettre de jetons dans le JavaScript », et c'est combattre le mauvais combat. Les jetons fuiront toujours — dans un journal, une capture d'écran, un bundle oublié. On ne peut pas gagner sur le fait de ne jamais exposer le premier identifiant. Ce qui a transformé une fuite en 1,3 téraoctet, c'est l'édifice d'identifiants machine permanents qui se trouvait derrière, dans le code, attendant d'être cloné. Obtenez-en un, obtenez la carte du reste.

Conçu pour cela, délibérément

Cette lacune est la raison d'être même de Clavitor : un coffre pour le côté pour lequel CyberArk n'a jamais été conçu — les identifiants utilisés par les applications et les agents. Avec Clavitor, il n'y a aucun identifiant à récolter dans les dépôts. Le code ne détient jamais un secret qu'il pourrait commettre ; il demande au coffre l'utilisation d'un identifiant à l'instant précis où il en a besoin, et la valeur ne se retrouve jamais dans le code source, la configuration ou le build. Un attaquant qui vole le premier jeton et clone tous vos dépôts trouve exactement ce qui devrait s'y trouver : du code, et aucune clé. La chaîne qui transforme une fuite en tout se brise dès le premier maillon.

Le jeton d'entrée est désarmé de la même manière. Un identifiant Clavitor est limité à une seule action et expire : un jeton trouvé dans un bundle égaré n'est donc plus un passe-partout — il ne peut pas cloner l'organisation ni atteindre le secret suivant, puisqu'il n'a jamais valu que pour la seule chose pour laquelle il était nommé. Il est lié à la machine à laquelle il a été délivré : une copie utilisée ailleurs est morte. Aucun identifiant unique ne devient non plus une canalisation d'exfiltration silencieuse : chaque autorisation est limitée en débit et déclenche un verrouillage en cas de pic anormal, si bien que 700 000 fichiers ne s'échappent pas une requête raisonnable à la fois sur dix semaines. Et chaque utilisation est journalisée hors de la machine et chaînée par hachage, ce qui rend une résidence silencieuse bien plus difficile à mener lorsque le registre ne se trouve pas sur une machine que l'intrus possède.

Rien de tout cela ne vous rend inviolable, et quiconque promet cela vous vend quelque chose. Codifiez en dur une clé maîtresse de longue durée et quiconque la trouve peut l'utiliser, une fois, pour ce qu'elle autorise. Ce qui change, c'est que trouver un identifiant ne livre plus les autres : pas de dépôt plein de secrets permanents derrière lui, pas de chaîne de la fuite jusqu'aux 1,3 téraoctets. Le rayon d'impact d'un jeton divulgué se réduit de nouveau au jeton.

La partie à retenir

Le titre de presse portera sur les formules des médicaments et la vente aux enchères sur le dark web, et c'est la partie qui fait mal. La leçon est plus discrète : une entreprise sophistiquée disposant d'une véritable gestion des identifiants est tout de même descendue à 1,3 téraoctet de profondeur — parce que son coffre surveillait les personnes pendant que l'intrusion entrait par les applications. Les identifiants machine sont l'endroit où se trouve le danger désormais, et ils sont le seul côté encore exposé en pleine lumière. La réponse n'est pas de nettoyer vos dépôts — c'est un identifiant qui ne s'y est jamais trouvé de façon permanente, donc rien à nettoyer, un identifiant qui, même volé, ne vaut que pour une seule action limitée, sans cabinet de clés derrière lui. La fuite reste une fuite. Elle cesse simplement d'être les clés de tout.

Nous avons consigné les règles qu'un outil d'identifiants devrait respecter pour le côté applications-et-agents — les dix règles complètes sont ici.

Clavitor (@clavitorai) est le coffre d'identifiants conçu pour les agents d'IA, et contre eux. clavitor.ai

Sources

[1] Novo Nordisk (@novonordisk) — Incident update. Confirme un accès non autorisé à un nombre limité de ses systèmes informatiques internes.

[2] CybelAngel (@CybelAngel) — Novo Nordisk Was Breached Through JavaScript: what the coverage got wrong. Retrace l'accès initial jusqu'à un jeton d'accès à haut privilège laissé dans le JavaScript client minifié d'un sous-domaine public oublié.

[3] TechRepublic (@TechRepublic) — Ozempic Maker Novo Nordisk Confirms Security Incident After $25M Hacker Demand. Le groupe FulcrumSec revendique une présence d'environ 2,5 mois et environ 700 000 fichiers / 1,3 To — code source, données de médicaments commercialisés et non commercialisés, dossiers d'essais cliniques et modèles d'IA internes — après avoir cloné des dépôts et récolté d'autres identifiants ; les données fuyant après le refus de la rançon.