SAPwned : des vulnérabilités de l’IA de SAP exposent les environnements cloud des clients et des livrables IA privés

• Wiz Research a confirmé qu’une chaîne de vulnérabilités d’isolation entre tenants dans SAP AI Core permettait de partir d’une exécution de code dans une tâche d’entraînement IA légitime pour aboutir à la prise de contrôle du service et à l’accès à des secrets clients
• Le chemin d’attaque reposait sur un enchaînement de contournement des restrictions réseau d’Istio, d’exposition de jetons AWS dans la configuration de Loki, de partages EFS sans authentification et d’un accès non authentifié à Helm v2 Tiller
• Avec les privilèges obtenus, il était possible de lire et modifier des images et artefacts dans le Docker Registry interne de SAP, Google Container Registry et l’Artifactory interne, ainsi que d’obtenir les privilèges cluster-admin sur le cluster Kubernetes
• Un attaquant potentiel pouvait accéder aux identifiants AWS, Azure et SAP HANA Cloud des clients, ainsi qu’à des livrables IA privés comme des modèles, des jeux de données et du code, ou encore compromettre des artefacts internes
• SAP a corrigé toutes les vulnérabilités signalées et fait une rotation des secrets concernés, et Wiz a indiqué qu’aucune compromission de données clients n’avait eu lieu

---

Problème d’isolation entre tenants révélé dans SAP AI Core

• Wiz Research étudie l’isolation entre tenants chez les fournisseurs de services IA, et SAP AI Core constitue son troisième rapport après Hugging Face et Replicate
• SAP AI Core est un service managé qui permet aux utilisateurs de développer, entraîner et exécuter des services IA sur les ressources cloud de SAP
• Les services d’entraînement IA doivent accéder à de grands volumes de données clients sensibles, et SAP AI Core utilise des clés d’accès cloud pour accéder aux données internes des clients afin d’intégrer HANA et d’autres services cloud
• L’étude a commencé avec un compte client SAP disposant des privilèges de base, en créant un projet IA puis en générant un Pod Kubernetes via un fichier Argo Workflow autorisé par SAP AI Core
• Les utilisateurs pouvaient, par conception, exécuter du code arbitraire dans le Pod, mais dans l’environnement initial, le sidecar proxy Istio limitait l’accès réseau, ce qui rendait difficile le scan du réseau interne

Bug n°1 : contournement des restrictions d’Istio

• Le contrôleur d’admission de SAP bloquait les options de sécurité dangereuses, y compris les tentatives d’exécuter un conteneur en root
• Deux paramètres non bloqués ont cependant permis de contourner les restrictions réseau
  • shareProcessNamespace permettait de partager l’espace de noms des processus avec le conteneur sidecar, donnant accès à la configuration du proxy Istio et au jeton d’accès au serveur central Istiod
  • runAsUser et runAsGroup autorisaient d’autres UID que root, ce qui permettait d’exécuter le processus avec l’UID d’Istio, 1337
• Istio lui-même est exclu des règles iptables d’Istio, de sorte qu’un processus exécuté avec l’UID 1337 fonctionnait sans restriction de trafic
• Il a ensuite été possible d’utiliser le jeton Istio pour lire la configuration du serveur Istiod et récupérer des informations sur l’environnement interne

Bug n°2 : exposition de jetons AWS dans la configuration de Loki

• Une instance Grafana Loki a été découverte à l’intérieur du cluster, et une requête sur l’endpoint /config permettait d’afficher toute sa configuration
• La réponse contenait les secrets AWS utilisés par Loki pour accéder à S3
• Ces secrets donnaient accès au bucket S3 de Loki, qui contenait de nombreux logs du service AI Core et des logs des Pods clients
• SAP estime que ces logs n’étaient pas sensibles

Bug n°3 : exposition de fichiers utilisateurs via des partages EFS sans authentification

• Six instances AWS Elastic File System, soit des EFS, écoutant sur le port 2049, ont été découvertes sur le réseau interne
• Ces instances EFS permettaient de consulter ou modifier des fichiers sans identifiants, dès lors qu’un accès réseau était possible
• Le contenu des partages était librement accessible avec de simples outils NFS open source
• Les EFS stockaient de grands volumes de données IA, notamment du code et des jeux de données d’entraînement classés par identifiant client

Bug n°4 : un Helm Tiller sans authentification expose le Registry interne et Artifactory

• Le service Tiller, composant serveur de Helm v2, a été découvert sur le réseau interne
• Tiller communique via une interface gRPC sur le port 44134 et est exposé par défaut sans authentification
• L’interrogation de Tiller a révélé des secrets à forts privilèges pour le Docker Registry de SAP et le serveur Artifactory
• Avec les droits de lecture, il était possible de consulter des images et builds internes afin d’extraire des secrets commerciaux et des données clients
• Avec les droits d’écriture, il était possible de compromettre des images et builds et de mener une attaque de la chaîne logistique contre le service SAP AI Core

Bug n°5 : prise de contrôle du cluster Kubernetes via les droits d’écriture de Helm Tiller

• Tiller autorisait non seulement la lecture, mais aussi les opérations d’écriture
• Comme la commande install récupère un package Helm et le déploie sur le cluster Kubernetes, l’équipe de recherche a créé puis installé un package Helm malveillant capable de générer un nouveau Pod avec les privilèges cluster-admin
• Cette opération a permis d’obtenir le contrôle total du cluster
• Ce niveau de privilèges permettait d’accéder directement aux Pods d’autres clients et d’en voler des données sensibles comme des modèles, des jeux de données et du code
• Il permettait aussi de perturber les Pods clients, d’altérer les données IA et de manipuler les inférences des modèles
• Avec les mêmes privilèges, il était également possible de consulter en clair des secrets clients dépassant le périmètre de SAP AI Core
  • Le compte AI Core de l’équipe contenait un secret de compte AWS pour l’accès aux données S3
  • Il contenait un secret de compte SAP HANA pour l’accès au Data Lake
  • Il contenait un secret de compte Docker Hub pour le pull d’images
• La même consultation a aussi mis au jour une clé d’accès SAP nommée sap-docker-registry-secret pour Google Container Registry, avec des droits de lecture et d’écriture

Étendue d’accès confirmée et impact potentiel

• La chaîne de vulnérabilités permettait notamment les actions suivantes
  • lire et modifier des images Docker dans le Registry de conteneurs interne de SAP
  • lire et modifier des images Docker SAP dans Google Container Registry
  • lire et modifier des artefacts sur le serveur Artifactory interne de SAP
  • obtenir les privilèges cluster-admin sur le cluster Kubernetes de SAP AI Core
  • accéder aux identifiants cloud des clients et à des livrables IA privés
• Un attaquant potentiel pouvait accéder aux données clients et compromettre des artefacts internes, avec un impact pouvant ensuite se propager aux services associés et à d’autres environnements clients
• Toutes les vulnérabilités ont été signalées à l’équipe sécurité de SAP, puis corrigées par SAP, qui a reconnu ces travaux sur sa page de crédits aux chercheurs en sécurité
• Les données clients n’ont pas été compromises

Problèmes mis en évidence du point de vue défensif

• La principale ligne de défense reposait sur Istio pour bloquer l’accès au réseau interne, mais une fois cette barrière contournée, plusieurs actifs internes ne demandaient aucune authentification supplémentaire
• Le réseau interne était traité comme une zone de confiance, si bien qu’un seul contournement pouvait se transformer en prise de contrôle du service
• Si les services internes avaient été davantage renforcés, l’impact aurait pu être limité à un incident de sécurité mineur plutôt qu’à une compromission complète du service
• Les services managés basés sur Kubernetes peuvent créer des pièges d’isolation entre tenants, car le plan de contrôle et le calcul client sont reliés logiquement par des API, des identités, du calcul partagé et une segmentation réseau logicielle
• L’entraînement IA exige par nature l’exécution de code arbitraire, ce qui impose des garde-fous afin que ce code non fiable reste correctement isolé des actifs internes et des autres tenants

Calendrier de divulgation

• 25 janvier 2024 : Wiz Research signale ses découvertes de sécurité à SAP
• 27 janvier 2024 : SAP répond et attribue un numéro de dossier
• 16 février 2024 : SAP corrige la première vulnérabilité et fait une rotation des secrets associés
• 28 février 2024 : Wiz Research contourne le correctif avec 2 nouvelles vulnérabilités et les signale à SAP
• 15 mai 2024 : SAP déploie des correctifs pour l’ensemble des vulnérabilités signalées
• 17 juillet 2024 : divulgation publique

[GN⁺]

Avis sur Hacker News

• Je comprends qu’il s’agisse d’un produit d’IA, mais ici la vulnérabilité se trouve dans la configuration k8s
  Cela n’a pas grand-chose à voir avec le produit d’IA lui-même, l’entraînement de l’IA, le machine learning ou l’IA générative ; cela relève plutôt d’une mauvaise sécurité de plateforme cloud

  • Cela pourrait même être pire. Pour une entreprise aussi grande que SAP, qui manipule beaucoup d’informations importantes, cela revient à avoir raté les bases de la sécurité cloud ; on n’a pas l’impression qu’ils se sont trompés sur quelque chose de nouveau, mais qu’ils ont commis une erreur courante
  • L’article ne dit pas que le problème vient du produit lui-même. Au contraire, il explique bien qu’il s’agit d’un problème d’isolation des modèles d’entraînement IA
    Le fait que « l’attaquant ait pu exécuter un modèle d’IA malveillant et une procédure d’entraînement » est la cause racine, et c’est, par nature, de l’exécution de code
    Je comprends que cela ait été étudié et investigué parce que les produits d’IA se répandent largement et qu’il faut donc faire attention à leur infrastructure
  • La marque commercialisée doit en assumer la responsabilité
    Appliquer la sécurité, connaître les besoins de sécurité, tester, ou ne pas lancer tant que ce n’est pas sûr : tout cela relève du rôle de vendeur de cette marque

• J’espère que SAP fera un solide retour d’expérience sur les raisons pour lesquelles les recherches de Wiz n’ont pas été bloquées avant d’atteindre les droits d’administrateur complets du cluster
  J’aimerais savoir si SAP a reçu des alertes sur cette activité et si elle a fait l’objet d’une enquête correcte. Je me demande aussi si SAP est soumise à des réglementations exigeant un système d’alerte suffisant sur les activités réseau suspectes, et si cette recherche pourrait constituer une preuve qu’ils ne les respectaient pas

  • Des règles et des réglementations existent clairement. Il suffit de voir la page des certifications : https://www.sap.com/about/trust-center/certification-complia...
    La question est de savoir si elles sont réellement respectées, ou si elles ne figurent que dans un classeur posé sur une étagère
  • En général, un chercheur en sécurité doit contacter la cible avant d’aller plus loin dans le système, afin d’obtenir l’autorisation de continuer
    Les programmes de bug bounty exigent souvent ce genre de règles dans leur périmètre. Comme le chercheur travaille pour une société de sécurité, je m’attendrais à ce que ce soit aussi le cas ici
    Les chercheurs indiquent généralement dans l’article à quel moment ils ont demandé une autorisation supplémentaire, mais ce n’est pas systématique
  • S’ils ne l’ont effectivement pas détecté, je me demande comment ils peuvent savoir que les données client n’ont pas été compromises
  • SAP manque de compétences en sécurité cloud. La liste des problèmes de sécurité des services cloud de SAP est longue, et ce ne sont que ceux qui sont connus
  • Ce serait bien d’avoir un article montrant comment détecter ce genre de choses dans l’IA

• Je suis choqué qu’une instance tiller soit encore en cours d’exécution. Elle n’est plus prise en charge depuis 2020 : https://helm.sh/blog/helm-v2-deprecation-timeline/

  • Vous seriez horrifié de voir combien de logiciels d’avant 2020, voire d’avant 2010, tournent encore en production
    Ici, il s’agit d’une grande entreprise et d’une migration hors de tiller qui peut être assez complexe, mais même sans ces circonstances atténuantes, on trouve facilement de vieux logiciels
  • D’après mon expérience, « fin de support » est souvent compris comme « ce n’est pas encore supprimé, donc on peut continuer à l’utiliser », ce qui est parfois assez décourageant
  • Microsoft Dynamics contient énormément de code legacy ancien, non sécurisé et non corrigé

• C’est vraiment mauvais. Ils exploitaient un unique cluster K8s en s’attendant à de fortes garanties de multi-tenant ?
  Tous les grands clouds utilisent des frontières de machines virtuelles entre clients et des clusters K8s distincts. Microsoft s’est aussi fait avoir de manière similaire il y a quelques années avec l’un de ses produits de fonctions, qui comptait sur K8s comme principale frontière de sécurité

  • J’ai peut-être manqué le passage où l’article dit qu’ils s’attendaient à de fortes garanties, mais où voit-on cette attente ?
    Par exemple, dans un contexte d’exécution de code arbitraire comme l’entraînement de modèles, je ne vois pas bien quel rôle joue le multi-tenant K8s
    À mes yeux, le principal problème est qu’une fois derrière Istio, qui fait office de proxy/pare-feu, ils faisaient confiance à toutes les communications du réseau interne. Mais il se peut aussi que je ne comprenne pas suffisamment les clusters k8s
  • Une forte isolation multi-tenant au sein d’un même cluster K8s logique est, en pratique, difficile à obtenir
    C’est une cible mouvante, et vouloir rendre cela sûr avec des admission controllers n’est pas un très bon plan
    Si l’on veut envisager un fort multi-tenant face à des tenants hostiles, il faut commencer par regarder des choses comme VirtualClusters (https://github.com/kubernetes-sigs/cluster-api-provider-nest...). Et encore, cela ne concerne que le plan de contrôle, pas du tout le plan de données
    Même avec cette couche supplémentaire, je ne sais pas à quel point c’est sûr. Dans le monde des machines virtuelles aussi, il y a eu pendant des années des vulnérabilités d’évasion de VM complètement absurdes
  • Un K8S correctement configuré est littéralement conçu pour le multi-tenant
    Avoir un cluster séparé pour chaque client coûte absurdement cher et est mauvais pour la planète. Cela peut se justifier pour un produit premium où la sécurité est la priorité absolue, mais des clusters séparés par client, c’est essentiellement brûler de l’argent

• Je pense que les entreprises qui s’introduisent dans des réseaux sans autorisation pour trouver des vulnérabilités et en faire du contenu de blog devraient être poursuivies
  Cet article ressemble particulièrement à un texte offensif à peine emballé dans une divulgation de vulnérabilité. Le passage disant qu’ils « ont apprécié la coopération » sonne aussi un peu comme de l’extorsion

  • On peut reformuler cela ainsi : « les entreprises qui collectent négligemment des données utilisateur sensibles et les stockent de manière non sécurisée ne devraient pas faire l’objet d’un examen minutieux, et devraient être laissées libres de continuer à exposer les données d’utilisateurs innocents à des cybercriminels malveillants »
    Vu sous cet angle, cela paraît assez différent, non ?
  • Tenter de pirater une grande entreprise sans y avoir été invité est un crime, et normalement quelque chose qui devrait être poursuivi sérieusement
    Mais comme le dit la pratique juridique, cela dérive vers une logique du type « si vous avez des milliards de dollars, la loi ne s’applique plus vraiment »

• Quelqu’un a déjà utilisé Wiz ?
  C’est peut-être la fusée la plus rapide parmi les éditeurs de logiciels d’entreprise. 100 millions de dollars d’ARR en 1,5 an, puis 350 millions de dollars à la fin de la troisième année
  https://www.wiz.io/blog/100m-arr-in-18-months-wiz-becomes-th...

  • Je l’utilise et j’en suis très satisfait. Même en dehors de l’aspect sécurité, c’est le meilleur outil que j’aie essayé pour faire correctement de la gestion d’actifs multicloud
    Avec la fonctionnalité de graphe, on peut interroger à peu près n’importe quoi sur tous les comptes si on le souhaite
  • Google serait aussi en train de vouloir les racheter pour 23 milliards de dollars

• Je suis content d’avoir convaincu les gens de mon entreprise de faire réaliser le test d’intrusion annuel du produit en environnement de production, et d’inclure toute l’infrastructure de production dans le périmètre
  L’accent peut être mis sur un produit ou un système précis, mais tout est dans le périmètre. Le premier test est en cours et personne ne hurle encore, donc j’espère que ça va bien se passer

  • Quand tu dis annuel, est-ce que je dois comprendre qu’il n’y a pas de tests d’intrusion internes réguliers ?
    Je serais aussi curieux de savoir si tu peux recommander une boîte de pentest qui fasse vraiment le travail, au-delà d’un simple passage rapide avec Metasploit

• Si j’ai bien lu, les données de compte des clients sont exposées à ces mêmes clients ? À part certains logs, semble-t-il

  • Pas seulement certains logs : les données d’entraînement et le code d’autres clients, ainsi que le registre interne d’images Docker de SAP, étaient aussi exposés. Et avec des droits en lecture-écriture !

• En tant que chercheur en sécurité, on pourrait penser qu’ils sauraient que la pixellisation est un mauvais choix pour masquer du texte
  https://www.bleepingcomputer.com/news/security/researcher-re...

  • Tous les bugs signalés ont été corrigés, et les secrets potentiellement compromis ont probablement été remplacés
    Flouter ou pixelliser semble en fait inutile, indépendamment de l’efficacité. Les données masquées ressemblent à des noms d’hôte locaux et à des parties de hash d’images
  • À mes yeux, ce n’était pas de la pixellisation mais du floutage
    Édit : en y regardant de nouveau, il semble que certains endroits aient été floutés et d’autres pixellisés