Les chercheurs découvrent les chaînes d’attaque RCE dans les coffres d’identification des entreprises populaires

Les chercheurs ont trouvé 14 défauts logiques dans diverses composants de Hashicorp Vault et Cyberark Conjur, deux systèmes de gestion des informations d’identification open source, permettant des attaques qui pourraient contourner les vérifications d’authentification, accéder aux secrets, imiter les identités et exécuter du code arbitraire.

Dans les environnements d’entreprise, les identités non humaines, telles que celles utilisées par les applications et les machines, sont estimées pour être plus nombreuses que les identités humaines 150 à 1.

Reconnaissant cela, les chercheurs de la société de cybersécurité Cyata ont analysé deux solutions de gestion des secrets open-source largement utilisées: Hashicorp Vault et Cyberark Conjur. Leurs résultats, qui comprennent 14 vulnérabilités qui permettent des chaînes d’attaque à distance d’exécution du code à distance (RCE) dans les deux produits, ont été présentées aujourd’hui à la Black Hat USA Security Conference à Las Vegas.

« Les Secrets Vaults sont l’épine dorsale de l’infrastructure numérique », ont écrit les chercheurs dans leur rapport. «Ils stockent les informations d’identification, les jetons et les certificats qui régissent l’accès aux systèmes, aux services, aux API et aux données. Ils ne font pas seulement partie du modèle de confiance – ils sont le modèle de confiance. En d’autres termes, si votre coffre-fort est compromis, votre infrastructure est déjà perdue.»

Hashicorp Vault et Cyberark conjur font plus que de simplement stocker des secrets. Ils permettent aux organisations de définir des politiques pour accéder et utiliser ces secrets, offrant des contrôles d’accès basés sur les rôles, la rotation automatisée des secrets, l’audit, etc. Conçus pour l’intégration avec les outils DevOps, ces systèmes font souvent partie des pipelines CI / CD.

Les chaînes d’attaque découvertes par Cyata, divulguées de manière responsable à Hashicorp et Cyberark et maintenant corrigées, découlent de défauts logiques subtils dans les mécanismes d’authentification, de validation et d’application des politiques. Les défauts ont permis de contourner les contournements de lock-out, d’évasion de contrôle politique et d’identité des comptes.

Les vérifications de validation manquantes permettent un compromis conjur

La chaîne d’attaque de Cyata contre Cyberark conjur a commencé par une simple erreur dans le code utilisé pour valider les identités AWS IAM. Conjur prend en charge l’authentification pour les instances AWS via le service de token de sécurité d’AWS (STS), permettant aux workflows de s’authentifier sans des informations d’identification codées en dur.

Pour s’authentifier, une instance AWS génère un en-tête signé, qui conduisait vers AWS Sts. STS valide la signature et renvoie l’identité de l’instance. Cependant, les serveurs STS sont spécifiques à la région. Par exemple, les instances dans US-East-1 doivent utiliser STS.US-East-1.amazonaws.com et conjur détermine la région STS correcte en fonction du nom d’hôte de l’instance inclus dans l’en-tête signé.

Le problème est que le nom d’hôte dans l’en-tête peut être contrôlé par l’attaquant. Et bien que ce ne soit pas un problème car une fausse signature échouerait normalement à la validation par une instance STS légitime, le code de conjur n’a pas réussi à désinfecter des caractères spéciaux comme «? dans le nom d’hôte.

Cela a permis aux chercheurs d’élaborer une demande avec un nom d’hôte tel que ST.Cyata.ai?, Que le code de conjur a transformé en s.cyata.ai?.amazonaws.com, ajoutant le domaine correct. Cependant, dans la pratique, la partie après le point d’interrogation supplémentaire est ignorée dans les URL afin que les demandes soient envoyées à ST.Cyata.ai, un serveur Rogue STS sous le contrôle des chercheurs, passant la validation.

« Ce fut la première étape de la chaîne, où un attaquant complètement non authentifié pouvait désormais entrer dans le système, semblant être une identité AWS légitime », ont expliqué les chercheurs.

De la contrefaçon d’identité au RCE complet

Une identité d’instance AWS correspond généralement à un nom d’hôte. Mais les chercheurs ont exploré comment cela pourrait être abusé dans le modèle de ressources de conjur, qui utilise trois paramètres: compte (nom de compte conjur), type (type de ressource – hôte, utilisateur, variable, politique, etc.) et identifiant (nom de ressource unique). Ces paramètres sont également utilisés dans les requêtes API.

Ils ont découvert que la logique d’authentification de conjur n’a pas validé la partie «gentille» d’une identité. Cela signifiait qu’ils pouvaient utiliser leur identité AWS usurpé pour s’authentifier en tant qu’utilisateur ou politique dans le système au lieu d’un hôte, élargissant considérablement la surface d’attaque.

« Cette étape a changé le jeu », ont-ils déclaré. «Il a comblé l’écart entre l’accès non authentifié et une surface d’attaque significative à conjur.

Ensuite, ils ont examiné l’usine de politique de conjur, un mécanisme qui permet aux administrateurs d’appliquer des modèles de politique réutilisables aux nouvelles ressources. Ces modèles peuvent contenir du code Ruby (ERB) intégré qui est exécuté lorsqu’il est appliqué.

Leur objectif était de créer un modèle avec un code ERB arbitraire pour réaliser une exécution arbitraire de code, mais comme la conjurage n’inclut pas les modèles intégrés par défaut, ils n’ont pas pu abuser d’un existant.

Les chercheurs ont déterminé que les modèles de politique étaient stockés dans le tableau des secrets de conjur et que les secrets étaient uniquement destinés à être affectés aux ressources de type variable, et non aux hôtes. Cependant, dans la pratique, le code de conjur n’a pas appliqué cette restriction.

Une inspection supplémentaire a révélé des lacunes de validation supplémentaires. Par exemple, une requête comme {compte}: variable: conjur / usine / {kind} n’a pas validé le champ de compte. En spécifiant un nom de compte comme MyAccount: Host, ils ont transformé l’ID de ressource en MyAccount: HOST: Variable: conjur / usine / {kind}.

« C’était la dernière étape et celle qui a livré une exécution complète du code distant », ont déclaré les chercheurs. «Le code a fonctionné parce que: nous avons trompé la conduite pour récupérer un hôte comme s’il s’agissait d’une variable. Nous avons attribué Erb en tant que secret et conjura l’a exécuté, exactement comme elle a été conçue. Cette vulnérabilité a transformé la création d’hôtes arbitraires en une chaîne d’exploitation arbitraire.

Cyberark a abordé ces questions en juin, publiant cinq CVE distincts. Cependant, les détails techniques complets des vulnérabilites sont maintenant divulgués publiquement pour la première fois.

Première défaut d’exécution du code à distance publique dans Hashicorp Vault

Hashicorp Vault est un système de gestion des informations d’identification open-source, également disponible dans une édition d’entreprise, qui sert un objectif similaire à Cyberark Conjur: stockage et contrôler l’accès à des secrets tels que les clés d’API, les mots de passe de base de données, les certificats et les clés de chiffrement utilisées pour l’authentification entre les systèmes distribués dans les environnements multi-cloud et hybrides. Il est généralement déployé dans les pipelines DevSecops.

Comme pour conjur, les chercheurs de Cyata ont effectué des revues de code manuel de Vault, en se concentrant sur les défauts logiques dans les composants responsables de l’authentification et de l’application des politiques, plutôt que sur la corruption de la mémoire ou les conditions de course généralement détectées par des outils automatisés. Cette approche a conduit à la découverte de neuf vulnérabilités, notamment le premier exploit d’exécution du code distant (RCE) dans l’histoire de 10 ans de Vault. Parce que ce sont des problèmes de logique profonde plutôt que des bugs au niveau de la surface, beaucoup étaient restés cachés dans la base de code pendant des années.

Les chercheurs ont commencé par examiner les méthodes d’authentification les plus couramment utilisées de Vault: Nom d’utilisateur et mot de passe traditionnels (UserPass); LDAP, qui s’appuie sur des services de répertoire comme Active Directory ou OpenLDAP; et l’authentification basée sur le certificat TLS, souvent utilisée pour la communication machine à machine.

Dans la méthode UserPass, ils ont trouvé un défaut qui a permis aux attaquants de déterminer s’il existe un nom d’utilisateur (énumération du nom d’utilisateur), ainsi qu’un moyen de contourner les protections par force brute qui devraient verrouiller les utilisateurs après plusieurs tentatives de connexion ratées. Dans la méthode LDAP, ils ont découvert des contournements de lock-out similaires et un moyen de contourner l’application de l’authentification multi-facteurs (MFA).

Pour la méthode MFA basée sur le temps basée sur le temps (TOTP), qui est activée sur de nombreux déploiements, ils ont identifié des bogues qui ont permis des contournements de protection contre la force brute, permettant aux attaquants de tenter de deviner les codes MFA sans déclencher de verrouillage.

Dans l’authentification basée sur le certificat (mode non-CA), les chercheurs ont découvert un défaut logique où Vault a vérifié seulement que la clé publique du certificat client TLS correspondait au certificat épinglé mais n’a pas vérifié que le nom du certificat (CN) correspond également. Étant donné que Vault utilise la valeur CN pour mapper pour un entityId interne, un attaquant ayant accès à la clé privée d’un certificat pourrait générer un certificat avec une clé publique valide mais un CN forgé, imitant une autre identité dans le système.

Une autre vulnérabilité a permis l’escalade des privilèges d’un compte d’administration à la racine, le plus haut niveau d’accès dans le système. Par conception, Vault empêche la politique racine d’être affectée à toute identité utilisateur, y compris les administrateurs, pour atténuer le risque de compromis complet du système. Cependant, les chercheurs ont trouvé un moyen de contourner cette barrière de sécurité.

La faille la plus critique impliquait de tirer parti du système de journalisation de Vault pour atteindre l’exécution de code arbitraire via des plug-ins, des binaires tiers qui étendent la fonctionnalité de Vault. Pour exploiter le système des plug-ins, les chercheurs devaient écrire du code arbitraire dans un fichier dans le répertoire des plug-ins et définir les autorisations exécutables. Ils l’ont atteint en manipulant le composant d’audit pour insérer du code malveillant dans les journaux à l’aide d’un préfixe personnalisé, puis en écrivant ces journaux dans le répertoire des plug-ins.

Cette vulnérabilité, désormais suivie sous le nom de CVE-2025-6000, est le résultat de plusieurs défauts logiques et existe depuis les premiers jours du projet Vault. Avec cet exploit, les attaquants pourraient supprimer un fichier critique contenant les clés nécessaires pour décrypter tous les secrets stockés, provoquant une perturbation de type ransomware, entre autres.

Cyata a rapporté les vulnérabilités à Hashicorp, qui les a depuis répartis dans les dernières versions logicielles. Des bulletins de sécurité détaillant les problèmes ont également été publiés aujourd’hui.

« Cette recherche renforce une vérité critique – même le logiciel sécurisé par la mémoire peut échouer au niveau logique – et quand il le fait, les conséquences peuvent être tout aussi graves », ont déclaré les chercheurs. «Vault est conçu pour être le protecteur ultime des secrets et de l’accès aux infrastructures. Mais ce travail montre comment des bogues logiques subtils dans les flux d’authentification, la résolution d’identité et l’application des politiques peuvent tranquillement rompre la confiance.»