Comment un seul jeton GitHub a contourné le périmètre d'un géant pharmaceutique mondial

Novo Nordisk maintient une infrastructure de sécurité à plusieurs niveaux. L'entreprise utilise une détection avancée des points terminaux, une segmentation du réseau et un centre d'opérations de sécurité dédié. Ces défenses coûtent des millions de dollars par an. Pourtant, toute l'architecture s'est effondrée à cause d'une seule chaîne de caractères sur un site web public. La violation chez le géant pharmaceutique danois est une étude de cas sur le paradoxe architectural du développement logiciel moderne. Un investissement massif dans la défense périmétrique a échoué parce qu'un seul jeton d'authentification se trouvait au mauvais endroit.

J'ai passé des années à communiquer avec des chercheurs en sécurité via Signal et des canaux cryptés par PGP. La plupart d'entre eux ne cherchent pas de vulnérabilités complexes de type « zero-day » dans des pare-feu renforcés. Ils cherchent le chemin de la moindre résistance. Dans l'incident de Novo Nordisk, le chemin était un jeton d'accès personnel (PAT) GitHub à hauts privilèges laissé dans le JavaScript côté client sur un sous-domaine obscur. Ce n'était pas un piratage sophistiqué. C'était un exercice de découverte. Une fois que le groupe de menace, connu sous le nom de FulcrumSec, a trouvé le jeton en mars, le périmètre de sécurité formel est devenu non pertinent. Le jeton fournissait un accès authentifié. Pour les systèmes internes, les attaquants étaient des développeurs légitimes.

L'anatomie d'une intrusion silencieuse

FulcrumSec a opéré à l'intérieur du réseau de Novo Nordisk pendant plus de deux mois avant d'être détecté. Durant cette période, le groupe a utilisé le jeton GitHub initial pour cloner des dépôts privés. Ces dépôts contenaient plus que du code. Ils contenaient des identifiants secondaires, des définitions d'infrastructure et de la documentation interne. C'est un schéma courant dans les intrusions modernes. Un attaquant utilise un petit point d'appui pour récolter des secrets plus puissants. Ils n'ont pas besoin d'exploiter un bogue logiciel lorsqu'ils ont les clés de la porte d'entrée.

Au moment où Novo Nordisk a divulgué l'incident le 11 juin, les attaquants avaient exfiltré 1,3 To de données. Ce cache comprenait 700 000 fichiers. Bien que l'entreprise ait initialement décrit l'impact comme étant limité à des données de patients pseudonymisées et à des dossiers de professionnels de santé, la réalité semble plus grave. Les données volées incluent des informations exclusives sur des médicaments commercialisés et non commercialisés, des recherches d'essais cliniques et des modèles d'IA internes. FulcrumSec affirme que ces informations pourraient faire gagner aux concurrents trois à cinq ans de temps de développement. C'est la définition d'une défaillance systémique. La violation est passée d'un simple jeton divulgué à la perte de propriété intellectuelle stratégique.

Pourquoi les pipelines de développement sont des systèmes de production

Les plateformes de développement sont les systèmes de plus haute valeur dans l'entreprise moderne. La plupart des programmes de sécurité ne reconnaissent pas cette réalité. Un dépôt de code n'est plus un simple bac de stockage pour des fichiers texte. C'est le plan directeur de tout l'environnement numérique. Il contient les configurations pour les environnements cloud et les pipelines de déploiement qui poussent le code vers les clients. Lorsqu'un attaquant accède à un dépôt, il voit le câblage de l'organisation.

Matt Kimpel, responsable de la sécurité de l'information chez Magna5, note que les développeurs ont un accès permanent aux systèmes qui comptent le plus. Ils possèdent des identifiants pour les pipelines de construction et les environnements cloud. Ces systèmes sont en amont de l'environnement de production. Si un attaquant compromet le code avant qu'il ne soit compilé, il contrôle le produit final. Cela rend le poste de travail du développeur et le dépôt plus critiques que le serveur de production lui-même. Les protections traditionnelles telles que les approbations de branches et les revues de code supposent que la personne effectuant l'action est un employé de confiance. Si l'identité est compromise, ces mêmes contrôles facilitent l'attaque.

Le risque invisible des identités machines

Les organisations traitent la gestion des secrets comme un problème d'outillage. Elles achètent un coffre-fort et supposent que le problème est résolu. L'incident de Novo Nordisk prouve que la gestion des secrets est un problème d'identité. Le jeton GitHub divulgué est une identité machine. Contrairement aux comptes humains, les identifiants machines manquent souvent de propriétaires clairs. Ils n'ont pas de calendriers de rotation cohérents. Ils manquent fréquemment de surveillance significative. Ces jetons persistent pendant des mois ou des années sans changement.

Shane Barney, RSSI chez Keeper Security, souligne que cette invisibilité transforme un seul jeton en une intrusion à long terme. Lorsqu'un identifiant machine porte des autorisations étendues et que personne ne surveille son utilisation, un attaquant n'a pas besoin d'augmenter ses privilèges. L'accès est déjà là. Le rayon d'action est l'ensemble de l'environnement. C'est pourquoi les attaquants sont restés indétectés pendant 60 jours. Ils ne s'introduisaient pas par effraction dans le système. Ils utilisaient le système tel qu'il avait été conçu pour être utilisé.

L'émergence d'acteurs de menace secondaires

Un deuxième groupe de menace s'appelant TheUSERS007 a également revendiqué un accès aux systèmes de Novo Nordisk entre le 5 et le 7 juin. Ce groupe a ciblé des données liées à la recherche en IA. Cela suggère qu'une fois qu'une fuite majeure se produit, d'autres acteurs commencent à sonder la même infrastructure. Une seule vulnérabilité dans un pipeline de développement indique souvent des faiblesses systémiques plus larges. Si un développeur laisse un jeton dans un script public, d'autres développeurs suivront probablement des schémas peu sûrs similaires. La surface d'attaque n'est pas une carte statique. C'est un environnement dynamique où une erreur invite à un examen plus approfondi de la part de multiples adversaires.

Cette intrusion secondaire met en évidence le risque pour les modèles d'IA internes. Ces modèles représentent l'avenir de la recherche pharmaceutique. Ils sont construits sur des années de données exclusives et un investissement informatique massif. La perte de ces modèles n'est pas seulement une violation de données. C'est une perte d'avantage concurrentiel. L'environnement numérique n'a pas de murs physiques. Une fois que la logique du système est exposée via le code source et les poids des modèles, les dommages sont permanents.

Passer des outils réactifs au contrôle proactif de l'identité

Pour atténuer ces risques, les organisations doivent changer leur vision de l'accès des développeurs. Un coffre-fort est une boîte pour les secrets. La gestion des identités est le contrôle de qui peut ouvrir la boîte et pendant combien de temps. L'objectif est de réduire la durée de vie de chaque secret. Si un jeton expire dans quatre heures, une fuite dans un fichier JavaScript est une nuisance temporaire. Si un jeton dure un an, une fuite est une catastrophe.

La centralisation de la gestion des secrets est une étape nécessaire. Chaque identité dans l'environnement doit suivre le principe du moindre privilège. Cela signifie qu'un jeton GitHub ne devrait avoir accès qu'aux dépôts spécifiques requis pour une tâche. Il ne devrait pas avoir d'autorisations administratives larges sur l'ensemble de l'organisation. La rotation automatisée garantit que les identifiants ne survivent pas à leur utilité. Cette discipline n'empêche pas un attaquant de trouver un jeton, mais elle limite ce qu'il peut en faire.

Mesures pratiques pour la sécurité des pipelines

Les organisations devraient commencer par un inventaire des identités non humaines. La plupart des entreprises ne savent pas combien de clés API ou de comptes de service existent dans leur environnement. On ne peut pas protéger ce que l'on ne voit pas. Cet inventaire doit inclure la portée de chaque clé et sa date de dernière utilisation. De nombreuses organisations constatent qu'un pourcentage important de leurs jetons actifs ne sont plus nécessaires. Ces secrets orphelins sont des cibles de haute valeur pour les attaquants.

La surveillance des identités machines est aussi vitale que la surveillance des connexions humaines. Les équipes de sécurité doivent établir une base de comportement normal pour les comptes de service. Si un jeton GitHub accède habituellement à trois dépôts à partir d'une adresse IP connue et commence soudainement à cloner 500 dépôts à partir d'une région différente, le système doit déclencher une alerte. La détection doit se produire au niveau de la couche d'identité. Corriger les logiciels est important, mais à une époque où les identités sont la cible principale, la visibilité sur l'utilisation des identifiants est le seul moyen d'attraper un intrus silencieux.

Étapes pour une réduction immédiate des risques

1. Scannez tous les actifs exposés au public pour y trouver des secrets. Utilisez des outils automatisés pour trouver des jetons, des clés API et des identifiants de base de données dans le code côté client.
2. Mettez en œuvre des jetons à courte durée de vie. Remplacez les jetons d'accès personnels à longue durée de vie par des identifiants précis et limités dans le temps chaque fois que la plateforme le permet.
3. Auditez les autorisations des dépôts. Supprimez l'accès administratif des jetons de développeur. Assurez-vous qu'aucun jeton unique n'a le pouvoir de cloner l'intégralité de la base de code.
4. Activez l'analyse des secrets dans le pipeline CI/CD. Bloquez tout commit contenant un secret en texte clair avant qu'il n'atteigne le dépôt.
5. Surveillez l'activité anormale des dépôts. Configurez des alertes pour le clonage en masse ou l'accès à partir d'emplacements inhabituels.

Cet incident rappelle que le périmètre s'est déplacé. Il ne se trouve plus à la limite du réseau. Il existe au niveau du jeton individuel et de l'identité spécifique. Si vous ne gérez pas ces identités avec la même rigueur que vos serveurs de production, vos défenses sont une illusion.

Sources : NIST Cybersecurity Framework, MITRE ATT&CK Framework (Technique T1528 : Steal Application Access Token), reportage de DataBreaches.net.

Avertissement : Cet article est fourni à des fins d'information et d'éducation uniquement. Il ne remplace pas un audit professionnel de cybersécurité ou un service de réponse aux incidents.