Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Podatności typu „confused deputy” należą do groźnej klasy błędów projektowych związanych z niewłaściwym przekazywaniem uprawnień między komponentami systemu. W takim scenariuszu uprzywilejowana usługa wykonuje operację w imieniu mniej uprzywilejowanego podmiotu, ale bez poprawnej weryfikacji źródła żądania oraz faktycznego zakresu autoryzacji. W środowiskach chmurowych może to prowadzić do obejścia mechanizmów IAM, eskalacji uprawnień i przejęcia kontroli nad zasobami.
Problem jest szczególnie istotny w architekturach cloud-native, gdzie wiele procesów opiera się na automatyzacji, kontach serwisowych, tożsamościach zarządzanych oraz integracji pomiędzy usługami. Im więcej pośredników bierze udział w realizacji operacji, tym większe ryzyko, że jeden z nich stanie się „zdezorientowanym zastępcą”.
W skrócie
Badacz bezpieczeństwa Justin O’Leary opisał dwa przypadki podatności typu „confused deputy” dotyczące Microsoft Azure oraz Google Cloud Platform. W Azure problem miał dotyczyć łańcucha zaufania w usłudze kopii zapasowych dla Azure Kubernetes Service, co mogło umożliwić eskalację do uprawnień cluster-admin.
W przypadku Google Cloud ryzyko miało dotyczyć Config Connectora, gdzie uprzywilejowany komponent mógł zostać wykorzystany do nadania szerokich uprawnień organizacyjnych z pominięciem oczekiwanych kontroli IAM. Oba scenariusze pokazują, że problem nie wynika wyłącznie z pojedynczych błędów implementacyjnych, ale z szerszego wzorca architektonicznego obecnego w nowoczesnych środowiskach chmurowych.
Kontekst / historia
Pojęcie „confused deputy” funkcjonuje w bezpieczeństwie systemów od końca lat 80. Odnosi się do sytuacji, w której program lub usługa posiadająca szersze uprawnienia niż użytkownik zostaje nakłoniona do wykonania operacji sprzecznej z rzeczywistym modelem autoryzacji. Choć sam koncept jest znany od dekad, współczesne środowiska chmurowe znacząco zwiększają skalę ryzyka.
Powodem jest rosnąca liczba zależności między usługami, operatorami Kubernetes, konektorami, platformami Infrastructure as Code i mechanizmami delegated access. W takich warunkach nie wystarczy już tylko kontrolować, jakie uprawnienia ma użytkownik. Trzeba także rozumieć, jakie uprawnienia mają usługi działające w jego imieniu i czy zachowują pełny kontekst tożsamości inicjatora operacji.
Analiza techniczna
W opisywanym scenariuszu Azure chodziło o usługę backupu dla Azure Kubernetes Service oraz mechanizm Trusted Access. Model ten ma umożliwiać bezpieczne przyznanie wybranym usługom dostępu do klastra przy użyciu ściśle określonych uprawnień. Problem pojawia się wtedy, gdy komponent pośredniczący przyjmuje żądanie od podmiotu o ograniczonych prawach, a następnie realizuje je z własnego, bardziej uprzywilejowanego kontekstu.
W praktyce oznacza to, że użytkownik posiadający jedynie ograniczoną rolę związaną z backupem może doprowadzić do uzyskania kontroli administracyjnej nad klastrem Kubernetes. Uprawnienie cluster-admin otwiera drogę do pełnej manipulacji workloadami, sekretami, konfiguracją i ruchem sieciowym. Atakujący może wdrażać złośliwe komponenty, przejmować tokeny usługowe, uzyskiwać dostęp do kopii zapasowych lub wykorzystywać klaster jako punkt wyjścia do dalszego ruchu lateralnego.
W przypadku Google Cloud problem miał dotyczyć Config Connectora, czyli narzędzia pozwalającego zarządzać zasobami GCP z poziomu deklaratywnej konfiguracji Kubernetes. Sednem ryzyka było niewystarczające sprawdzenie, czy użytkownik inicjujący operację rzeczywiście ma prawo do nadawania określonych ról IAM dla wskazanego zasobu. Jeśli konektor przekazuje do API żądania dostarczone przez użytkownika, ale korzysta przy tym z własnych uprzywilejowanych poświadczeń, powstaje klasyczny mechanizm „confused deputy”.
Dodatkowym problemem jest rozdzielenie aktora logicznego od aktora widocznego w logach. Operacja może wyglądać jak działanie zaufanego konta serwisowego albo komponentu automatyzacji, a nie użytkownika, który faktycznie ją zainicjował. To znacząco utrudnia detekcję, analizę incydentu i szybkie ustalenie rzeczywistej ścieżki nadużycia.
Konsekwencje / ryzyko
Ryzyko związane z podatnościami „confused deputy” w chmurze jest wielowymiarowe. Tego typu luki mogą obchodzić granice bezpieczeństwa zaprojektowane w warstwie IAM i RBAC, prowadzić do błyskawicznej eskalacji uprawnień oraz maskować nieautoryzowane działania jako legalną aktywność zaufanej usługi.
- przejęcie środowisk Kubernetes i zasobów chmurowych,
- wyciek danych z backupów, wolumenów i sekretów,
- wdrożenie złośliwego kodu w workloadach oraz pipeline’ach,
- trwałe utrzymanie dostępu przez nadanie sobie ról IAM,
- utrudnienie analizy śledczej przez ukrycie źródła operacji w logach kont serwisowych.
Szczególnie narażone są duże organizacje wielozespołowe, środowiska intensywnie korzystające z automatyzacji oraz podmioty, które łączą Kubernetes, managed identities i rozbudowane integracje między usługami.
Rekomendacje
Organizacje korzystające z Azure, GCP i Kubernetes powinny potraktować takie przypadki jako sygnał do gruntownego przeglądu architektury zaufania między usługami. Kluczowe jest ograniczenie sytuacji, w których komponent pośredniczący może wykonywać operacje o szerszym zakresie niż użytkownik inicjujący żądanie.
- przeprowadzenie audytu wszystkich managed identities, service accounts i konektorów integracyjnych,
- weryfikacja, czy usługi pośredniczące zachowują kontekst tożsamości inicjatora operacji,
- ograniczenie ról przypisywanych komponentom automatyzacji zgodnie z zasadą najmniejszych uprawnień,
- regularny przegląd relacji trusted access oraz polityk IAM i RBAC,
- monitorowanie działań wykonywanych przez konta serwisowe pod kątem anomalii,
- korelacja logów Kubernetes z logami chmurowymi w celu ustalenia faktycznego źródła operacji,
- testowanie scenariuszy privilege escalation w procesach DevSecOps,
- wymaganie od dostawców jasnej dokumentacji ograniczeń bezpieczeństwa konektorów i usług pośredniczących.
W praktyce warto również wdrożyć alerty dla zdarzeń obejmujących tworzenie lub modyfikację powiązań IAM, użycie wysoko uprzywilejowanych kont serwisowych oraz nietypowe działania wykonywane z mniej zaufanych przestrzeni nazw i środowisk roboczych.
Podsumowanie
Opisane przypadki pokazują, że podatności typu „confused deputy” pozostają jednym z bardziej niedocenianych zagrożeń w bezpieczeństwie chmury. Problem nie ogranicza się do pojedynczych błędów w Azure czy Google Cloud, lecz dotyczy szerszego wzorca projektowego obecnego w nowoczesnych architekturach opartych na automatyzacji i tożsamościach maszynowych.
Dla zespołów bezpieczeństwa oznacza to konieczność analizy nie tylko tego, jakie uprawnienia posiada dany komponent, ale także w czyim imieniu i na jakiej podstawie wykonuje operacje. To właśnie na styku delegacji, nadmiernego zaufania i słabej walidacji autoryzacji powstają ścieżki prowadzące do najgroźniejszych eskalacji uprawnień.
Źródła
- https://www.darkreading.com/cloud-security/confused-deputy-flaws-google-cloud-microsoft-azure
- https://www.blackhat.com/us-26/briefings/schedule/#trust-no-deputy-breaking-azure-and-gcp-through-managed-identity-chains-46218
- https://cwe.mitre.org/data/definitions/441.html
- https://cloud.google.com/config-connector/docs/overview
- https://css.csail.mit.edu/6.858/2014/readings/confused-deputy.pdf