Et si les utilisateurs IAM pouvaient générer librement des clés API AWS sans restriction ? Et si les administrateurs de sécurité n'avaient pas de visibilité sur la création des clés API et ne pouvaient pas vérifier qui utilise les clés API ?
Bien que ce scénario ne s'applique pas à AWS, c'est une dure réalité pour les clés HMAC de Google Cloud . Ce blog présente trois vulnérabilités apparues dans la manière dont Google Cloud gère les clés HMAC associées à l'utilisateur.
1. Vulnérabilité n° 1 - Journalisation insuffisante
2. Vulnérabilité n° 2 - Titres de compétences à long terme non gérables
3. Vulnérabilité n° 3 - Informations d'identification à long terme non vérifiables
TLDR ;
- Les clés HMAC ont une utilité pratique. Elles peuvent être utilisées pour créer des en-têtes signés Sigv4 utilisés pour s'authentifier auprès de l'API XML de stockageCloud , et ce jusqu'à 7 jours après la création initiale.
- Les journaux d'audit de Google Cloud n'enregistrent pas les événements de création ou de suppression de clés HMAC lorsqu'ils sont associés à des comptes d'utilisateurs.
- Les administrateurs ne disposent pas de l'API Google Cloud , ce qui les empêche de vérifier l'existence des clés HMAC associées aux comptes d'utilisateurs.
- Aucune autorisation IAM Cloud n'est disponible pour restreindre la création, la suppression ou l'utilisation des clés HMAC.
- Ce problème a été signalé via le programme de récompense des vulnérabilités de Google et l'entreprise a fermé le problème sans fournir de solution, arguant que le comportement signalé fonctionne comme prévu.
Utilisation des clés HMAC
Les API pour la création et la suppression des clés HMAC associées aux comptes d'utilisateurs ne sont pas accessibles de l'extérieur. Ces actions ne peuvent être effectuées que par le service API privé de la console cloud (cloudconsole-pa), accessible via l'onglet interopérabilité de la console de stockage. Les URL identifiées ci-dessous représentent les points d'extrémité de la console cloud utilisés pour créer et supprimer les clés HMAC associées à l'utilisateur lorsqu'elles sont accompagnées d'un cookie de connexion valide.
- Une requête POST vers `/v3/entityServices/StorageEntityService/entities/STORAGE_USER_HMAC/CREATE` crée une clé HMAC utilisée dans le processus de signature Sigv4.
- Une requête POST vers `/v3/entityServices/StorageEntityService/entities/STORAGE_USER_HMAC/DELETE` supprime un HMAC associé à un utilisateur.
Les utilisateurs de Google Cloud peuvent créer une quantité apparemment infinie de ressources de ce type : "type.googleapis.com/google.internal.cloud.console.clientapi.storage.UserHmac"
Aucune limite supérieure des clés HMAC n'a été identifiée lors des essais, et aucune limite de classement n'a été rencontrée.
Vulnérabilité n° 1 - Journalisation insuffisante
Cloud Les journaux d'audit ne capturent pas les actions médiées par le service API privé de la console cloud (cloudconsole-pa). Par conséquent, il n'y a pas d'enregistrement de la création ou de la suppression de clés HMAC liées à des comptes d'utilisateurs. Cette absence de journaux entrave la capacité des défenseurs à alerter ou à surveiller la création de clés HMAC pour les comptes d'utilisateurs, ce qui présente un risque de persistance, ou leur suppression, ce qui présente un risque de déni de service.
Vulnérabilité n°2 - Des références à long terme non gérables
Les utilisateurs ayant accès à Google Cloud peuvent créer des clés HMAC, ce qui nécessite au moins l'autorisation resource manager.projects.get. Cependant, il n'existe pas d'autorisation IAM Cloud permettant de gérer les clés HMAC pour soi-même ou pour d'autres utilisateurs, ce qui empêche les administrateurs de contrôler leur création. Par conséquent, cet avis ne fournit pas de recommandations pour atténuer le risque d'exposition des clés HMAC en limitant l'attribution des autorisations.
Vulnérabilité n° 3 : informations d'identification à long terme non vérifiables
Cloud Les administrateurs sont confrontés à des difficultés dans la gestion des clés HMAC au sein de leur entreprise, car ils n'ont pas de visibilité sur les comptes utilisateurs qui ont généré ces clés et ne savent pas si elles sont activement utilisées pour accéder aux objets de stockage. En outre, il n'existe pas de fonctionnalité permettant de révoquer les clés associées à d'autres utilisateurs, ce qui limite leur capacité à appliquer efficacement les politiques de sécurité.
Les équipes de réponse aux incidents s'appuient sur Cloud Logging pour surveiller l'accès aux objets de stockage Cloud , mais elles manquent d'indicateurs spécifiques pour déterminer si les clés HMAC sont utilisées dans ces tentatives d'accès. Alors que diverses actions de confinement, telles que la suspension ou la suppression des comptes d'utilisateurs compromis, peuvent initialement sembler efficaces en rejetant les en-têtes signés Sigv4 créés précédemment, la réactivation ou la recréation du même utilisateur permet la réutilisation des informations d'identification à moins qu'elles n'aient expiré.
En outre, la suppression de Cloud IAM Roles peut révoquer l'accès aux ressources de stockage concernées. Cependant, il est important de noter que la réaffectation des rôles n'invalide pas les en-têtes signés Sigv4 créés précédemment, ce qui leur permet de continuer à fonctionner même après le changement de rôle.
Cas d'abus de la clé HMAC
Un attaquant en possession d'un compte utilisateur Google ayant accès à un projet Google Cloud et disposant au minimum de l'autorisation `resource manager.projects.get` est en mesure de générer des clés HMAC dans l'onglet interopérabilité de la console de stockage.
Une attaque utilisant les clés HMAC peut se dérouler comme suit :
1. Un pirate compromet un compte d'utilisateur Google
2. Génère une clé HMAC pour l'utilisateur
3. Utilise la clé HMAC pour générer une série d'en-têtes signés Sigv4 avec une expiration de 7 jours.
4. Exfiltre les données de Google Cloud Storage jusqu'à l'expiration de la signature de l'en-tête.
5. L'identification de l'accès au stockage malveillant et/ou de la réponse est entravée par les vulnérabilités n° 1, 2 et 3 décrites ci-dessus.
6. Les tentatives de confinement peuvent être soit inefficaces, comme la modification du mot de passe de l'utilisateur compromis, soit temporaires, si un utilisateur affecté est suspendu puis réactivé ultérieurement.
Preuve de concept
Le SDK Google Cloud ne propose pas de fonctionnalité permettant de convertir une clé HMAC associée à l'utilisateur en informations d'identification utilisables par le biais du processus de signature Sigv4. C'est pourquoi nous avons fourni un simple script d'aide en python qui permet de le faire. Il prend en compte l'identifiant de la clé d'accès, le secret, le nom de l'objet et du seau et renvoie une requête curl avec un en-tête d'autorisation signé qui sera utilisé pour récupérer l'objet GCS ciblé via l'API XML.
La preuve de concept est fortement influencée par un article de Rosy Parmar sur l'utilisation de HMAC pour s'authentifier sur Google Cloud.
Recommandations
À la lumière des nombreux abus associés aux clés HMAC spécifiques à l'utilisateur, nous présentons ici une série de recommandations visant à améliorer la gestion, l'enregistrement et le cycle de vie des clés HMAC dans le cadre des BPC.
1. Permissions et API
- Introduire des API et des autorisations associées qui donneront aux administrateurs le pouvoir de créer et de supprimer des clés HMAC spécifiques à l'utilisateur en fonction des besoins.
- Créer des API et des autorisations associées permettant aux administrateurs de l'espace de travail Google d'auditer les clés HMAC de tous les utilisateurs de leur organisation, leur utilisation et la possibilité de supprimer des clés pour d'autres utilisateurs.
2. Contraintes de la politique de l'Org
- Créer une contrainte de politique d'organisation permettant aux administrateurs de politiques d'empêcher la création de clés HMAC associées à l'utilisateur.
3. Enregistrement
- Write to Admin Activity admin enregistre la création et la suppression de toutes les clés HMAC, y compris celles associées aux utilisateurs.
- Indiquer dans les journaux de Cloud lorsque l'accès à l'API XML de stockage de Cloud se fait à l'aide d'un justificatif d'identité d'en-tête Sigv4.
4. Gestion des justificatifs
- Limiter le nombre de clés HMAC qu'un utilisateur peut créer à un maximum de deux.
- Introduire une date d'expiration configurée par l'utilisateur pour les clés HMAC.
- N'afficher les clés HMAC aux utilisateurs qu'une seule fois, au moment de leur création, et ne pas communiquer de secrets à l'interface utilisateur lors des demandes ultérieures.
Calendrier de divulgation
2/07/24 [Kat Traxler] : Signalé au programme de récompense des vulnérabilités de Google sous le titre "HMAC keys generated for users pose security risks, notably due to the absence of logging events upon their creation or deletion" (Les clés HMAC générées pour les utilisateurs posent des risques de sécurité, notamment en raison de l'absence d'événements de journalisation lors de leur création ou de leur suppression).
2/07/24 [Google] : Confirme la réception du rapport
2/08/24 [Google] : A indiqué qu'il fermait le problème en raison du manque de détails. Demande d'un scénario d'attaque et d'une preuve de concept.
02/09/24 [Kat Traxler] : A répondu avec une description plus détaillée des actions de l'attaquant compte tenu des caractéristiques des clés HMAC et une promesse d'écrire un PoC.
2/12/24 [Google] : Statut modifié en "Assigné, Ré-ouvert, Trié".
16/02/24 [Google] : L'équipe de chasseurs de bogues de Google a rappelé les détails de la vulnérabilité signalée, a demandé un exemple d'en-tête signé Sigv4 et a demandé si les informations d'identification peuvent être utilisées pour accéder à autre chose que l'API XML de stockage de Google Cloud .
18/02/24 [Kat Traxler] : Réponse à la série de questions et confirmation que les identifiants générés à partir des clés HMAC ne peuvent être utilisés que pour accéder à l'API XML de stockage de Google Cloud .
19/02/24 [Kat Traxler] : Fourni à l'équipe Google Bug Hunter un lien vers un PoC hébergé sur Github leur permettant de générer leurs propres en-têtes signés avec des clés HMAC.
28/02/24 [Google] : Le problème a été "identifié comme un risque d'abus et transmis à notre équipe de confiance et de sécurité".
28/02/24 [Google] : A répondu en remerciant pour le rapport et en indiquant que l'équipe était en train d'analyser la soumission.
04/01/24 [Kat Traxler] : "Suivi de ce rapport. Cela fait environ 4 semaines que nous nous sommes parlés. Pour rappel, je prévois de divulguer ce problème aux alentours de la première semaine de juin. J'aimerais utiliser le temps dont nous disposons pour coordonner avec l'équipe de service la mise en œuvre de la journalisation manquante et des contrôles IAM. En l'absence de nouveaux événements enregistrés et de nouveaux contrôles IAM, la divulgation ne contiendra que des détails sur le mécanisme de persistance, sans aucune indication pour les clients sur la manière de l'empêcher ou de le détecter. Personne n'aime ce genre de blog de divulgation. *Je vous prie de me faire savoir comment je peux contribuer à élever ce problème ou à assurer la coordination avec les parties responsables".
4/02/24 [Google] : "🎉 Bien vu ! J'ai déposé un bogue auprès de l'équipe produit responsable sur la base de votre rapport. Nous allons travailler avec l'équipe produit pour nous assurer que ce problème est résolu. Nous vous informerons lorsque le problème aura été résolu."
4/11/24 [Google] : "Le comité du programme Google Vulnerability Reward a décidé que l'impact de ce problème sur la sécurité n'est pas suffisant pour justifier une récompense financière."
6/04/24 [Google] : "Nos systèmes indiquent que le bogue que nous avons créé sur la base de votre rapport a été fermé sans qu'un correctif ait été apporté. Cela peut être dû à diverses raisons : l'impact sur le risque peut être trop faible pour justifier une correction, il peut y avoir d'autres facteurs atténuants, ou simplement le produit n'est plus maintenu. Le statut exact est INTENDED_BEHAVIOR. Cette décision a été prise par les équipes de produits concernées et n'affecte pas le montant de votre récompense VRP ni votre position dans le classement. Nous ne pouvons pas fournir plus de détails dans cette notification automatisée, mais nous serons heureux de répondre à vos questions concernant cette décision."