Le rapport sur la chaîne d'attaque du 23 octobre de LiteLLM place l'autorité détenue au sein d'une plateforme d'agents au centre de la compromission de sa mise en production du 21 octobre. LiteLLM indique qu'une clé maître de la plateforme, exposée publiquement, n'a pas été révoquée, et qu'un attaquant a ensuite utilisé la plateforme pour obtenir le jeton du propriétaire d'une organisation GitHub. Pour les équipes de plateforme IA et d'ingénierie des releases, la question pratique est de savoir quels pouvoirs de production un service d'agents expérimental peut atteindre.
Selon LiteLLM, la plateforme permettait à des agents cloud de soumettre des pull requests. Le jeton stocké appartenait à un propriétaire d'organisation et non à un compte de service à portée limitée. L'attaquant a obtenu des identifiants supplémentaires de mainteneur et a utilisé des identités compromises pour modifier et approuver la mise en production malveillante. Il s'agit des conclusions de l'enquête du mainteneur, et non d'une détermination indépendante de Maetra.
L'analyse distincte de l'artefact par Microsoft corrobore des mécanismes de démarrage Python malveillants dans LiteLLM 1.107.0. Microsoft indique que le lancement de Python dans un environnement affecté pouvait activer la charge utile sans importer LiteLLM. Microsoft n'a toutefois pas établi de manière indépendante la voie d'accès initiale en amont.
Utilisez la version corrigée pour la cause racine
LiteLLM identifie explicitement son rapport sur la chaîne d'attaque comme la version faisant autorité lorsque des mises à jour antérieures divergent. Les équipes devraient préserver cette distinction dans les notes d'incident. Une hypothèse initiale peut constituer un historique utile, mais elle ne devrait pas rester la cause racine énoncée après correction par la source.
Cela importe lors de l'attribution des mesures de remédiation. Une équipe qui n'examinerait que la passerelle d’inférence pourrait passer à côté d'un service d'orchestration d'agents ayant accès à des identifiants de dépôt. L'incident ne constitue pas non plus une preuve qu'un modèle a choisi de façon autonome de compromettre la mise en production. La version publiée décrit un acteur malveillant utilisant une infrastructure et des identifiants exposés.
Les recommandations ci-dessous sont l'analyse de Maetra sur la conception des contrôles et la collecte de preuves. Elles doivent être appliquées à la propre exposition de l'équipe, en s'appuyant sur les consignes actuelles du fournisseur pour l'incident afin d'obtenir les détails de reprise propres aux artefacts.
Cartographiez l'autorité à partir du service d'agent vers l'extérieur
Commencez par l'identité d'exécution de chaque service d'agent et énumérez ce que cette identité peut lire. Incluez les secrets montés, les variables d'environnement, les magasins d'identifiants, la configuration CI et les jetons accessibles via les API connectées. Cartographiez ensuite ce que ces identifiants autorisent dans leurs systèmes de destination.
Des identifiants présentés comme une simple commodité de développement peuvent porter des droits d'administration de dépôt ou une autorité de mise en production. Les enregistrements d'inventaire devraient donc saisir les privilèges et les destinations, pas seulement les noms des secrets. Documentez le propriétaire, l'usage prévu, l'échéance ou le dispositif de rotation, et indiquez si une identité à moindre privilège pourrait exécuter la même tâche.
Utilisez la liste de contrôle d'inventaire des agents de Maetra pour relier un service à ses capacités. Le résultat utile est un chemin traçable reliant une charge de travail d'agent à des autorisations à fort impact, y compris des autorisations qui n'ont jamais été prévues pour cette charge.
Vérifiez si les identités d'approbation sont indépendantes
Deux approbations enregistrées offrent une protection limitée si un même environnement compromis peut obtenir les deux identifiants. Examinez la séparation technique qui sous-tend le processus d'approbation : où s'exécutent les identités, quels secrets elles peuvent récupérer, qui peut modifier le workflow et qui peut contourner les restrictions.
Pour un agent de release hypothétique, préparer une pull request et publier un artefact de production correspondent à des autorités différentes. Séparez ces autorisations lorsque le workflow le permet. Vérifiez si l'identité de préparation peut modifier la source de la release, changer les paramètres d'application des règles ou obtenir les identifiants de l'identité de publication.
Conservez les preuves du commit et de l'artefact approuvés. Un événement d'approbation visible ne suffit pas lorsque la source en cours de construction peut changer en dehors du lien qui l'attache à cet événement. Toute extension exceptionnelle de permissions devrait avoir un propriétaire, une échéance et une vérification attestant du rétablissement de la limite précédente.
Récupérez à partir de l'environnement affecté, pas seulement de l'étiquette de version
Microsoft conseille d'examiner les environnements suspects avec des outils de confiance depuis un système propre et d'éviter Python ou pip à l'intérieur de l'environnement affecté pendant la collecte de preuves. Son analyse explique pourquoi le simple fait de supprimer les fichiers applicatifs de LiteLLM peut laisser des composants de démarrage ailleurs dans l'environnement.
Pour coordonner la réponse, identifiez les postes de travail, agents de build et conteneurs affectés, ainsi que les hôtes de passerelle. Notez quelles identités et quels identifiants étaient accessibles, lesquels ont été révoqués ou renouvelés, et quelles sessions nécessitent une invalidation distincte. Ne considérez pas la seule présence du paquet comme une preuve que chaque secret visé a effectivement été volé.
Gardez visible l'exposition incertaine. L'absence de journal ou de marqueur n'établit pas automatiquement qu'aucune exécution n'a eu lieu. De même, une capacité malveillante dans le code récupéré ne prouve pas que chaque action possible de second niveau s'est produite. Le dossier de réponse devrait distinguer les observations confirmées, les évaluations d'exposition étayées et les questions non résolues.
Testez le chemin de révocation avant de clore l'incident
La clé de plateforme non révoquée dans la version de LiteLLM est une raison de vérifier la révocation comme un résultat observable. Supprimer un commit public et consigner une tâche de rotation ne prouve pas que l'ancien identifiant a cessé de fonctionner.
Depuis un environnement propre et autorisé, vérifiez que l'accès retiré est refusé et que les identités de remplacement disposent des autorisations prévues. Conservez le résultat sans faire figurer de valeurs d'identifiants dans le rapport d'incident. Attribuez la responsabilité de vérifier la configuration en cache, l'automatisation et le comportement de redémarrage des services.
Pour les équipes qui cartographient l'infrastructure d'agents, l'étape suivante consiste à suivre les identifiants accessibles depuis une charge de travail jusqu'à l'autorité de mise en production ou de production. La documentation technique de Maetra décrit des contrôles d'inventaire et de sécurité qui peuvent soutenir cette évaluation. La reprise opérationnelle dépend toujours de modifications vérifiées dans les systèmes affectés.