Nous lions à certaines catégories et entreprises dans ce blog, mais ce billet n'est pas sponsorisé d'aucune façon.

Des visages qui se bousculent calendrier technique de leur infrastructure se faire pirater par l'agent OpenAI-S est une lecture fascinante. En résumé, un agent OpenAI a utilisé une nouvelle découverte de vulnérabilité combinée à de nombreuses petites erreurs de configuration pour pivoter d'un coureur de la série "Sandboxed" dans une grande partie de l'infrastructure de production Hugging Faces - GitHub, Kubernetes, MongoDB, etc. L'agent a lancé cette attaque à partir d'un pipeline OpenAI sans garde-corps, déplacé dans une boîte publique qu'il pouvait contrôler, puis attaqué Hugging Face afin d'essayer de trouver des réponses à une évaluation.

D'une part, Hugging Face souligne à juste titre qu'il n'y avait pas ici de nouveau vecteur d'attaque d'IA magique ; cependant, il y a une sophistication croissante et la vitesse des attaques d'IA a permis - lancer près de 17 600 actions différentes dans les quatre jours. Ces attaques avancées sont possibles sans AI, mais l'IA les rend beaucoup plus réalisables et plus rapides que l'attaquant moyen.

Plutôt que de pontificer sur les Attaques à l'ère de l'IA, ce chapitre est destiné à être un guide pour prévenir cette attaque spécifique, et quels outils pourraient même aider. C'est particulièrement important de faire comme beaucoup de fournisseurs sont des messages qu'ils sont une solution de sécurité d'argent. Malheureusement, la majorité des entreprises sont incitées à prioriser les mauvaises choses : un EDR avec un SIEM et des journaux Windows ne le détecteront pas. Au lieu de cela, une combinaison de technologies souvent négligées sont nécessaires: Kubernetes runtime et la gestion de la posture, IC/CD monitoring, NHI monitoring and runtime controls, et l'isolement avancé.

Première étape, l'agent atteint un launchpad

Les détails exacts de l'accès initial de l'agent à Internet sont omis de l'écriture d'OpenAI, mais semble avoir été principalement entraîné par l'exploitation d'un registre de paquets Artifactory proxié. À mon avis, les pare-feu de chaîne d'approvisionnement, sous la forme de répertoires de paquets mandataires, ne font pas vraiment grand-chose - si un mandataire est utilisé ou non, nous parlons de télécharger ou d'accéder à des paquets depuis Internet avec une étape intermédiaire. Typiquement, cette étape intermédiaire n'est que retarder la construction de paquets, souvent même pas faire des logiciels malveillants scanner eux-mêmes pour les paquets malveillants. Celui-ci a apparemment été abusé pour obtenir un accès Internet plus large.

À un niveau élevé, l'agent a finalement pu accéder au calcul sur Internet depuis l'intérieur d'un pod. C'est là qu'il n'y a vraiment que trois options pour les défenseurs qui essaient d'empêcher un agent voyou comme ceci:

1. Bloquer le trafic d'évacuation de vos environnements; cependant, normalement il est impossible de faire un bloc entier, en choisissant plutôt de limiter l'accès à des domaines spécifiques. C'est ici que le jour zéro exploiter contre le proxy crée un point mort contre ce qui autrement est une architecture assez serrée. De plus, l'agent a épinglé DNS et utilisé d'autres méthodes pour contourner les contrôles d'évacuation Hugging Face avait mis en place plus tard dans l'attaque - augmentant l'importance de la surveillance des temps d'exécution du trafic réseau.

2. En raison de sa capacité à découvrir de nouveaux exploits, les équipes de sécurité doivent adopter une posture d'hypothèse de rupture, c'est-à-dire de surveillance en profondeur et d'isolement de tous les aspects de leur charge de travail (oui, c'est vraiment difficile à faire). Préventionnellement, cela signifie une forte isolation des compétences et du réseau; réceptif, cela signifie l'enregistrement et l'alerte sur des détails vraiment difficiles comme les journaux de coureur et Kubernetes. Du point de vue de l'outillage, l'émergence sécurité préventive et CADR les catégories y contribuent, en plus des capacités de sécurité de Kubernetes longtemps négligées des CNAPP.

3. Solutions avancées de sécurité d'exécution pour surveiller l'activité de tout agent d'origine, à la recherche de déviations d'intention ou autrement. Ces technologies sont encore généralement nouvelles et peuvent être incohérentes dans leur efficacité. Nous aurons plus de détails à ce sujet dans notre prochain rapport sur la sécurité de l'IA, mais beaucoup des sécurité émergente de l'agent final Les fournisseurs de services développent cette approche.

Empêcher quelque chose de quitter vos environnements de construction est un défi monumental, car de nombreuses équipes de sécurité manquent de contrôles d'évacuation sur leurs charges de travail en nuage entièrement. Cette attaque est préoccupante parce qu'elle a montré que l'agent contournait même les contrôles d'évacuation qui étaient en place. À long terme, ces nouvelles solutions de sécurité d'agents axées sur le temps d'exécution seront la solution pour les entreprises qui construisent, testent et lancent leurs propres agents.

Deuxième étape, l'agent Breaches s'empare du visage

Une fois que l'agent avait accès à Internet, il a essayé d'exploiter Hugging Face. Il a téléchargé des ensembles de données malveillantes afin d'exécuter le code sur les pods internes, avant de pivoter dans Kubernetes via IMDS, avant de pivoter plus profondément dans les systèmes Hugging Face. Tout d'abord, il est intéressant de noter que l'infrastructure Hugging Faces pose des défis exceptionnellement avancés - à bien des égards ils offrent l'exécution à distance comme un service. Deuxièmement, il est louable qu'ils aient eu suffisamment de télémétrie d'exécution de leurs systèmes pour reconstruire toute l'attaque, et que leurs systèmes de détection ont tiré, tout simplement pas à une gravité assez élevée.

Une fois que l'agent a pu exécuter des commandes, il a profité de deux vecteurs d'attaque courants pour ces types de systèmes : l'injection de gabarit et la lecture de stockage local pour des secrets. Voici extrêmement des attaques difficiles à arrêter.

1. Bloquer des attaques d'injection complexes nécessite des capacités d'application avancées, des choses ADR aide avec. Cependant, souvent, les bibliothèques fournissent aussi l'injection comme un service, permettant aux équipes d'exécuter le code de manière formatée. À la fin de la journée, il s'agissait d'une exploitation de couches d'application contre Hugging Face, le type qui ne deviendra plus commun que lorsque les capacités d'IA augmenteront.

2. La plupart des équipes chargent des secrets dans la mémoire de processus ou les disques éphémères, où ils peuvent être consultés par les applications. La meilleure pratique, bien que rarement mise en œuvre, est d'accéder à ces secrets seulement au besoin, puis de les rejeter au niveau de l'application ou du réseau. Par exemple, les outils Sécurité et Atteinte avoir la possibilité d'injecter des identifiants dans le cadre des requêtes réseau proxiées. Pas une solution infaillible, mais une capacité de sécurité avancée pour gérer les lettres d'identité.

Cette partie de l'attaque est la plus difficile à arrêter - lire les secrets en premier lieu. C'est là que la connaissance et la surveillance des NHI et de la télémétrie d'exécution sont essentielles.

Troisième étape, L'agent atteint le mouvement latéral

Une fois ces secrets lus, l'agent utilise une méthode plus éprouvée et plus vraie de mouvement latéral : lancer des pods privilégiés, accéder aux nœuds et lire des secrets de cluster. C'est l'étape où les lacunes dans l'infrastructure de Hugging Faces où plus de contrôles, comme l'utilisation d'un contrôleur d'admissions pour ne pas permettre de nouveaux pods privilégiés, sont fréquemment déployées. Les plus CNAPP vendeurs, et en particulier ceux avec Kubernetes expertise, ont une conclusion pour cette erreur de configuration.

L'Agent a ensuite utilisé des identifiants grattés pour rejoindre le réseau interne et accéder aux identifiants system:masters via un courtier d'accès. De là, l'agent a continué à pivoter, obtenant l'accès aux références GitHub sensibles. Une fois que l'agent avait les identifiants GitHub, l'attaque pourrait avoir très mal tourné si l'agent avait une intention plus malveillante - Hugging Face n'a pas détecté d'écrits malveillants à ses bases de code ou images.

L'agent a ensuite continué à essayer de pivoter vers d'autres avions de contrôle pour accéder aux données avant que l'équipe de sécurité Hugging Face ne coupe l'accès. Voici un résumé rapide des contrôles utiles Hugging Face utilisé, et aurait pu utiliser, dont beaucoup sont devenus le point de mire de l'émergence outils de sécurité en nuage préventifs:

1. Par cluster scoped identities plutôt que global system:masters

2. Blocage IMDS au niveau de la goupille

3. RBAC cadrage des comptes de services Kubernetes

4. Lien privé avec IP allowlist sur les magasins de données

5. Rôles de base de données les moins privilégiés pour les pods

6. Des identifiants d'accès VPN de courte durée et des ACL plus serrés

7. Limites des données pour empêcher toute inspection non autorisée à l'extérieur des zones approuvées

Conclusion

Cet incident mérite d'être pris en considération parce qu'il touche deux réalités en évolution rapide pour les équipes de sécurité :

1. Les attaques activées par l'IA sont capables de découvrir de nouvelles faiblesses et d'exploiter celles qui existent à des vitesses incroyables. Même en générant beaucoup de bruit dans le processus, ce genre d'attaque aurait été considéré comme un grade d'État-nation pour la plupart des organisations avant AI, mais il devient ouvert à tout le monde.

2. Les outils de sécurité existants étaient suffisamment efficaces pour contrer la plupart des étapes de cette attaque - de la détection à la prévention. Mais nous sommes à un moment où beaucoup d'entreprises pivotent et hiérarchisent la sécurité d'argent ; pendant ce temps, la plupart de ces solutions font peu pour aider à résoudre les problèmes d'infrastructure, au lieu de se concentrer sur la surveillance des agents internes pour un comportement involontaire.

Les attaques d'IA nécessitent une nouvelle norme pour les équipes de sécurité qui sécurisent leurs environnements cloud et runtime, où la complexité des attaques devient plus réalisable. Cela nécessite plus de télémétrie opérationnelle, une détection et une intervention plus rapides des incidents et une meilleure opérationnalisation des résultats de prévention. Bref, prenez la sécurité de Kubernetes au sérieux - à la fois préventive et d'exécution!