Failles de sécurité : la vulnérabilité dans HashiCorp Vault décryptée par un exploit

En Août dernier, Vault de Hashicorp, une solution de coffre-fort sécurisé (solution permettant de sécuriser des tokens, des certificats, des mots de passe, des clés de chiffrements accessibles en ligne de commande, des API HTTP ou interface utilisateur) avait été découvert par deux vulnérabilités.

Des failles de sécurité critiques (CVE-2020-16250/16251), qui aujourd’hui sont bien évidemment corrigé. Cependant l’équipe de cybersécurité de Google, le Project Zéro a décidé de faire une description du mode opératoire permettant d’utiliser ces vulnérabilités. Un exploit qui a mis en avant le problème de la sécurité des solutions cloud en ce qui concerne en la gestion des identités.

Cet article va aussi vous intéresser : Une faille de sécurité touchant des cartes Visa permettant des pirates avec des smartphones tournant sous Android d’effectuer des paiements sans contact

« 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 », a notifié, Felix Wilhelm, un chercheur en sécurité de Project Zero.

C’est littéralement l’une des pires éventualités pour un coffre-fort sécurisé d’être touché par une faille de sécurité. Dans ce contexte il y en avait deux. Encore pire. Bien sûr il ne faut pas se leurrer. À l’instar de tout programme informatique ou tout système, il y a toujours une vulnérabilité quelque part. On peut prendre l’exemple de Last Pass, qui a corrigé plusieurs failles de sécurité affectant sa composition. Mais bien sûr le pire est passé vu que les vulnérabilités ont déjà été corrigées.

L’équipe de spécialistes en recherche de faille de sécurité de Google, un mois plus tard a décidé de faire une meilleure approche de la vulnérabilité et de ses potentielles conséquences. Si ces vulnérabilités étaient tombées entre les mains de personnes mal intentionnées. « 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 », note les chercheurs en sécurité informatique 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 ». Les vulnérabilités ont été précisément découvertes lors de l’utilisation de plate-forme tierces IAM cloud, celle fournie par Amazon Web services mais aussi GCP.

« J’ai écrit un POC d’exploit qui touche à la création et de la sérialisation 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 », note Felix Wilhelm, le chercheur en sécurité de Projet Zero. « 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 chercheur de Google précise par la suite : « Il est important de noter que le compte AWS utilisé pour cela n’a pas besoin d’avoir de relation avec notre cible ».

« 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 ». Note ce dernier. Au moment où, le décodeur Go XML ne prendra pas en compte tout le contenu de l’objet GetCallerIdentityResponse, Vault sera amené à considérer cette information comme une réponse STS CallerIdentity correct donc le validera.

« 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 ». Explique Felix Wilhelm

Pour sa conclusion, le chercheur de Project Zero de Google déclare : « 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 ».

Accédez maintenant à un nombre illimité de mot de passe :