Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Podatności typu „confused deputy” należą do szczególnie niebezpiecznych błędów projektowych w nowoczesnych środowiskach chmurowych. Występują wtedy, gdy uprzywilejowana usługa wykonuje operacje w imieniu mniej uprzywilejowanego podmiotu, nie zachowując pełnego kontekstu źródła żądania i nie egzekwując właściwej autoryzacji. W praktyce oznacza to, że atakujący może nakłonić zaufany komponent do przeprowadzenia działań z uprawnieniami, których sam bezpośrednio nie posiada.
Najnowsze opisy przypadków dotyczą Microsoft Azure oraz Google Cloud Platform i pokazują, że nawet dojrzałe platformy public cloud nadal pozostają podatne na nadużycia wynikające z błędnych relacji zaufania między usługami, tożsamościami zarządzanymi i warstwą automatyzacji.
W skrócie
Badacz bezpieczeństwa Justin O’Leary opisał dwa scenariusze, w których mechanizmy delegowania uprawnień w Azure i Google Cloud mogły prowadzić do eskalacji uprawnień lub obejścia kontroli dostępu. W Azure problem miał dotyczyć usługi backupu dla AKS oraz mechanizmu Trusted Access, a w Google Cloud — Config Connectora, który operował z użyciem uprzywilejowanych poświadczeń.
- W Azure możliwa była eskalacja do poziomu administratora klastra Kubernetes.
- W Google Cloud ryzyko dotyczyło obejścia kontroli IAM przez komponent pośredniczący.
- W obu przypadkach źródłem problemu był wadliwy model zaufania między usługą zarządzaną a tożsamością wykonującą operację.
Kontekst / historia
Pojęcie „confused deputy” funkcjonuje w bezpieczeństwie od dekad i odnosi się do sytuacji, w której uprzywilejowany „pośrednik” zostaje wykorzystany do wykonania operacji sprzecznej z rzeczywistymi uprawnieniami nadawcy żądania. Choć sam wzorzec nie jest nowy, jego znaczenie wzrosło wraz z popularyzacją architektur cloud-native, gdzie pojedyncze żądanie przechodzi przez wiele warstw pośrednich.
W środowiskach chmurowych jedna operacja może obejmować API, operator Kubernetes, konto serwisowe, mechanizm automatyzacji i końcową usługę dostawcy. Jeśli którykolwiek element tego łańcucha nie weryfikuje autoryzacji względem pierwotnego podmiotu inicjującego akcję, pojawia się możliwość nadużycia. To sprawia, że problem ma charakter architektoniczny, a nie wyłącznie implementacyjny.
Analiza techniczna
W scenariuszu dotyczącym Microsoft Azure badacz wskazał na usługę backupu dla Azure Kubernetes Service oraz powiązany z nią mechanizm Trusted Access. Ten model pozwala określonym usługom komunikować się z klastrem AKS z odpowiednim poziomem zaufania. Przy niewłaściwym wykorzystaniu tej relacji możliwe było podniesienie uprawnień z roli Backup Contributor do poziomu cluster-admin.
Z perspektywy bezpieczeństwa jest to bardzo poważne, ponieważ uprawnienia cluster-admin w Kubernetes oznaczają w praktyce pełną kontrolę nad klastrem. Atakujący może tworzyć i modyfikować workloady, uzyskiwać dostęp do sekretów, uruchamiać złośliwe kontenery, wykonywać ruch boczny oraz przejmować kolejne tożsamości używane przez aplikacje i integracje z chmurą.
W przypadku Google Cloud problem miał dotyczyć Config Connectora, czyli narzędzia łączącego zarządzanie zasobami Google Cloud z ekosystemem Kubernetes. Zgodnie z opisem komponent ten mógł przekazywać żądania do interfejsów Google Cloud przy użyciu własnych, uprzywilejowanych poświadczeń, bez wystarczającej walidacji tego, czy użytkownik inicjujący zmianę rzeczywiście posiadał odpowiednie uprawnienia do wskazanego zasobu.
To klasyczny przykład luki typu „confused deputy”: komponent o wysokim poziomie uprawnień wykonuje operację na podstawie danych kontrolowanych przez podmiot o niższych uprawnieniach. Dodatkowym problemem pozostaje telemetria. Jeśli akcje wykonywane są z perspektywy konta serwisowego lub zarządzanej tożsamości, ślady w logach mogą wyglądać jak legalna aktywność komponentu systemowego, co utrudnia wykrycie nadużycia i analizę incydentu.
Konsekwencje / ryzyko
Ryzyko związane z tego typu podatnościami jest wysokie, ponieważ dotyczy samego modelu autoryzacji i zaufania w środowisku chmurowym. Nie chodzi więc o pojedynczy błąd o ograniczonym wpływie, lecz o potencjalną możliwość przejęcia kontroli nad krytycznymi elementami infrastruktury.
- eskalacja uprawnień do poziomu administracyjnego w chmurze lub klastrze Kubernetes,
- dostęp do backupów oraz danych wrażliwych,
- wdrożenie złośliwych workloadów i utrzymanie trwałej obecności w środowisku,
- wykorzystanie kont serwisowych do dalszego ruchu bocznego,
- ukrycie działań napastnika za zaufaną usługą,
- obejście wybranych mechanizmów IAM i polityk segmentacji.
Najbardziej niepokojące jest to, że podobne scenariusze mogą dotyczyć także innych usług, operatorów i konektorów infrastrukturalnych. Wiele nowoczesnych platform opiera się na modelu, w którym komponent pośredni działa z wysokim poziomem zaufania. Jeśli nie uwzględniono twardych granic autoryzacji, ryzyko może mieć charakter systemowy.
Rekomendacje
Organizacje korzystające z Azure, Google Cloud i Kubernetes powinny potraktować ten problem jako element szerszego przeglądu architektury bezpieczeństwa. Samo poleganie na domyślnych mechanizmach usług zarządzanych nie wystarcza, jeśli nie towarzyszy temu kontrola nad relacjami zaufania.
- Przeprowadzić audyt wszystkich usług, operatorów i konektorów działających z użyciem kont serwisowych lub zarządzanych tożsamości.
- Ograniczyć zakres uprawnień komponentów pośredniczących zgodnie z zasadą najmniejszych uprawnień.
- Egzekwować autoryzację względem pierwotnego nadawcy żądania, a nie wyłącznie wobec usługi wykonującej operację.
- Segmentować granice zaufania między Kubernetes a natywnym IAM dostawcy chmury.
- Monitorować nietypowe operacje wykonywane przez konta serwisowe i tożsamości zarządzane.
- Korelować logi z warstw Kubernetes, IAM, CI/CD i narzędzi automatyzacji, aby ustalić rzeczywiste źródło żądania.
- Uwzględnić scenariusze privilege escalation przez usługi pośredniczące w ćwiczeniach red team i przeglądach bezpieczeństwa.
- Śledzić poprawki dostawców, nawet jeśli nie są formalnie opisane jako osobne podatności.
Podsumowanie
Opisane przypadki pokazują, że luki typu „confused deputy” pozostają realnym zagrożeniem dla środowisk public cloud i platform Kubernetes. Problem nie wynika wyłącznie z nadmiernych uprawnień, lecz z błędnego delegowania zaufania między komponentami, które działają w imieniu użytkowników lub workloadów.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że należy audytować nie tylko użytkowników i role IAM, ale również mechanizmy automatyzacji, konta serwisowe oraz kontrolery pośredniczące. Właśnie tam mogą powstawać ścieżki do eskalacji uprawnień, obejścia kontroli dostępu i ukrywania działań atakującego.
Źródła
- Confused Deputy Flaws Persist in Google Cloud, Microsoft Azure — https://www.darkreading.com/cloud-security/confused-deputy-flaws-google-cloud-microsoft-azure
- Trust No Deputy: Breaking Azure and GCP Through Managed Identity Chains — https://www.blackhat.com/us-26/briefings/schedule/#trust-no-deputy-breaking-azure-and-gcp-through-managed-identity-chains-46440
- The Confused Deputy Problem — https://css.csail.mit.edu/6.858/2019/readings/confused-deputy.pdf