Abus d'accès transitif - Exfiltration de données via Document AI

¹⁶ septembre 2024

TLDR ;

‍Leservice Document AI permet involontairement aux utilisateurs de lire n'importe quel objet Cloud Storage dans le même projet.

• Mauvaise configuration du service Document AI : L'agent du service Document AI se voit attribuer automatiquement des autorisations excessives, ce qui lui permet d'accéder à tous les objets de Cloud Storage buckets dans le même projet.
• Risque d'exfiltration de données : des acteurs malveillants peuvent exploiter ce risque pour exfiltrer des données de Cloud Storage en exploitant indirectement les autorisations de l'agent de service.
• Abus d'accès transitif : Cette vulnérabilité est un exemple d'abus d'accès transitif, une catégorie de faille de sécurité dans laquelle un accès non autorisé est obtenu indirectement par le biais d'un intermédiaire de confiance. 
• Impact sur les clients de Google Cloud : Avec ce cas d'abus, les menaces vont au-delà des "autorisations risquées" de premier niveau et incluent une toile d'araignée de relations transitives non documentées. 

‍

Historique du service :

Document AI est un service Google Cloud qui extrait des informations de documents non structurés. Il propose à la fois des modèles pré-entraînés et une plateforme de création de modèles personnalisés. Dans le cadre de Vertex AI, Document AI s'intègre à d'autres services d'IA pour servir et partager des modèles.

Document AI utilise un compte de service géré par Google, souvent appelé agent de service, auquel est attribué le rôle documentaicore.serviceAgent lors du traitement par lots des documents. Ce compte gère l'ingestion, la transformation et la sortie des données à l'aide de ses autorisations de stockage Cloud . Cette approche réduit les frictions pour l'utilisateur final en automatisant la création de l'identité et l'attribution automatique des autorisations par rapport à l'alternative consistant à utiliser un compte de service géré par le client pour l'exécution, ce qui nécessiterait une configuration explicite et une attribution manuelle des rôles.

Description de la vulnérabilité

Document AI permet aux utilisateurs de traiter les documents stockés sur Cloud Storage en créant des tâches en ligne (standard) et des tâches de traitement hors ligne (par lots). Le service utilise l'agent de service Document AI Core avec le rôle documentaicore.serviceAgent pour gérer l'ingestion des données et produire les résultats lors du traitement par lots. Il est essentiel que cet agent de service dispose d'autorisations étendues pour accéder à n'importe quel godet de stockage Cloud au sein du même projet. 

Contrairement au traitement en ligne ou standard, où l'appelant initial à Document AI est le principal utilisé pour récupérer les objets GCS, en mode de traitement par lots, la récupération de toutes les données d'entrée et l'écriture des résultats dans un seau GCS sont exécutées dans le contexte de l'agent de service Document AI Core, à l'aide de ses permissions préattribuées. Étant donné que l'agent de service est utilisé comme identité dans le traitement par lots, les limites de permission de l'appelant initial ne sont pas respectées, ce qui permet l'exfiltration de données.

Le service Document AI utilise un emplacement d'entrée défini par l'utilisateur pour lire des données prétraitées et un emplacement de sortie pour écrire ses résultats. Cette capacité permet à un acteur malveillant d'exfiltrer des données de GCS vers un panier de stockage Cloud arbitraire, en contournant les contrôles d'accès et en exfiltrant des informations sensibles.

L'utilisation du service (et de son identité) pour exfiltrer des données constitue un abus d'accès transitif, qui contourne les contrôles d'accès prévus et compromet la confidentialité des données.

‍

Conditions préalables

1. Document existant Processeur AI

Supposons qu'un processeur existe dans un projet cible. Dans ce cas, un acteur malveillant n'a besoin que de l'autorisation documentai.processors.processBatch ou documentai.processorVersions.processBatch pour utiliser le processeur, lire les données de n'importe quel panier de stockage Cloud dans le projet et exfiltrer les objets vers un panier arbitraire.

‍

2. Création ou mise à jour d'un processeur

Si aucun processeur n'existe dans un projet cible, un acteur malveillant aurait en outre besoin de l'autorisation documentai.processors.create pour en créer un adapté à la lecture à partir d'un seau de stockage Cloud et écrire la sortie dans un autre. Par ailleurs, un processeur pourrait être modifié avec l'autorisation documentai.processors.update pour permettre l'ingestion via un seau GCS. 

‍

3. Document AI non utilisé précédemment

Si DocumentAI n'a pas été utilisé dans un projet, un attaquant doit activer le service avant de créer ou d'utiliser un processeur. L'activation de nouveaux services dans les projets GCP nécessite l'autorisation IAM serviceusage.services.enable Cloud et est incluse dans plus de 25 rôles prédéfinis, ainsi que dans l'éditeur et le propriétaire de rôles à gros grain. Lors de l'activation du service DocumentAI, l'agent de service associé et son rôle auto-attribué au niveau du projet sont créés, ne nécessitant aucune autorisation *.setIamPolicy de la part de l'enabler du service.

‍

Preuve de concept

Quatre modules Terraform sont fournis pour démontrer l'exfiltration de données par Document AI. Deux modules exploitent la fonction processeurs.processBatch et processorVersions.processBatch respectivement, en s'appuyant sur les autorisations étendues de l'agent de service pour copier les données d'un godet de stockage d'entrée Cloud vers un godet de sortie spécifié par l'utilisateur. En revanche, les deux autres modules présentent les modes en ligne standard, processors.process et processorVersions.process, qui récupèrent les données d'entrée dans le contexte de l'appelant d'origine, en respectant les contrôles d'accès prévus. Les méthodes de traitement par lots contournent effectivement ces contrôles en exécutant le travail en tant qu'agent de service de DocumentAI.    

‍

Réponse de Google 

Ce cas d'abus d'accès transitif a été signalé à Google par le biais de son programme de récompense des vulnérabilités le 4 avril 2024. Après plusieurs mois d'efforts de la part des chercheurs pour identifier la cause première du problème et proposer une solution, Google a accepté le rapport en tant que vulnérabilité, la classant dans la catégorie S2C "contournement de contrôles de sécurité importants", autres données/systèmes. La société a été informée de la divulgation publique prévue le 2 juillet.

Un compte rendu complet de la chronologie des rapports peut être consulté ci-dessous, mais il convient de noter les commentaires/actions suivants :

1. Google a déterminé que ".....le problème est dû à une documentation insuffisante ou incorrecte".
2. Le rapport trié dans le cadre du programme de récompense des vulnérabilités (VRP) est passé à l'état "corrigé", bien que le problème persiste.
3. Un encadré "Attention" a été ajouté à la page Rôles IAM de DocumentAI La page de documentation avertit les clients que "Les autorisations pour les documentai.processors.create et documentai.datasets.update sont très privilégiés". 
   1. L'avertissement suivant a été ajouté quelque temps après le dernier instantané d'Internet Archive, le 9 décembre 2023. Je n'ai aucun moyen de savoir s'il a été ajouté en réponse à mon rapport.

‍

1. Google est revenu sur sa décision de ne pas accorder de prime, citant une "documentation insuffisante ou incorrecte" comme cause première. La soumission du bogue a maintenant été classée comme un "contournement de contrôles de sécurité importants" et une prime lui a été attribuée. Il n'y a toujours pas d'indication sur la date ou la manière dont le cas d'abus sera corrigé.

‍

Recommandations pour Google

 L'agent de service Document AI ne doit pas se voir attribuer automatiquement des autorisations générales au niveau du projet. Bien que l'utilisation d'un compte de service géré par Google présente des avantages opérationnels, le fait de lui accorder un accès illimité au stockage Cloud en liaison avec des emplacements d'entrée/sortie définis par l'utilisateur présente un risque de sécurité important en raison d'un abus d'accès transitif. Le service peut fonctionner comme prévu, mais pas comme on s'y attendait.

Impact sur les clients de Google Cloud

Tous les clients de Google Cloud sont concernés par cette vulnérabilité s'ils n'empêchent pas l'activation du service DocumentAI et son utilisation via les contraintes de politique organisationnelle énumérées ci-dessous. Il n'est pas nécessaire qu'un client utilise DocumentAI pour être affecté. Le simple fait qu'un pirate puisse activer le service expose les données critiques à un risque d'exfiltration.

Lorsque les autorisations IAM ont des effets en chaîne les unes sur les autres, il devient impossible de répondre à la question "Qu'est-ce qui pourrait mal tourner" avec un service donné. Les prochaines étapes de Google pour protéger ses clients ne sont pas claires, qu'il s'agisse de proposer une contrainte de politique organisationnelle ou de supprimer complètement ce cas d'abus d'accès transitif.

‍

Atténuations

Malheureusement, le rapport soumis dans le cadre du Vulnerability Reward Program (VRP) de Google n'a donné lieu à aucune modification du service, malgré tous les efforts déployés. Les migrations mentionnées ci-dessous ne traitent pas la vulnérabilité sous-jacente, mais réduisent seulement l'impact potentiel pour le client. 

1. Segmentation au niveau du projet : Document AI doit être utilisé dans le cadre d'un projet segmenté et isolé. Ne combinez pas le service Document AI avec un projet contenant des données sensibles. Lors de l'utilisation d'un service SaaS ou ETL, configurez les emplacements des entrées et des sorties de manière transversale. Cela obligera à lier manuellement les permissions IAM pour tout agent de service plutôt que de compter sur des attributions automatiques.

 2. Restreindre l'API et le service : Utilisez la contrainte de politique d'organisation serviceuser.services pour empêcher l'activation du service Document AI lorsqu'il n'est pas nécessaire et restreignez l'utilisation de l'API avec la contrainte de politique d'organisation serviceuser.restrictServiceUsage.

‍

Conclusions

L'attribution de rôles et de permissions n'est qu'une partie de l'histoire, en particulier lorsque la fonctionnalité du service et la possibilité d'un accès transitif sont prises en compte. L'abus d'accès transitif n'est probablement pas isolé au service Document AI ; il se reproduira probablement dans tous les services (et chez tous les principaux fournisseurs de cloud ) à mesure que les modèles de menace seront mal compris.

La segmentation du stockage des données, de la logique commerciale et des charges de travail dans différents projets peut réduire le rayon d'action des agents de service disposant de privilèges excessifs, mais les clients comptent sur les fournisseurs cloud pour s'assurer qu'ils ne créent pas de voies d'escalade des privilèges dans leurs produits et leurs schémas IAM.

‍

Délai d'établissement des rapports et réponse

• 4 avril^th 2024 : Rapport initial : Exfiltration de données via Document AI Data Processing, Issue 332943600
  • [Google VRP] : "Bonjour, nous vous remercions de nous avoir fait part de votre rapport. Cet e-mail confirme que nous avons bien reçu votre message. Nous allons examiner le problème que vous avez signalé et vous contacterons dès que nous aurons une mise à jour. En attendant, vous pouvez consulter la liste des questions fréquemment posées sur Google Bug Hunters.

• 8 avril^th 2024 : Priorité modifiée P4 -> P3 et Statut modifié Nouveau -> Attribué
  • [Google VRP] : "Nous voulons juste vous faire savoir que votre rapport a été trié et que nous sommes en train de l'examiner".
• 9 avril^th 2024 : Type change Customer Issue -> Bug ; Severity change de S4 -> S2 ; Status change de Assigned -> In Progress (accepted)
  • [Google VRP] : "Merci encore pour votre rapport. J'ai signalé un bogue à l'équipe produit responsable sur la base de votre rapport. L'équipe produit évaluera votre rapport et décidera si un correctif est nécessaire. Nous vous ferons savoir si le problème a été résolu. En ce qui concerne notre programme de récompense pour les vulnérabilités : À première vue, il semble que ce problème ne soit pas suffisamment grave pour donner droit à une récompense. Toutefois, le comité VRP examinera le problème de plus près lors de sa prochaine réunion. Nous vous tiendrons au courant dès que nous aurons pris une décision. Si vous ne recevez pas de réponse de notre part dans les 2 à 3 semaines ou si vous avez des informations supplémentaires sur la vulnérabilité, faites-le nous savoir ! "
• ⁹ avril 2024 - [Kat Traxler] : "Comme toujours, merci pour le triage rapide. Si je peux vous aider à décrire les risques de la configuration actuelle, n'hésitez pas à me contacter. Merci, Kat"
• ³⁰ avril 2024 - [Kat Traxler] : "Bonjour, je vous envoie ce message en haut de votre boîte de réception. Je voudrais savoir si cela a été classé comme un risque d'abus ou si une mise à jour du service est à venir. Merci, Kat"
• ² mai 2024 - [Google VRP] : "Bonjour ! Les membres du panel n'ont pas encore pris de décision sur ce rapport ; le panel se réunit deux fois par semaine, et votre rapport est pris en compte à chaque réunion. Nous sommes désolés pour ce retard et vous remercions de votre patience. Vous recevrez un courriel automatique dès qu'une décision aura été prise."
• ² mai 2024 - [Kat Traxler] : "Merci pour la mise à jour. Si je n'ai pas de nouvelles d'ici ~4 semaines, je referai un ping"
• ⁷ mai 2024 - [Google VRP] : "** NOTE : This is an automatically generated email **Hello, Google Vulnerability Reward Program panel has decided that the security impact of this issue does not meet the bar for a financial reward. Cependant, nous aimerions reconnaître votre contribution à la sécurité de Google sur notre page Mentions honorables à l'adresse https://bughunters.google.com/leaderboard/honorable-mentions. Si vous souhaitez y être ajouté, veuillez créer un profil à l'adresse https://bughunters.google.com, si vous ne l'avez pas encore fait. Justification de cette décision : Nous avons déterminé que le problème était dû à une documentation insuffisante ou incorrecte. Veuillez noter que le fait que ce problème ne soit pas récompensé ne signifie pas que l'équipe produit ne le corrigera pas. Nous avons signalé un bogue à l'équipe chargée des produits. Elle examinera votre rapport et décidera si un correctif est nécessaire. Nous vous ferons savoir si le problème a été résolu. Salutations, Google Security Bot"
• ⁷ mai 2024 : - [Kat Traxler] : "Merci pour la réponse !"
• 22 juin^nd 2024 : Statut modifié en "Fixe"
  • [Google VRP] : "Nos systèmes indiquent que tous les bogues que nous avons créés sur la base de votre rapport ont été corrigés par l'équipe produit. N'hésitez pas à vérifier et à nous faire savoir si tout semble correct de votre côté. Merci encore pour votre aide !"
• ²⁵ juin 2024 - [Kat Traxler] : "Bonjour. Je constate que ce problème persiste. Les documents et les données d'entraînement peuvent être exportés en utilisant les autorisations de l'agent de service Document AI Core, ce qui permet à un utilisateur qui n'a pas accès au stockage d'exfiltrer des données. Notez que cette capacité existe dans les méthodes : google.cloud.documentai.uiv1beta3.DocumentService.ExportDocuments et dans les capacités de traitement par lots : (processors.batchProcess & processorVersions.batchProcess & processors.batchProcess) Faites-moi savoir si vous avez besoin d'autres POCs"
• ²⁶ juin 2024 - [Google VRP] : "Bonjour ! Merci pour votre réponse, nous avons mis à jour le bug interne pour l'équipe qui travaille sur le problème."
• ² juillet 2024 - [Kat Traxler] : "Bonjour. Compte tenu de la récente 'fausse alerte' selon laquelle ce problème a été résolu, j'ai commencé à m'inquiéter de ne pas avoir communiqué le risque et l'impact de manière appropriée. J'ai donc créé un déploiement de la TF et enregistré un POC pour que vous et l'équipe de service puissiez le regarder. Le déploiement de la FO est disponible à l'adresse suivante : https://github.com/KatTraxler/document-ai-samples POC video at this drive link. Il faut insister sur le fait que le principal qui peut traiter (ou traiter par lots) des documents avec Document AI n'a pas besoin d'avoir des autorisations de stockage pour accéder aux données dans le stockage Cloud et les déplacer vers un autre emplacement (exfiltration des données), ce qui est possible grâce aux autorisations attribuées à Document AI P4SA. (roles/documentaicore.serviceAgent). Je recommande d'attribuer à Document AI un compte de service géré par l'utilisateur pour le traitement des données, à l'instar de Cloud Workflows. Permettre au P4SA de déplacer des données définies par l'utilisateur n'est pas le bon modèle et a conduit à une vulnérabilité d'exfiltration de données. Veuillez changer le statut de ce problème pour indiquer qu'il n'a pas été corrigé. La divulgation publique aura lieu lors d'un événement très médiatisé en septembre 2024"
• ⁴ juillet 2024 - [Google VRP] : "Bonjour, nous vous remercions pour les informations complémentaires sur le cas, nous allons envoyer un ping à l'équipe produit. Et merci pour l'information concernant la divulgation de votre rapport. Veuillez lire notre position sur la divulgation coordonnée. En substance, nous nous engageons à vous répondre rapidement et à corriger les vulnérabilités dans un délai raisonnable - et en échange, nous demandons un préavis raisonnable."
• ²⁹ juillet 2024 - [Kat Traxler] : "Bonjour l'équipe. Je vous préviens encore une fois que je parlerai du risque d'exfiltration de données via le service DocumentAI à fwd:CloudsecEU le 17 septembre : https://pretalx.com/fwd-cloudsec-europe-2024/talk/BTT9LJ/ Avec un blog d'accompagnement qui sera publié la veille, le 16 septembre. Merci, Kat"
• ³⁰ juillet 2024 - [Google VRP]: "Bonjour, merci beaucoup de m'avoir prévenu !"
• ⁵ août 2024 - [Kat Traxler] : "Merci. Puis-je suggérer de changer le statut de ce rapport pour qu'il ne soit plus "corrigé" ? Puisqu'il n'est pas corrigé, merci encore. Kat"
• ¹² août 2024 - [Google VRP] : "Bonjour, serait-il possible de partager une ébauche de la présentation et/ou de l'article de blog avec nous avant la divulgation ? Merci"
• ¹² août 2024 : Commentaire de Kat Traxler : "Je suis plus qu'heureuse de le faire. Je suis particulièrement intéressée par vos commentaires sur l'exactitude et la coordination des avis. L'article de blog sera prêt pour le²⁶ août^".
• ¹³ août 2024 - [Google VRP] : "Bonjour, merci !"
• ²¹ août 2024 - [Google VRP] : "Bonjour Kat, Merci encore pour votre rapport et pour votre patience ! L'équipe vient de s'asseoir et de discuter de votre soumission en équipe de manière beaucoup plus détaillée. Nous avons décidé de déposer un bogue auprès de l'équipe produit après avoir délibéré pour savoir s'il s'agissait d'un WAI ou d'une vulnérabilité. Nous avons fait cela parce que le comportement n'est pas clair de votre point de vue, mais l'équipe produit est la mieux placée pour déterminer si quelque chose est WAI ou non. Le bogue interne a été rouvert le 9 juillet suite à votre commentaire et nous allons travailler avec l'équipe produit pour faire cette détermination. Nous allons également rouvrir le problème 332943600 pour refléter cela maintenant - cela aurait dû être fait en juillet, désolé ! Encore une fois, nous vous remercions de nous avoir contactés et de nous avoir fait part de votre problème !
  L'équipe de chasseurs de bugs de Google"
• ²² août 2024 - [Kat Traxler] : "Merci pour la mise à jour et le changement de statut. Pouvez-vous partager vos définitions de WAI et de vulnérabilité ? Pour moi, un problème peut à la fois fonctionner comme prévu (WAI) et avoir un impact négatif significatif sur la sécurité. Je vous remercie. Kat"
• ⁹ septembre 2024 - [Google VRP] : "Le panel du programme Google Vulnerability Reward Program a décidé d'attribuer une récompense de 3133,70 $ pour votre rapport. Félicitations ! Raison de cette décision : Applications Google normales. La catégorie de vulnérabilité est "contournement de contrôles de sécurité importants", autres données/systèmes. Nous avons appliqué un déclassement car l'attaquant doit avoir accès au projet d'une victime impactée."

 Recherche connexe

 Pour plus d'informations sur les agents de service GCP et leurs modèles de menace, veuillez consulter la série GCP IAM 201 couvrant ces sujets :

• GCP IAM 201 - Agents de service
• GCP IAM 201 - Modèle de menace pour les agents de service

‍