Défendeur adjoint dans Azure Backup et AKS expose les organisations non-CVE

Un chercheur en sécurité affirme que Microsoft a résolu silencieusement une vulnérabilité critique dans Azure Backup for AKS après avoir rejeté son rapport et bloqué l'émission d'un CVE, laissant les organisations sans une façon claire de mesurer leur exposition. Selon le chercheur, l'échec a permis d'alléger les privilèges du rôle de « contributeur de secours » de faible confiance aux permissions de cluster-admin dans Kubernetes, en exploitant la façon dont Azure met en place des relations Trusted Access pour les sauvegardes.

La technique décrite correspond à ce que la communauté connaît comme un type d'attaque Députée en conflit lorsque l'interaction entre Azure RBAC et Kubernetes RBAC brise les barrières d'autorisation attendues et permet une identité avec des permis limités pour activer l'élévation. Le rapport technique du chercheur explique comment activer le support de sauvegarde dans un cluster cible contraint Azure à créer des liens de confiance avec les privilèges d'administrateur dans Kubernetes, opérations qui pourraient être utilisées pour extraire des secrets ou restaurer des charges malveillantes dans le cluster; voir l'explication originale ici: olearysec.com.

La chronologie qui facilite le cas montre des tensions régulières dans les processus de divulgation responsable: la découverte initiale et l'expédition ont eu lieu en mars, Microsoft Security Response Center (MSRC) a rejeté la notation comme vulnérabilité au motif que l'attaque exigeait un accès administratif préalable, et la discussion a augmenté CERT / CC, qui a validé la défaillance et a attribué un identifiant (VU # 284781). Microsoft a ensuite demandé à MITRE de ne pas se voir attribuer un CVE, et l'application des règles de hiérarchie des CNA a laissé à Microsoft le pouvoir final de délivrer le CVE ou non; les règles CNA sont disponibles à l'adresse suivante: Cve.org. L'épisode a été rapporté publiquement par des médias spécialisés couvrant le différend et la correction apparente: Calculateur.

La chose la plus inquiétante pour les défenseurs est que, suite à la divulgation, le chercheur a observé des changements opérationnels qui ont empêché la reproduction de l'explosion originale: des étapes manuelles sont maintenant nécessaires pour configurer Trusted Access et des vérifications supplémentaires des autorisations apparaissent sur les identités gérées par le coffre et le cluster, ce qui suggère une correction appliquée du côté du fournisseur sans préavis officiel. Microsoft affirme qu'aucune « modification de produit » n'a été apportée parce que le comportement antérieur, tel qu'évalué, était attendu; le chercheur et le CERT/CC n'étaient pas d'accord avec cette interprétation.

Cette affaire a plusieurs implications pratiques et sécuritaires pour le gouvernement. Sans CVE ni avis public l'équipement de sécurité ne peut quantifier le nombre de ressources exposées, le guichet temporaire des risques ou l'ordre de priorité des mesures correctives fondées sur un inventaire touché. De plus, les corrections silencieuses rendent difficile la validation indépendante de l'atténuation et la réduction de la traçabilité juridique et opérationnelle dans les environnements réglementés. Le différend révèle également des frictions dans le triage des rapports, y compris la mention controversée du contenu "généré par l'AI" comme un facteur qui détourne de l'analyse technique.

Pour les équipes de sécurité qui gèrent AKS et Azure Backup, je recommande d'agir immédiatement : audit et liste de toutes les attributions du rôle contributeur de sauvegarde dans tous les coffres et abonnements, confirmez si une identité gérée (MSI) a des permis inattendus sur les groupes ou groupes de ressources de snapshots, et vérifiez la configuration Trusted Access dans les groupes AKS. Activer et examiner les journaux de contrôle d'accès, les liaisons RBAC changent les alertes et les opérations habilitantes de sauvegarde, et envisager des secrets / lettres d'identité tournantes qui auraient pu être compromises. Mettre en œuvre des politiques moins privilégiées et des restrictions administratives sur ceux qui peuvent activer les sauvegardes et gérer les identités de voûte, et utiliser Azure Policy et Azure Monitor pour automatiser la détection et le blocage des modifications non autorisées.

En outre, documenter et consigner toute interaction avec le fournisseur : demander la confirmation écrite des changements appliqués, des calendriers et de la portée de l'atténuation, et exiger des conseils techniques ou un CVE pour suivre l'exposition dans les outils de gestion de la vulnérabilité. Si vous gérez des environnements ayant des exigences de conformité, incluez cet examen dans les prochains processus de contrôle d'accès et de gestion des risques.

L'épisode met en évidence un besoin plus large : les programmes de sensibilisation et les hiérarchies des ACN doivent équilibrer la protection des écosystèmes et la transparence envers les clients. Tant qu'il n'y aura pas de mécanisme permettant d'harmoniser les mesures d'incitation pour signaler les corrections et de délivrer des CVE de manière impartiale, le cas échéant, les organisations et les défenseurs continueront de faire face à un Fenêtre de visibilité insuffisante qui complique l'atténuation efficace des risques liés aux nuages.