Forscher meldet „Confused Deputy“-Lücken in Google Cloud und Microsoft Azure

O’Leary wertet die beiden Funde nicht als isolierte Einzelfehler, sondern als Hinweis auf grundlegende Schwächen moderner Cloud-Architekturen. In einer angekündigten Black-Hat-USA-Session mit dem Titel „Trust No Deputy: Breaking Azure and GCP Through Managed Identity Chains“ will er darlegen, wie sich das Problem, das unter CWE-114 in Mitres Common Weakness Enumeration geführt wird, in heutigen Cloud-Umgebungen verbreitet hat. Gegenüber Dark Reading sagte er, solche Fehler hielten sich unter anderem deshalb so hartnäckig, weil große Cloud-Infrastrukturen oft nach Schablonen aufgebaut würden.

Die erste von O’Leary gemeldete Schwachstelle betrifft den Backup-Dienst von Microsofts Azure Kubernetes Service (AKS). Der Dienst verwendet laut Bericht die Funktion Trusted Access, um dem Backup-Tresor über spezifisch vergebene Berechtigungen Zugriff auf den AKS-Cluster zu geben. O’Leary zufolge lässt sich hier ein „Confused Deputy“-Fehler ausnutzen, um die Rechte eines Kontos mit der Rolle Backup Contributor, das eigentlich keinerlei Kubernetes-Berechtigungen besitzt, bis auf Cluster-Admin-Niveau im AKS auszuweiten.

Damit könne ein Angreifer sensible Daten aus Backups abziehen oder bösartige Workloads in beliebigen Clustern des Netzwerks bereitstellen. O’Leary meldete diese Schwachstelle am 12. Mai. Nach seiner Kommunikation mit Microsoft und CERT/CC stellte er später fest, dass Microsoft den Angriffsweg offenbar per stillschweigendem Patch geschlossen hatte. Gegenüber Dark Reading bezeichnete er einen stillen Patch als Eingeständnis und kritisierte, dass solche Vorgehensweisen zwar Anbieter schützten, es Kunden aber erschwerten, eigene Gefährdungen und Bedrohungen nachzuvollziehen.

Die zweite Schwachstelle legte O’Leary am 18. Juni offen. Sie betrifft laut seiner Forschung einen IAM-Bypass in GCP über Config Connector, ein Open-Source-Add-on, mit dem sich Google-Cloud-Ressourcen über Kubernetes verwalten lassen. O’Leary zufolge führt Config Connector keine Autorisierungsprüfung durch, um die Identität des Nutzers mit Googles IAM abzugleichen, und umgeht damit die Zugriffskontrollen der Plattform.

In einem Blogbeitrag schrieb O’Leary, Config Connector müsse prüfen, ob ein Kubernetes-Nutzer überhaupt berechtigt sei, IAM-Rollen für eine externe Organisation zu vergeben, wenn er ein IAMPolicyMember mit Verweis auf eine solche Organisation einreiche. Genau das geschehe aber nicht: Stattdessen werde die vom Nutzer gelieferte Organisations-ID mit den eigenen erhöhten Berechtigungen des Dienstes direkt an die GCP-API weitergereicht. Das Ergebnis: Ein Angreifer mit einfachem Zugriff auf einen Kubernetes-Namespace und ohne GCP-Berechtigungen könne sich rasch als GCP Organization Owner mit voller administrativer Kontrolle etablieren.

Hinzu kommt laut O’Leary, dass die Aktionen des Angreifers in den Protokollen als Aktivität eines Service-Kontos erscheinen. Dadurch werde der eigentliche Angreifer in den Cloud-Audit-Logs faktisch unsichtbar. Google habe zunächst positiv reagiert, sagte O’Leary, und er sei zunächst für eine Prämie aus dem Vulnerability Rewards Program vorgesehen gewesen. Später entschied ein VRP-Gremium jedoch, dass es sich nicht um eine Schwachstelle handle.

Nach O’Learys Darstellung argumentierte Google sinngemäß, Kunden seien selbst dafür verantwortlich, die richtigen Berechtigungen für Config Connector zu setzen. Der Forscher hält das für eine Verfehlung des eigentlichen Problems: Der Connector überprüfe nicht, ob ein Nutzer überhaupt befugt sei, genau diese Berechtigungen für ein bestimmtes Ziel anzufordern, und Google habe keine Möglichkeit, den Missbrauch zu verhindern. O’Leary verweist zudem darauf, dass Config Connector in vielen großen Unternehmen und Behördenumgebungen eingesetzt werde, darunter auch in FedRAMP-autorisierten GCP-Umgebungen. Die Dokumentation des Werkzeugs vermittle die Risiken eines „Confused Deputy“-Angriffs aus seiner Sicht nicht angemessen.

Microsoft und Google seien mit solchen Problemen nicht allein, sagte O’Leary weiter. Ähnliche Connectoren gebe es auch bei anderen großen Cloud-Anbietern. Maßnahmen wie eine engere Begrenzung von Berechtigungen und eine klarere Trennung von Vertrauensgrenzen könnten das Risiko in den Cloud-Umgebungen von Kunden senken. Insgesamt hält O’Leary das Phänomen für ein systemisches Problem.