Problème 4494

L'équipe de recherche sur les menaces Sysdig (TRT) a récemment observé une nouvelle attaque qui exploitait des identifiants cloud volés afin de cibler dix services de modèles de langage volumineux (LLM) hébergés dans le cloud, connus sous le nom de LLMjacking. Les identifiants ont été obtenus à partir d'une cible populaire, un système exécutant une version vulnérable de Laravel (CVE-2021-3129). Les attaques contre les systèmes d'intelligence artificielle (IA) basés sur LLM ont souvent été évoquées, mais principalement autour d'abus rapides et de la modification des données de formation. Dans ce cas, les attaquants ont l'intention de vendre l'accès LLM à d'autres cybercriminels pendant que le propriétaire du compte cloud paie la facture. Une fois l'accès initial obtenu, ils ont exfiltré les identifiants cloud et ont obtenu l'accès à l'environnement cloud, où ils ont tenté d'accéder à des modèles LLM locaux hébergés par des fournisseurs de cloud : dans ce cas, un modèle LLM local Claude (v2/v3) d'Anthropic a été ciblé. Si elle n'est pas découverte, ce type d'attaque pourrait entraîner des coûts de consommation de LLM de plus de 46 000 $ par jour pour la victime. Les chercheurs de Sysdig ont découvert des preuves de l'utilisation d'un proxy inverse pour les LLM afin de fournir l'accès aux comptes compromis, suggérant une motivation financière. Cependant, une autre motivation possible est d'extraire les données de formation LLM. Étendue des cibles ------------------ Nous avons pu découvrir les outils qui généraient les requêtes utilisées pour invoquer les modèles pendant l'attaque. Cela a révélé un script plus large capable de vérifier les informations d'identification de dix services d'IA différents afin de déterminer lesquels étaient utiles à leurs fins. Ces services incluent : - AI21 Labs, Anthropic, AWS Bedrock, Azure, ElevenLabs, MakerSuite, Mistral, OpenAI, OpenRouter et GCP Vertex AI Les attaquants cherchent à accéder à une grande quantité de modèles LLM dans différents services. Aucune requête LLM légitime n'a été réellement exécutée pendant la phase de vérification. Au lieu de cela, juste ce qu'il faut a été fait pour déterminer de quoi les informations d'identification étaient capables et les quotas. En outre, les paramètres de journalisation sont également interrogés lorsque cela est possible. Cela est fait pour éviter la détection lors de l'utilisation des informations d'identification compromises pour exécuter leurs invites. Contexte ---------- ### Modèles LLM hébergés Tous les principaux fournisseurs de cloud, y compris Azure Machine Learning, Vertex AI de GCP et AWS Bedrock, hébergent désormais des services de grands modèles de langage (LLM). Ces plateformes offrent aux développeurs un accès facile à divers modèles populaires utilisés dans l'IA basée sur LLM. Comme illustré dans la capture d'écran ci-dessous, l'interface utilisateur est conçue pour la simplicité, permettant aux développeurs de commencer à créer des applications rapidement. Ces modèles ne sont cependant pas activés par défaut. Au lieu de cela, une demande doit être soumise au fournisseur de cloud pour pouvoir les exécuter. Pour certains modèles, il s'agit d'une approbation automatique ; pour d'autres, comme les modèles tiers, un petit formulaire doit être rempli. Une fois la demande effectuée, le fournisseur de cloud autorise généralement l'accès assez rapidement. L'obligation de faire une demande est souvent plus un obstacle pour les attaquants qu'un obstacle, et ne doit pas être considérée comme un mécanisme de sécurité. Les fournisseurs de cloud ont simplifié le processus d'interaction avec les modèles de langage hébergés dans le cloud en utilisant des commandes CLI simples. Une fois les configurations et autorisations nécessaires en place, vous pouvez facilement interagir avec le modèle à l'aide d'une commande similaire à celle-ci : > aws bedrock-runtime invoke-model --model-id anthropic.claude-v2 --body '{"prompt": "\n\nHuman: story of two dogs\n\nAssistant:", "max_tokens_to_sample" : 300}' --cli-binary-format raw-in-base64-out invoke-model-output.txt ### Proxy inverse LLM Le code de vérification de clé qui vérifie si les informations d'identification peuvent utiliser les LLM ciblés fait également référence à un autre projet : OAI Reverse Proxy. Ce projet open source agit comme un proxy inverse pour les services LLM. L'utilisation d'un logiciel comme celui-ci permettrait à un attaquant de gérer de manière centralisée l'accès à plusieurs comptes LLM sans exposer les informations d'identification sous-jacentes, ou dans ce cas, le pool sous-jacent d'informations d'identification compromises. Lors de l'attaque utilisant les informations d'identification cloud compromises, un agent utilisateur correspondant au proxy inverse OAI a été observé en train de tenter d'utiliser des modèles LLM. L'image ci-dessus est un exemple d'un proxy inverse OAI que nous avons trouvé en cours d'exécution sur Internet. Il n'y a aucune preuve que cette instance soit liée à cette attaque de quelque manière que ce soit, mais elle montre le type d'informations qu'elle collecte et affiche. Il convient de noter en particulier le nombre de jetons (« tookens »), les coûts et les clés qui sont potentiellement enregistrés. Cet exemple montre une instance de proxy inverse OAI, qui est configurée pour utiliser plusieurs types de LLM. Rien ne prouve que cette instance soit impliquée dans l'attaque. Si les attaquants rassemblaient un inventaire d'informations d'identification utiles et souhaitaient vendre l'accès aux modèles LLM disponibles, un proxy inverse comme celui-ci pourrait leur permettre de monétiser leurs efforts. Analyse technique ------------------ Dans cette analyse technique, nous explorons comment les attaquants ont navigué dans un environnement cloud pour mener à bien leur intrusion. En utilisant des requêtes API apparemment légitimes dans l'environnement cloud, ils ont astucieusement testé les limites de leur accès sans déclencher immédiatement d'alarmes. L'exemple ci-dessous démontre une utilisation stratégique de l'appel d'API InvokeModel enregistré par CloudTrail. Bien que les attaquants aient émis une requête valide, ils ont intentionnellement défini le paramètre max_tokens_to_sample sur -1. Ce paramètre inhabituel, généralement censé déclencher une erreur, avait en fait un double objectif. Il confirmait non seulement l'existence de l'accès aux LLM, mais également que ces services étaient actifs, comme l'indique l'exception ValidationException résultante. Un résultat différent, comme une erreur AccessDenied, aurait suggéré un accès restreint. Cette enquête subtile révèle une approche calculée pour découvrir les actions autorisées par leurs informations d'identification volées au sein du compte cloud. ### InvokeModel L'appel InvokeModel est enregistré par CloudTrail et un exemple d'événement malveillant peut être vu ci-dessous. Ils ont envoyé une demande légitime mais ont spécifié que "max_tokens_to_sample" était -1. Il s'agit d'une erreur non valide qui provoque l'erreur "ValidationException", mais il s'agit d'informations utiles pour l'attaquant, car elles lui indiquent que les informations d'identification ont accès aux LLM et qu'elles ont été activées. Sinon, ils auraient reçu une erreur "AccessDenied". { "eventVersion": "1.09", "userIdentity": { "type": "IAMUser", "principalId": "[SUPPRIMÉ]", "arn": "[SUPPRIMÉ]", "accountId": "[SUPPRIMÉ]", "accessKeyId": "[SUPPRIMÉ]", "userName": "[SUPPRIMÉ]" }, "eventTime": "[SUPPRIMÉ]", "eventSource": "bedrock.amazonaws.com", "eventName": "InvokeModel", "awsRegion": "us-east-1", "sourceIPAddress": "83.7.139.184", "userAgent": "Boto3/1.29.7 md/Botocore#1.32.7 ua/2.0 os/windows#10 md/arch#amd64 lang/python#3.12.1 md/pyimpl#CPython cfg/retry-mode#legacy Botocore/1.32.7", "errorCode": "ValidationException", "errorMessage": "max_tokens_to_sample: range: 1..1,000,000", "requestParameters": { "modelId": "anthropic.claude-v2" }, "responseElements": null, "requestID": "d4dced7e-25c8-4e8e-a893-38c61e888d91", "eventID": "419e15ca-2097-4190-a233-678415ed9a4f", "readOnly": true, "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "[SUPPRIMÉ]", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_128_GCM_SHA256", "clientProvidedHostHeader": "bedrock-runtime.us-east-1.amazonaws.com" } }Langage du code : Perl (perl) Exemple de journal Cloudtrail AWS Bedrock n'est pas pris en charge dans toutes les régions, c'est pourquoi les attaquants ont appelé « InvokeModel » uniquement dans les régions prises en charge. À l'heure actuelle, Bedrock est pris en charge dans les régions us-east-1, us-west-2, ap-southeast-1, ap-northeast-1, eu-central-1, eu-west-3 et us-gov-west-1, comme indiqué ici. Différents modèles sont disponibles selon la région ; Voici la liste des modèles pris en charge par la région AWS. ### GetModelInvocationLoggingConfiguration Il est intéressant de noter que les attaquants se sont montrés intéressés par la manière dont le service était configuré. Cela peut être fait en appelant "GetModelInvocationLoggingConfiguration," qui renvoie la configuration de journalisation S3 et Cloudwatch si elle est activée. Dans notre configuration, nous avons utilisé à la fois S3 et Cloudwatch pour collecter autant de données que possible sur l'attaque. Exemple de réponse GetModelInvocationLoggingConfiguration Les informations sur les invites en cours d'exécution et leurs résultats ne sont pas stockées dans Cloudtrail. Au lieu de cela, une configuration supplémentaire doit être effectuée pour envoyer ces informations à Cloudwatch et S3. Cette vérification est effectuée pour masquer les détails de leurs activités à toute observation détaillée. OAI Reverse Proxy déclare qu'il n'utilisera aucune clé AWS dont la journalisation est activée pour des raisons de « confidentialité ». Cela rend impossible l'inspection des invites et des réponses si elles utilisent le vecteur AWS Bedrock. Impact ------ Dans une attaque de piratage LLM, les dommages se présentent sous la forme de coûts accrus pour la victime. Il ne devrait pas être surprenant d'apprendre que l'utilisation d'un LLM n'est pas bon marché et que ce coût peut s'accumuler très rapidement. Considérant le pire scénario où un attaquant abuse d'Anthropic Claude 2.x et atteint la limite de quota dans plusieurs régions, le coût pour la victime peut être supérieur à 46 000 $ par jour. Selon les tarifs et la limite de quota initiale pour Claude 2 : - 1 000 jetons d'entrée coûtent 0,008 $, 1 000 jetons de sortie coûtent 0,024 $. - Un maximum de 500 000 jetons d'entrée et de sortie peuvent être traités par minute selon AWS Bedrock. Nous pouvons considérer le coût moyen entre les jetons d'entrée et de sortie, qui est de 0,016 $ pour 1 000 jetons. Conduisant au coût total : (500 000 jetons/1 000 * 0,016 $) * 60 minutes * 24 heures * 4 régions = 46 080 $/jour En maximisant les limites de quota, les attaquants peuvent également empêcher l'organisation compromise d'utiliser des modèles de manière légitime, perturbant ainsi les opérations commerciales. Détection --------- La capacité à détecter et à réagir rapidement aux menaces potentielles peut faire toute la différence dans le maintien d'une défense robuste. En nous appuyant sur les commentaires récents et les meilleures pratiques du secteur, nous avons distillé des stratégies clés pour améliorer vos capacités de détection : - Détections de journaux cloud : des outils comme Falco, Sysdig Secure et CloudWatch Alerts sont des alliés indispensables. Les organisations peuvent identifier de manière proactive les comportements suspects en surveillant l'activité d'exécution et en analysant les journaux cloud, y compris les tactiques de reconnaissance telles que celles employées dans AWS Bedrock. - Journalisation détaillée : la journalisation complète, y compris la journalisation détaillée, offre une visibilité inestimable sur le fonctionnement interne de votre environnement cloud. Les informations détaillées sur les invocations de modèles et d'autres activités critiques donnent aux organisations une compréhension nuancée de l'activité dans leurs environnements cloud. ### Détections de journaux cloud La surveillance des journaux cloud peut révéler une activité suspecte ou non autorisée. À l'aide de Falco ou de Sysdig Secure, les méthodes de reconnaissance utilisées pendant l'attaque peuvent être détectées et une réponse peut être lancée. Pour les clients Sysdig Secure, cette règle se trouve dans la politique Sysdig AWS Notable Events. Règle Falco : - règle : Activité de reconnaissance de modèle Bedrock desc : Détecter les tentatives de reconnaissance pour vérifier si Amazon Bedrock est activé, en fonction du code d'erreur. Les attaquants peuvent exploiter cela pour découvrir l'état de Bedrock, puis en abuser s'il est activé. En outre, les alertes CloudWatch peuvent être configurées pour gérer les comportements suspects. Plusieurs [métriques d'exécution](https://docs.aws.amazon.com/bedrock/latest/userguide/monitoring-cw.html) pour Bedrock peuvent être surveillées pour déclencher des alertes. ### Journalisation détaillée La surveillance de l'utilisation des services de modèle de langage (LLM) de votre organisation est essentielle, et divers fournisseurs de cloud fournissent des installations pour rationaliser ce processus. Cela implique généralement la configuration de mécanismes pour enregistrer et stocker des données sur les invocations de modèle. Pour AWS Bedrock en particulier, les utilisateurs peuvent tirer parti de CloudWatch et de S3 pour des capacités de surveillance améliorées. CloudWatch peut être configuré en créant un groupe de journaux et en attribuant un rôle avec les autorisations nécessaires. De même, pour se connecter à S3, un bucket désigné est requis comme destination. Il est important de noter que le journal CloudTrail de la commande InvokeModel ne capture pas les détails sur l'entrée et la sortie de l'invite. Cependant, les paramètres Bedrock permettent une activation facile de la journalisation des invocations de modèle. De plus, pour les données d'entrée ou de sortie de modèle supérieures à 100 Ko ou au format binaire, les utilisateurs doivent spécifier explicitement une destination S3 pour gérer la livraison de données volumineuses. Cela inclut les images d'entrée et de sortie, qui sont stockées dans les journaux sous forme de chaînes Base64. Ces mécanismes de journalisation complets garantissent que tous les aspects de l'utilisation du modèle sont surveillés et archivés pour une analyse et une conformité ultérieures. Les journaux contiennent des informations supplémentaires sur les jetons traités, comme indiqué dans l'exemple suivant : { "schemaType": "ModelInvocationLog", "schemaVersion": "1.0", "timestamp": "[REDACTED]", "accountId": "[REDACTED]", "identity": { "arn": "[REDACTED]" }, "region": "us-east-1", "requestId": "bea9d003-f7df-4558-8823-367349de75f2", "operation": "InvokeModel", "modelId": "anthropic.claude-v2", "input": { "inputContentType": "application/json", "inputBodyJson": { "prompt": "\n\nHumain : Écrivez l'histoire d'un jeune sorcier\n\nAssistant :", "max_tokens_to_sample": 300 }, "inputTokenCount": 16 }, "output": { "outputContentType": "application/json", "outputBodyJson": { "completion": " Voici l'histoire d'un jeune sorcier :\n\nMartin était un garçon ordinaire vivant dans un petit village. Il aidait ses parents dans leur modeste ferme, s'occupant des animaux et travaillant dans les champs. [...] La matière préférée de Martin était la métamorphose, l'art de transformer des objets d'une chose en une autre. Il maîtrisa rapidement le sujet, étonnant ses professeurs en transformant des souris en gobelets et des pierres en oiseaux flottants.\n\nMartin", "stop_reason": "max_tokens", "stop": null }, "outputTokenCount": 300 } }`Langage de code : Perl (perl) Exemple de journal S3 Recommandations --------------- Cette attaque aurait pu être évitée de plusieurs manières, notamment : - Gestion des vulnérabilités pour empêcher l'accès initial. - Gestion des secrets pour garantir que les informations d'identification ne sont pas stockées en clair où elles peuvent être volées. - CSPM/CIEM pour s'assurer que le compte abusé dispose du minimum d'autorisations nécessaires. Comme le soulignent des recherches récentes, les fournisseurs de cloud proposent une gamme d'outils et de bonnes pratiques conçus pour atténuer les risques d'attaques cloud. Ces outils aident les organisations à créer et à maintenir un environnement cloud sécurisé dès le départ. Par exemple, AWS fournit plusieurs mesures de sécurité robustes. L'architecture de référence de sécurité AWS décrit les meilleures pratiques pour construire votre environnement cloud en toute sécurité. En outre, AWS recommande d'utiliser des politiques de contrôle des services (SCP) pour gérer de manière centralisée les autorisations, ce qui permet de minimiser le risque associé aux comptes sur-autorisés qui pourraient potentiellement être utilisés à mauvais escient. Ces directives et outils font partie de l'engagement d'AWS à améliorer la sécurité et à fournir aux clients les ressources nécessaires pour protéger efficacement leur infrastructure cloud. D'autres fournisseurs de cloud proposent des cadres et des outils similaires, garantissant aux utilisateurs l'accès aux mesures de sécurité essentielles pour protéger leurs données et leurs services, quelle que soit la plateforme. Conclusion ---------- Les informations d'identification cloud et SaaS volées continuent d'être un vecteur d'attaque courant. Cette tendance ne fera qu'augmenter en popularité à mesure que les attaquants apprendront toutes les façons dont ils peuvent tirer parti de leur nouvel accès pour obtenir un gain financier. L'utilisation des services LLM peut être coûteuse, selon le modèle et la quantité de jetons qui lui sont fournis. Normalement, cela inciterait un développeur à essayer d'être efficace --- malheureusement, les attaquants n'ont pas la même motivation. La détection et la réponse sont essentielles pour traiter rapidement tout problème. ### Adresses IP des IoC 83.7.139.184 83.7.157.76 73.105.135.22883.7.135.97