Le top 10 des risques de sécurité liés aux identités machine

Quel point commun entre le piratage d'Okta fin 2023, celui de Microsoft par Midnight Blizzard début 2024 et, plus récemment, la compromission du Zendesk de l'Internet Archive ? Tout au moins, celui d'avoir impliqué des identités machine.

L'OWASP (Open Worldwide Application Security Project) donne ces trois exemples en introduction d'un Top 10 dédié au sujet, sous l'angle du cycle de développement logiciel. Ses principales sources :

• Compilation, parmi les failles majeures survenues ces trois dernières années, de celles ayant impliqué des identités "non humaines" (NHI, non-human identities)
• Scores CVE dans la National Vulnerability Database
• Sondages mettant en lumière les enjeux importants des NHI
• Rapports State of Cloud Security de Datadog (2022, 2023, 2024)
• NHI Report de la Cloud Security Alliance (2024)
• Data Breach Investigations Report de Verizon (2024)

L'OWASP a repris la méthodologie traditionnelle du Top 10, évaluant les vulnérabilités sur quatre dimensions : exploitabilité, prévalence, détectabilité et impact technique.

Désactivation ou suppression inadéquate d'identités machine

Le Top 10 NHI s'ouvre avec cette vulnérabilité souvent introduite lorsque des applications sont déclarées obsolètes, que des services sont mis hors ligne ou que des owners ou admins quittent une organisation.

L'OWASP donne trois exemples :

• Comptes de service Kubernetes orphelins
  Un cluster appartenant à un service décommissionné conserve des comptes de service actifs. Un attaquant qui accéderait à ce cluster non supervisé pourrait exploiter lesdits comptes.
  
  
• Ancien employé exploitant des authentifiants non révoqués
  
  
• Applications non décommissionnées servant à l'élévation de privilèges et à la latéralisation
  Typiquement, une app créée dans un environnement de test, puis connectée à un environnement de prod sensible et ensuite non retirée.

Fuite de secrets

Des NHI peuvent filtrer au cours du cycle de développement logiciel, que ce soit parce qu'elles sont intégrées en dur dans du code, incluses en clair dans des fichiers de configuration ou transmises sur des applications de chat non sécurisées.

L'OWASP donne deux exemples :

• Un token Azure SAS poussé sur un dépôt GitHub public
  
  
• La clé d'API d'un admin Delinea stockée dans un script au sein d'un partage de fichiers accessible à tous les employés
  Un attaquant disposant de privilèges limités sur le réseau corporate pourrait identifier la clé, la lire et élever ses privilèges depuis le PAM.

Identité machine tierce vulnérable

Ces NHI s'intègrent dans le cycle de développement notamment à travers l'usage d'IDE et de leurs extensions. Pour fonctionner correctement, ces extensions peuvent avoir besoin de s'intégrer à des services tiers (bases de données, gestion de versions, VM et environnements cloud...) et de leur transmettre des NHI. La compromission d'une extension peut être exploitée pour voler les authentifiants ou abuser des permissions associées.

L'OWASP donne trois exemples :

• Intégration d'IDE avec des dépôts de code
  Cela nécessite de donner, à l'IDE ou à ses extensions, des PAT (jetons d'accès personnels) ou des clés SSH.
  
  
• Extensions accédant à des ressources cloud
  Par exemple, celles qui facilitent le déploiement et le test sur ces environnements. Une extension malveillante pourrait exploiter des NHI pour accéder à des ressources, voire les modifier ou les supprimer.
  
  
• Fournisseur de service tiers
  Exemple de l'intégration de Sisense pour créer une app BI. Les dévelopeurs créent, dans ce cadre, une NHI privilégiée et l'envoient au fournisseur tiers. Si celui-ci est compromis, un attaquant pourrait obtenir la NHI.

Authentification non sécurisée

Les méthodes d'authentification utilisées avec les services tiers peuvent être vulnérables, en particulier parce que obsolètes.

L'OWASP donne cinq exemples :

• Flux OAuth obsolètes
  Certains flux d'anciennes versions comme OAuth 1.0 et 2.0 ont été déclarés obsolètes en raison de vulnérabilités. Par exemple, le flux implicite, communément utilisé pour les applications monopages, et qui expose les jetons d'accès dans l'URL. Ou le flux de code d'autorisation lorsqu'il est utilisé sans une extension type PKCE (Proof Key for Code Exchange).
  
  
• Implémentations OAuth non standards
  Certaines plates-formes implémentent des comportements spécifiques comme la conversion des jetons d'accès en cookies ou la génération de jetons JSON Web à la demande. Des pratiques qui peuvent occasionner des vulnérabilités.
  
  
• Usage de méthodes avec authentifiants plutôt que sans
  Les CSP proposent souvent des mécanismes sans authentifiants, par exemple en utilisant les profils d'instances ou la fédération OIDC. Des options préférables à celles avec authentifiants, en tout cas statiques.
  
  
• Contournement du MFA par des mots de passe d'applications
  Pour prendre en charge les applications anciennes qui ne gèrent pas les protocoles d'authentification modernes, certaines plates-formes fournissent des mots de passe d'applications. Ces derniers contournent le MFA même lorsqu'il est activé.
  
  
• Protocoles d'authentification hérités exploitant nom d'utilisateur et mot de passe

Identité machine surprivilégiée

L'OWASP donne cinq exemples :

• Utilisateur surprivilégié sur un serveur web
  Un serveur web exploite un compte utilisateur local sur une machine Linux qui a accès à d'autres applications et données. Si le serveur a une vulnérabilité permettant la prise de contrôle du processus, l'attaquant peut tirer parti du compte utilisateur et de ses permissions.
  
  
• VM surprivilégiée
  Par erreur, on attribue à une instance EC2 Jenkins les droits AdministratorAccess, même si elle n'a besoin que de permissions pour EKS et ECS. Une vulnérabilité sur l'instance peut entraîner un accès malveillant et l'exploitation des privilèges dans l'environnement cloud.
  
  
• Application OAuth surprivilégiée
  Une app OAuth en cours de développment est installée sur un compte Azure de production, avec les droits AppRoleAssignment.ReadWriteAll, même si elle n'a besoin que de lire un dossier spécifique sur Azure Blob. Un attaquant qui mettrait la main sur l'application pourrait exploiter ces droits.
  
  
• Compte de service de base de données surprivilégié
  Une base de données managée fonctionne avec un compte de service qui a des privilèges admin. Si un attaquant accède à la base, il pourrait utiliserces privilèges sur tout le compte cloud.
  
  
• Utilisateur d'application insuffisamment restreint
  Une application de base de données fonctionne avec un compte de service qui a des privilèges admin sur le serveur. Un attaquant exploitant une vulnérabilité dans le logiciel de base de données pourrait exploiter les permissions du compte pour exécuter des commandes.

Configurations de déploiements cloud non sécurisées

Utiliser des comptes de service avec authentifiants statiques au sein des pipelines CI/CD est considéré comme non sécurisé. Ces authentifiants peuvent effectivement se retrouver exposés dans du code, des logs ou des fichiers de config. L'option OIDC est plus sécurisée... à condition de bien la paramétrer. Entre autres, en encadrant strictement les demandes de jetons et en les validant correctement.

L'OWASP donne deux exemples :

• Rôles AWS IAM avec relations de confiance OIDC mal configurées
  Les rôles AWS permettant l'accès OIDC par l'intermédiaire d'AssureRoleWithWebIdentity peuvent être mal configurés s'ils font confiance à des fournisseurs publics comme GitHub ou GitLab sans restreindre de manière appropriée la demande sub. Tout utilisateur de ces plates-formes pourrait alors endosser le rôle.
  
  
• Authentifiants de principal de service Azure codés en dur
  Les authentifiants d'un principal de service utilisé dans une action GitHub peuvent être codés en dur dans les fichiers de configuration du pipeline.

Secrets durables

Des NHI sensibles peuvent avoir des dates d'expiration trop lointaines, voire pas du tout de date d'expiration.

L'OWASP donne deux exemples :

• Élévation de privilèges via un vieux jeton d'accès sensible
  Un attaquant à faible niveau de privilèges pourrait identifier un tel token "traînant" sur le réseau corporate.
  
  
• Détournement de session par vol de cookies
  Un cookie de session web est paramétré pour être durable. Il pourrait être exfiltré, par exemple par un infostealer parcourant le réseau corporate.

Absence d'isolation entre environnements

Réutiliser des NHI entre plusieurs applications peut introduire des vulnérabilités.

L'OWASP donne deux exemples :

• Clés d'accès AWS partagées entre environnements
  Une clé d'accès à des buckets S3 est utilisée à la fois dans des environnements de testet de prod. Elle a des permissions pour accéder à des données sensibles. La compromission d'un environnement expose l'autre.
  
  
• Identité Azure managée partagée entre abonnements
  Une identité managée assignée par le système est utilisable à la fois par des ressources d'un abonnement de test et les ressources d'un abonnement de prod. Là aussi, un environnement compromis en vaut deux.

Réutilisation d'identités machine

L'OWASP donne trois exemples :

• Réutilisation d'un compte de service Kubernetes
  Dans un cluster, plusieurs pods partagent un compte de service, dont des pods critiques responsables des tâches d'orchestration. Si un pod est compromis, l'attaquant peut utiliser le compte de service dans le cluster.
• Clés d'API partagées entre applications
• Réutilisation d'authentifiants cloud

Utilisation d'identités machine par des humains

Pendant le développement et la maintenance d'applications, devs et admins peuvent utiliser des NHI pour des tâches manuelles qu'ils devraient effectuer avec des identités humaines aux privilèges appropriés.

L'OWASP donne cinq exemples :

• Admins utilisant des authentifiants de compte de service
  Pour se connecter sur une console de gestion cloud, un admin utilise une NHI destinée au déploiement automatisé et qui a par là même des privilèges étendus. Ses actions sont journalisées au nom du compte de service, obscurcissant la responsabilité.
  
  
• Développeurs exécutant des commandes avec des identités machine
  Un dev exécute manuellement un script ou une commande avec un NHI dotée de permissions sur les environnements de prod. En cas d'erreur, il devient difficile de remonter jusqu'à lui par l'intermédiaire des logs.
  
  
• Jetons d'API partagés entre membres d'une équipe
  Pour accéder rapidement à certaines ressources, une équipe partage un jeton d'API associé à un compte de service, avec des droits d'accès étendus. Autant de chances pour un attaquant de mettre la main dessus.
  
  
• Contournement des contrôles de sécurité par un employé
  Un employé utilise une NHI pour accéder à des ressources sur lesquelles son compte n'a pas de droits (MFA, restriction d'adresse IP...). Cette pratique sape la posture de sécurité de l'organisation.
  
  
• Attaquants exploitant des NHI à des fins de persistance
  Les NHI ne sont pas sujettes au MFA ou à des changements réguliers de mot de passe, favorisant la persistance.

Le tableau récapitulatif du Top 10

Illustration générée par IA