Pour un coffre-fort sécurisé, être victime de failles de sécurité est certainement la pire des situations. Comme toute solution, ces coffres peuvent toutefois aussi avoir leurs faiblesses, comme cela a été le cas pour Last Pass par exemple qui a dû à plusieurs reprises corriger des failles. La solution Vault de HashiCorp de coffre-fort électronique permettant de mettre à l'abri tokens, mots de passe, certificats et autres clés de chiffrements accessibles en ligne de commande, API HTTP ou interface utilisateur, n'a pas fait exception. En août dernier, deux failles de sécurité (CVE-2020-16250/16251) ont ainsi dû être corrigées.

Un mois et demi plus tard, l'équipe Project Zero de Google spécialisé dans la découverte de failles, a décrit ces deux vulnérabilités permettant ainsi d'en savoir plus sur la méthode d'exploit rendant à risque ce coffre-fort électronique. « L'interfaçage avec Vault nécessite une authentification, et Vault prend en charge le contrôle d'accès basé sur les rôles pour régir l'accès aux secrets stockés », expliquent les chercheurs en sécurité de Google dans un billet de blog. « Pour l'authentification, il prend en charge les méthodes d'authentification enfichables allant des informations d'identification statiques, LDAP ou Radius, à l'intégration complète dans les fournisseurs tiers OpenID Connect ou les plateformes Cloud Identity Access Management ». Et c'est précisément en recourant à des plateformes tierces IAM cloud fournies par AWS mais aussi GCP que des faiblesses d'exploitation ont pu être identifiées.

Un POC d'exploit mis au point

« J'ai écrit un POC d'exploit qui touche à la création et de la serialisation de JWT. Bien que la configuration du fournisseur OIDC ajoute une certaine complexité, nous nous retrouvons avec un joli contournement d'authentification pour les rôles activés arbitrairement par AWS. La seule exigence est que l'attaquant connaisse le nom d'un rôle AWS privilégié dans le serveur Vault cible », explique le chercheur en sécurité de Projet Zero, Felix Wilhelm. « AWS IAM ne dispose pas d'un moyen simple de prouver l'identité d'un service à d'autres services non AWS. Les services tiers ne peuvent pas facilement vérifier les demandes pré-signées et AWS IAM ne propose aucune signature primitive standard qui pourrait être utilisée pour implémenter une authentification basée sur des certificats ou des JWT. En fin de compte, Hashicorp a corrigé la vulnérabilité en appliquant une liste d'autorisation d'en-têtes HTTP, en limitant les demandes à l'action GetCallerIdentity et en validant plus fortement la réponse STS, ce qui, espérons-le, est suffisant pour protéger contre les modifications inattendues de l'implémentation STS ou les différences de l'analyseur HTTP entre STS et Golang.

Le mode opératoire et schéma d'exploit a été décrit par le chercheur de Project Zero est le suivant : génération d'une paire de clés RSA et création d'un document OIDC discovery.json et key.json et hébergement des fichiers json sur un serveur Web. Puis utilisation du compte AWS pour enregistrer un IdP OID -> Mappage de rôle AWS IAM. « Il est important de noter que le compte AWS utilisé pour cela n'a pas besoin d'avoir de relation avec notre cible », note le chercheur. « Nous pouvons maintenant utiliser notre OIDP pour signer un JWT qui contient un GetCallerIdentityResponse arbitraire [...] Si tout se passe comme prévu, STS reflétera le sujet du jeton dans le cadre de sa réponse codée JSON ». Dès lors, le décodeur Go XML ignorera tout le contenu avant et après l'objet GetCallerIdentityResponse, ce qui amènera Vault à considérer cela comme une réponse STS CallerIdentity valide. « La dernière étape consiste à convertir cette demande sous la forme attendue par Vault et de l'envoyer au serveur Vault cible en tant que demande de connexion sur / v1 / auth / aws /s'identifier. Vault désérialise la demande, l'envoie à STS et interprète mal la réponse. Si AWS ARN / UserID GetCallerIdentityResponse a des privilèges sur le serveur Vault, il est alors possible de récupérer un jeton de session valide, que nous pouvons utiliser pour interagir avec le serveur Vault pour récupérer des données secrètes ».

GCP pas épargné

Felix Wilhelm ne s'est pas arrêté là et a décidé de pousser son investigation pour savoir si une telle vulnérabilité de Vault était réplicable sur un autre environnement cloud, à savoir Google Cloud Platform (GCP). Les fruits de ses travaux sont sans équivoque : « Aucun contrôle ne garantit qu'un jeton signé par un compte de service arbitraire ne contient pas de revendication GCE compute_engine. Alors que le contenu d'un jeton de métadonnées GCE est digne de confiance et contrôlé par Google, les jetons de compte de service sont entièrement contrôlés par le propriétaire du compte de service et peuvent donc contenir de revendications arbitraires ». En termes de configuration d'exploit d'attaque, le chercheur de Project Zero a fourni la description suivante : « Créez un compte de service dans un projet GCP que vous contrôlez et générez une clé privée à l'aide de gcloud: gcloud iam service-accounts keys create key.json --iam-account sa-name@project-id.iam.gserviceaccount.com. Signez un JWT avec une fausse revendication compute_engine décrivant une VM existante et privilégiée. Maintenant, utilisez simplement le jeton pour vous connecter à Vault: curl --request POST --data '{"role": "my-gce-role", "jwt": "...."}' http: // coffre-fort: 8200 / v1 / auth / gcp / login ».

« Un très bon développeur peut être capable de raisonner sur toutes les limites de sécurité, les exigences et les pièges de son propre logiciel, mais cela devient très difficile une fois qu'un service externe complexe entre en jeu », prévient Felix Wilhelm. « Les solutions IAM cloud modernes sont puissantes et souvent plus sécurisées que les solutions sur site comparables, mais elles présentent leurs propres écueils de sécurité et une grande complexité de mise en œuvre. Alors que de plus en plus d'entreprises se tournent vers les grands fournisseurs de cloud, la familiarité avec ces piles technologiques deviendra une compétence clé pour les ingénieurs et les chercheurs en sécurité et il est prudent de supposer qu'il y aura beaucoup de problèmes similaires dans les prochaines années ».