CosmosEscape : l'explosion qui transforme un bac à sable Gremlin en un accès complet au multitenu Cosmos DB

A L'équipe de recherche de Wiz a découvert et signalé une chaîne d'exploitation à Azure Cosmos DB, qui, selon son rapport public, a permis de s'échapper du bac à sable du moteur Gremlin et de monter pour obtenir l'accès à la lecture et à l'écriture sur des comptes à plusieurs locataires Cosmos DB. Vulnérabilité - co-appelé Cosmos Échapper par les chercheurs - combiné une injection dans les consultations de Gremlin avec la capacité d'invoquer . Réflexions NET dans le moteur personnalisé, qui a facilité la lecture / l'écriture de fichiers primitifs et, enfin, l'exécution de code dans une composante multi-tenu du service.

Selon la réponse publique de Wiz et de Microsoft, le vecteur initial prouvé était basé sur une base de données Gremlin contrôlée par l'attaquant et les identifiants de ce compte; de là l'exécution est passée au composant que Wiz appelle DB Gateway, qui fonctionne dans les clusters partagés de Service Fabric. Cette composante avait accès à une clé de signature de plate-forme qui permettait de récupérer les clés de comptes primaires de Cosmos DB dans différentes régions, API (SQL, MongolDB, Cassandra et Gremlin) et les niveaux de locataires, et il y avait aussi un entrepôt régional (Config Store) avec des métadonnées et la cartographie de compte / locataire qui faciliterait le ciblage.

Microsoft a bloqué le point d'entrée vulnérable en moins de 48 heures depuis le rapport reçu en novembre 2025 et a achevé un arrangement plus large en juillet 2025, y compris la suppression de la clé de signature de la plate-forme comme indiqué. Microsoft prétend ne pas avoir détecté d'activité non autorisée en dehors des tests des chercheurs et qu'il n'était pas nécessaire que les clients prennent des mesures Bien que l'entreprise n'ait pas encore publié de CVE ou de période d'exposition complète, la fenêtre de risque historique n'est pas entièrement clarifiée dans la documentation publique.

Les implications techniques de cette constatation sont pertinentes pour tout architecte ou responsable de la sécurité du cloud: une fuite d'un bac à sable d'exécution vers un composant de passerelle multi-tenu peut convertir des références apparemment limitées en un accès complet aux ressources s'il existe des secrets à portée globale au sein de la plateforme. Cela souligne l'importance cruciale de la séparation des privilèges entre les données et le contrôle, ainsi que d'éviter les secrets à portée massive au sein des services partagés.

Pour les équipes de sécurité et les gestionnaires de Cosmos DB, les mesures immédiates prudentes comprennent la demande d'un rapport détaillé de la portée et de la période révisées couvertes par son examen du journal, la confirmation de l'inscription de son(s) compte(s) dans le Config Store et la demande de rotation clé en cas de risque indirect. En outre, il convient d'activer et d'examiner les registres de diagnostic, de conserver suffisamment de preuves pour les chasses médico-légales et d'appliquer la rotation principale des clés/régences en cas de moindre doute. Il est également recommandé de valider les isolations de réseau (Private Link, VNET) et l'existence de mesures de contrôle supplémentaires telles que l'utilisation d'identités et de clés gérées par les clients (CMK).

En termes d'atténuation à long terme, les fournisseurs et les clients devraient prioriser les mécanismes qui réduisent le rayon d'explosion de tout secret engagé : séparer les composants qui traitent les consultations des clients, supprimer les références mondiales, appliquer un principe moins privilégié dans chaque service et les changements d'infrastructure sujets aux examens de sécurité et aux tests de pénétration qui incluent des scénarios d'évasion de bac à sable et des abus de réflexion dans des environnements gérés. La capacité de défense et de détection précoce en profondeur sont les meilleures garanties contre les défaillances de conception dans les services multilocataires.

Wiz a annoncé qu'il présentera la chaîne complète à Black Hat USA, qui permettra techniquement de revoir les conditions exactes de l'explosion, sa robustesse et ses limites. Pour connaître ces détails, il est raisonnable de supposer des incertitudes sur les exigences initiales et l'extensibilité de l'attaque, de sorte que des mesures d'atténuation prudentes et des pressions pour obtenir une panne officielle restent recommandées. Les ressources publiques de la documentation de Wiz et de Microsoft sur Cosmos DB sont disponibles pour la divulgation officielle et la chronologie: Wiz et Azure Cosmos DB (Microsoft Learn). La présentation de la conférence sera également disponible sur les chaînes Black Hat: Chapeau noir.

Enfin, pour l'équipement de gestion des risques et de conformité, il est important de demander à Microsoft de confirmer par écrit la portée de l'examen du registre, de demander des indicateurs d'engagement liés à la chaîne signalée et d'exiger une notification immédiate de toute conclusion rétroactive. L'absence d'exposition vérifiable aujourd'hui ne remplace pas une réponse proactive: les secrets tournants, le resserrement de l'accès et l'amélioration de la surveillance sont des étapes qui réduisent le risque de vulnérabilité future de la plateforme.