Dwie różne platformy chmurowe, dwie różne usługi i ten sam mechanizm prowadzący do eskalacji uprawnień. Opublikowane w ostatnich miesiącach badania Justina O’Leary’ego pokazują, jak błędnie zaprojektowane relacje zaufania pomiędzy usługami posiadającymi szerokie uprawnienia a użytkownikami mogą prowadzić do błędów z kategorii Confused Deputy.

Autor: 6 min czytania

To kolejny przykład problemu, o którym pisaliśmy już wcześniej przy okazji błędu w Meta AI Support. Tym razem podobny mechanizm został opisany w dwóch różnych usługach działających w środowiskach chmurowych – Azure Backup for AKS oraz Config Connector dla Google Cloud.

Gdzie leżał problem?

W nowoczesnych środowiskach chmurowych wiele operacji wykonywanych jest automatycznie przez usługi odpowiedzialne za backup, zarządzanie konfiguracją, wdrożenia czy orkiestrację kontenerów. Aby mogły realizować swoje zadania, często posiadają znacznie szersze uprawnienia niż zwykli użytkownicy.

Z punktu widzenia platformy wykonywane przez nią operacje są całkowicie poprawne. Problem pojawia się dopiero, gdy usługa nie zweryfikuje odpowiednio uprawnień osoby inicjującej żądanie. Zamiast działać w zakresie jej uprawnień, wykonuje operacje, korzystając z własnych uprawnień.

To właśnie istota błędu określanego jako Confused Deputy – zaufana usługa staje się nieświadomym pośrednikiem wykonującym działania, których użytkownik sam nie byłby w stanie wykonać.

Azure Backup – eskalacja uprawnień przez usługę backupu

Pierwszy z opisanych przypadków dotyczył usługi odpowiedzialnej za wykonywanie kopii zapasowych klastrów Azure Kubernetes Service (AKS).

Autor opisał scenariusz, w którym użytkownik posiadający jedynie rolę Backup Contributor w Azure RBAC, a jednocześnie nieposiadający żadnych uprawnień w Kubernetes, mógł uzyskać uprawnienia cluster-admin w wybranym klastrze AKS. Mechanizm wykorzystywał sposób, w jaki Azure Backup konfigurował funkcję Trusted Access, pozwalającą usłudze na wykonywanie uprzywilejowanych operacji wewnątrz klastra Kubernetes.

Uzyskanie roli cluster-admin oznacza pełną kontrolę nad klastrem Kubernetes, w tym możliwość wdrażania nowych workloadów, wykonywania poleceń wewnątrz kontenerów, modyfikowania konfiguracji czy dostępu do przechowywanych sekretów.

Autor badań ocenił wpływ podatności na CVSS 9.9. Microsoft usunął opisane zachowanie jeszcze przed jego publicznym ujawnieniem, jednak nie opublikował identyfikatora CVE ani nie wydał osobnego komunikatu bezpieczeństwa. Producent utrzymuje jednocześnie, że nie była to podatność wymagająca wdrożenia poprawek, co stało się przedmiotem sporu pomiędzy badaczem a Microsoftem.

Google Cloud – podobny mechanizm w Config Connector

Drugi z opisanych przypadków dotyczył Config Connector, komponentu umożliwiającego zarządzanie zasobami Google Cloud z poziomu Kubernetes.

Autor przedstawił scenariusz, w którym użytkownik posiadający jedynie możliwość tworzenia odpowiednich zasobów w przestrzeni nazw Kubernetes, mógł utworzyć obiekt IAMPolicyMember, służący do przypisywania ról IAM.

Config Connector przekazywał następnie wskazany identyfikator do GCP IAM API, czyli interfejsu odpowiedzialnego za zarządzanie uprawnieniami. Operacja była wykonywana z wykorzystaniem uprawnień usługi Config Connectora, bez weryfikacji, czy użytkownik posiada wymagane uprawnienia.

Autor badań wskazuje, że w określonych konfiguracjach mogło to prowadzić do nadania uprawnień właściciela organizacji i zdobycia pełnej kontroli nad środowiskiem.

Google nie zakwalifikowało zgłoszenia jako podatności bezpieczeństwa w swoim procesie obsługi zgłoszeń. Firma uznała, że opisany scenariusz wymaga konfiguracji niezgodnej z zaleceniami bezpieczeństwa, natomiast badacz argumentuje, że podobny mechanizm został wcześniej usunięty w innych usługach Google Cloud.

Dwa przypadki, jeden problem

Choć opisane incydenty dotyczyły różnych usług, ich źródło było bardzo podobne. W obu sytuacjach usługa posiadająca szerokie uprawnienia wykonywała operacje na podstawie żądania użytkownika, wykorzystując własne uprawnienia – bez odpowiedniej weryfikacji, czy użytkownik rzeczywiście był uprawniony do wykonania danej operacji.

Pokazuje to, że ocena bezpieczeństwa środowisk chmurowych nie powinna ograniczać się wyłącznie do analizy uprawnień użytkowników. Równie istotne jest zrozumienie relacji zaufania pomiędzy usługami posiadającymi szerokie uprawnienia a komponentami, z którymi współpracują.

Co warto sprawdzić we własnym środowisku?

Oba opisane przypadki udowadniają, że sama analiza ról użytkowników nie zawsze wystarcza. Równie ważne jest zrozumienie, jakie operacje mogą wykonywać usługi posiadające szerokie uprawnienia oraz w jaki sposób weryfikują żądania, które do nich trafiają.

Warto przede wszystkim zidentyfikować komponenty posiadające szerokie uprawnienia, takie jak Managed Identities, Service Principals, Service Accounts czy kontrolery odpowiedzialne za automatyzację środowiska. Następnie należy sprawdzić, czy wykonując operacje na żądanie użytkownika weryfikują jego rzeczywiste uprawnienia, czy polegają wyłącznie na własnych.

Dobrą praktyką jest również upewnienie się, że logi pozwalają ustalić nie tylko, która usługa wykonała daną operację, ale również kto ją zainicjował. W przypadku błędów z kategorii Confused Deputy właśnie ta informacja często pozwala odróżnić prawidłowe działanie usługi od potencjalnego nadużycia.

Podsumowanie

Badania Justina O’Leary’ego pokazują, że Confused Deputy to klasa błędów projektowych, która może występować wszędzie tam, gdzie komponent posiadający szerokie uprawnienia wykonuje operacje na podstawie żądania użytkownika, korzystając z własnych uprawnień. Przypadki z Azure i Google Cloud są jedynie kolejnymi przykładami tego mechanizmu.

Oba mają zostać omówione szerzej podczas konferencji Black Hat USA 2026.