Archiwa: Admin - Security Bez Tabu

Tysiące kontrolerów BMC narażonych na przejęcie serwerów przez lukę w IPMI 2.0

Wprowadzenie do problemu / definicja

Kontrolery BMC (Baseboard Management Controller) to wyspecjalizowane układy odpowiedzialne za zdalne zarządzanie serwerem poza głównym systemem operacyjnym. Umożliwiają administratorom wykonywanie krytycznych operacji, takich jak restart urządzenia, zarządzanie zasilaniem, dostęp do konsoli czy obsługa firmware. Ze względu na bardzo wysoki poziom uprawnień, każda słabość w interfejsach BMC może prowadzić do poważnego naruszenia bezpieczeństwa infrastruktury centrów danych.

W skrócie

Badacze bezpieczeństwa wskazali, że dziesiątki tysięcy publicznie dostępnych kontrolerów BMC odpowiadają w sposób umożliwiający przeprowadzenie ataku offline na poświadczenia. Problem dotyczy znanej od lat słabości w mechanizmie uwierzytelniania IPMI 2.0, oznaczonej jako CVE-2013-4786.

W praktyce oznacza to, że napastnik mający dostęp do portu UDP 623 może pozyskać materiał uwierzytelniający i próbować odtworzyć hasło poza systemem ofiary. Taki model ataku znacząco zwiększa ryzyko przejęcia interfejsów zarządzania serwerami, szczególnie tam, gdzie nadal używane są słabe, domyślne lub przewidywalne hasła.

zagrożone są publicznie dostępne interfejsy BMC/IPMI,
atak może być prowadzony offline, bez wielu prób logowania do urządzenia,
największe ryzyko dotyczy środowisk ze słabymi lub fabrycznymi poświadczeniami,
przejęcie BMC może oznaczać pełną kontrolę nad serwerem.

Kontekst / historia

Źródłem problemu jest konstrukcja protokołu IPMI 2.0, wykorzystywanego od wielu lat do zdalnego zarządzania sprzętem serwerowym. Słabość została powiązana z wdrożeniem IPMI 2.0 w 2004 roku, a następnie opisana jako CVE-2013-4786 w 2013 roku. Mimo że problem jest znany od dawna, wiele organizacji nadal utrzymuje interfejsy zarządzania wystawione bezpośrednio do Internetu.

W najnowszych ustaleniach zidentyfikowano około 24 650 endpointów BMC, które zwracały dane pozwalające na prowadzenie ataków słownikowych lub brute force offline. Część z tych systemów akceptowała puste nazwy użytkowników w połączeniu ze słabymi hasłami, a w innych przypadkach wykorzystywano typowe konta administracyjne, takie jak ADMIN lub root, z hasłami obecnymi w popularnych listach słownikowych.

Badacze odnotowali również oznaki aktywnego wykorzystywania tego problemu przez napastników. W niektórych przypadkach na przejętych systemach widoczne były nawet komunikaty charakterystyczne dla incydentów ransomware, co pokazuje, że ryzyko nie ma wyłącznie teoretycznego charakteru.

Analiza techniczna

Istota podatności polega na tym, że mechanizm uwierzytelniania w IPMI 2.0 może ujawnić nieuwierzytelnionemu klientowi materiał pochodny od hasła jeszcze przed zakończeniem procesu logowania. Nie jest to bezpośrednie ujawnienie hasła w postaci jawnego tekstu, ale dostarcza danych wystarczających do późniejszego odtwarzania poświadczeń metodą offline.

Z punktu widzenia napastnika jest to bardzo korzystny scenariusz. W klasycznym ataku online każda próba odgadnięcia hasła wymaga komunikacji z urządzeniem, może zostać zarejestrowana i ograniczona przez polityki bezpieczeństwa. W modelu offline atakujący pobiera materiał tylko raz, a następnie testuje kolejne warianty haseł lokalnie, bez dalszej interakcji z celem.

To znacząco zwiększa skuteczność ataku na słabe lub przewidywalne hasła. Szczególnie niebezpieczne są środowiska, w których stosowane są fabryczne dane dostępowe, powtarzalne wzorce generowania haseł albo konta uprzywilejowane pozostawione bez zmian po wdrożeniu sprzętu.

Dodatkowym problemem jest fakt, że BMC działa poza typową warstwą widoczności wielu narzędzi ochronnych. Rozwiązania EDR, monitoring systemu operacyjnego czy mechanizmy kontroli integralności hosta zwykle nie obejmują warstwy zarządzania out-of-band. W rezultacie przejęcie BMC może długo pozostać niezauważone, mimo że napastnik uzyskuje bardzo głęboki poziom kontroli nad platformą.

Konsekwencje / ryzyko

Przejęcie kontrolera BMC oznacza dostęp do jednego z najbardziej uprzywilejowanych punktów zarządzania w infrastrukturze serwerowej. Napastnik może zdalnie uruchamiać i wyłączać systemy, korzystać z konsoli, montować złośliwe obrazy, zmieniać ustawienia niskopoziomowe, ingerować w firmware i utrzymywać trwałą obecność poniżej warstwy systemu operacyjnego.

W praktyce skutki nie muszą ograniczać się do pojedynczego hosta. Jeśli sieć zarządzania out-of-band nie jest właściwie odseparowana, przejęty BMC może stać się punktem wyjścia do ruchu lateralnego w kierunku kolejnych serwerów, systemów administracyjnych, macierzy czy narzędzi provisioningowych.

W środowiskach wielodostępnych, w tym w platformach chmurowych i środowiskach GPU, ryzyko obejmuje także możliwość naruszenia izolacji pomiędzy współdzielonymi zasobami. Najpoważniejsze scenariusze obejmują wdrożenie ransomware, sabotaż operacyjny, ukrytą manipulację platformą sprzętową oraz kosztowne działania naprawcze związane z odzyskaniem zaufania do infrastruktury.

Rekomendacje

Najważniejszym krokiem obronnym jest natychmiastowe usunięcie interfejsów BMC i IPMI z publicznego Internetu. Dostęp do takich usług powinien być realizowany wyłącznie przez dedykowane, ściśle kontrolowane ścieżki administracyjne.

Organizacje powinny wdrożyć zestaw działań ograniczających ryzyko:

odseparować sieć zarządzania BMC od sieci produkcyjnej i użytkowej,
ograniczyć dostęp do interfejsów administracyjnych za pomocą list kontroli dostępu, VPN i segmentacji,
wymienić wszystkie hasła domyślne, słabe i ponownie używane,
zweryfikować konta uprzywilejowane, w tym ADMIN i root, oraz usunąć nieużywane wpisy,
wyłączyć starsze i niebezpieczne funkcje tam, gdzie to możliwe,
prowadzić ciągły monitoring ruchu w sieci out-of-band,
inwentaryzować wszystkie kontrolery BMC i regularnie testować ich ekspozycję,
sprawdzać polityki producentów dotyczące domyślnych poświadczeń i schematów generowania haseł.

Z perspektywy operacyjnej warstwa BMC powinna być traktowana jako osobny obszar bezpieczeństwa, wymagający własnych procedur hardeningu, monitoringu i reagowania na incydenty. To szczególnie ważne w organizacjach, które koncentrują ochronę głównie na systemie operacyjnym i aplikacjach, pomijając warstwę zarządzania sprzętem.

Podsumowanie

Skala ujawnionej ekspozycji pokazuje, że nawet wieloletnie i dobrze opisane słabości nadal mogą stanowić realne zagrożenie dla centrów danych. CVE-2013-4786 nie jest nową podatnością, jednak jej praktyczna użyteczność dla napastników pozostaje bardzo wysoka, zwłaszcza tam, gdzie IPMI jest publicznie dostępne i chronione słabymi poświadczeniami.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona serwerów nie może kończyć się na systemie operacyjnym i warstwie aplikacyjnej. Bez właściwego zabezpieczenia BMC organizacja pozostaje narażona na atak poniżej standardowej warstwy widoczności, gdzie wykrywanie i odzyskiwanie kontroli są znacznie trudniejsze.

Źródła

Luki typu „confused deputy” nadal zagrażają Google Cloud i Microsoft Azure

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

24 650 publicznie dostępnych interfejsów BMC ujawnia hashe IPMI przed logowaniem

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa alarmują o dużej skali ekspozycji interfejsów Baseboard Management Controller (BMC) dostępnych bezpośrednio z internetu. Problem dotyczy wdrożeń IPMI 2.0, w których jeszcze przed skutecznym uwierzytelnieniem można uzyskać materiał kryptograficzny powiązany z hasłem administratora.

W praktyce oznacza to, że napastnik nie musi prowadzić klasycznego brute force przeciwko urządzeniu. Wystarczy dostęp do usługi IPMI, aby pobrać odpowiedź użyteczną w ataku offline i następnie lokalnie odtwarzać hasło bez dalszej interakcji z celem.

W skrócie

Badanie wykazało 36 872 hosty z publicznie dostępnym IPMI.
24 650 z nich ujawniało dane pochodne od hasła jeszcze przed logowaniem.
Źródłem problemu jest znana od lat słabość CVE-2013-4786 związana z mechanizmem RAKP w IPMI 2.0.
Atakujący z dostępem do UDP/623 może pozyskać odpowiedź HMAC i prowadzić zgadywanie haseł offline.
Największe ryzyko dotyczy środowisk z hasłami fabrycznymi, słabymi lub przewidywalnymi.

Kontekst / historia

BMC to dedykowany kontroler zarządzania osadzony na płycie głównej serwera. Odpowiada za zadania out-of-band, takie jak zdalne uruchamianie i wyłączanie systemu, dostęp do konsoli, instalację systemu operacyjnego, aktualizacje firmware czy odzyskiwanie po awarii.

Z perspektywy bezpieczeństwa jest to jeden z najbardziej wrażliwych komponentów infrastruktury. BMC działa poza systemem operacyjnym hosta i posiada uprzywilejowaną pozycję wobec całej platformy serwerowej, dlatego jego przejęcie może mieć znacznie poważniejsze skutki niż kompromitacja zwykłego panelu administracyjnego.

Słabość oznaczona jako CVE-2013-4786 została opisana już w 2013 roku i dotyczy samego sposobu działania uwierzytelniania RMCP+ w IPMI 2.0. Mimo upływu lat problem pozostaje aktualny, ponieważ wiele organizacji nadal wystawia interfejsy zarządzania do internetu, a współczesne akceleratory GPU znacząco przyspieszają łamanie słabych haseł.

Analiza techniczna

Rdzeniem problemu jest mechanizm RAKP używany podczas negocjacji sesji IPMI 2.0. W określonych warunkach BMC odsyła odpowiedź zawierającą HMAC-SHA1 wyliczony z użyciem hasła konta oraz parametrów sesji znanych stronie inicjującej połączenie.

Jeżeli usługa IPMI jest osiągalna przez UDP/623, napastnik może pobrać taki materiał bez wcześniejszego zalogowania. To zasadniczo zmienia charakter zagrożenia: zamiast ataku online ograniczanego przez blokady, opóźnienia czy monitoring, pojawia się możliwość nieograniczonego testowania kandydatów na hasło lokalnie, we własnym środowisku.

W praktyce szczególnie narażone są instalacje korzystające z haseł fabrycznych, słownikowych, powtarzalnych lub tworzonych według przewidywalnych schematów. Dodatkowym problemem jest obecność standardowych nazw kont administracyjnych, takich jak ADMIN czy root, a w części przypadków także reakcja urządzeń na pustą nazwę użytkownika.

Kompromitacja BMC może dać napastnikowi dostęp poniżej warstwy systemu operacyjnego. Otwiera to drogę do zdalnego zarządzania serwerem, modyfikacji ustawień startowych, zmian firmware, utrzymywania persystencji po reinstalacji systemu oraz prowadzenia dalszego ruchu bocznego w infrastrukturze.

Konsekwencje / ryzyko

Ekspozycja BMC do internetu niesie ryzyko nieproporcjonalnie większe niż w przypadku typowych interfejsów administracyjnych. Uzyskanie dostępu do kontrolera zarządzania może umożliwić pełne przejęcie serwera, zdalne restartowanie, dostęp do konsoli, podmianę obrazów rozruchowych oraz osadzenie złośliwego kodu na poziomie firmware.

W środowiskach centrów danych, usług bare-metal i platform obsługujących obciążenia AI skutki mogą wykraczać poza pojedynczy host. Jeden podatny interfejs zarządzania może stać się punktem wejścia do segmentów infrastruktury o wysokim poziomie zaufania, zwiększając ryzyko ransomware, sabotażu operacyjnego oraz trudnych do wykrycia działań posteksploatacyjnych.

Szczególnie niepokojące jest to, że mowa o problemie znanym od wielu lat. Jego praktyczna wykorzystywalność wynika nie tyle z nowości technicznej, ile z utrzymujących się błędów konfiguracyjnych, braku segmentacji sieci zarządzającej i pozostawiania słabych poświadczeń na krytycznych urządzeniach.

Rekomendacje

Najważniejszym działaniem obronnym powinno być całkowite usunięcie interfejsów BMC z publicznego internetu. Dostęp do IPMI należy ograniczyć do wydzielonej sieci zarządzającej, a port UDP 623 blokować na granicy sieci organizacji.

Przeprowadzić pełną inwentaryzację interfejsów out-of-band i sprawdzić, czy nie są osiągalne publicznie.
Natychmiast zmienić hasła fabryczne i wymusić silne, unikalne poświadczenia dla każdego BMC.
Wyłączyć zbędne funkcje i starsze tryby IPMI, jeśli nie są wymagane operacyjnie.
Stosować dostęp przez VPN, bastion hosty oraz listy ACL zamiast bezpośredniej ekspozycji do internetu.
Monitorować ruch administracyjny i objąć BMC regularnym audytem konfiguracji oraz hardeningiem.
Traktować warstwę zarządzania sprzętem jako zasób krytyczny i ograniczyć liczbę uprzywilejowanych administratorów.

W organizacjach o podwyższonym profilu ryzyka BMC powinny być objęte takimi samymi rygorami bezpieczeństwa jak inne systemy klasy Tier 0. Obejmuje to ścisłe logowanie dostępu, kontrolę zmian, testy bezpieczeństwa firmware i bieżące wykrywanie prób nieautoryzowanej aktywności.

Podsumowanie

Przypadek 24 650 publicznie dostępnych interfejsów BMC ujawniających hashe IPMI przed logowaniem pokazuje, że wieloletnie słabości protokołów zarządzania nadal mogą stanowić realne zagrożenie. Problem wynika zarówno z ograniczeń samej specyfikacji IPMI 2.0, jak i z błędnej ekspozycji usług administracyjnych oraz utrzymywania słabych poświadczeń.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona serwerów nie kończy się na systemie operacyjnym i narzędziach EDR. Warstwa out-of-band, firmware oraz kontrolery BMC muszą być chronione z taką samą dyscypliną jak pozostałe elementy infrastruktury krytycznej.

Źródła

Luki typu „confused deputy” nadal zagrażają Google Cloud i Microsoft Azure

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

Luki typu „confused deputy” nadal zagrażają Google Cloud i Microsoft Azure

Wprowadzenie do problemu / definicja

W skrócie

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

Analiza techniczna

Konsekwencje / ryzyko

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.

Rekomendacje

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

Ź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

Luki typu „confused deputy” nadal zagrażają Google Cloud i Microsoft Azure

Wprowadzenie do problemu / definicja

W skrócie

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

Analiza techniczna

Konsekwencje / ryzyko

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.

Rekomendacje

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

Ź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

Hermes AI wykorzystany po włamaniu do resortu finansów Tajlandii. Automatyzacja post-exploitation wchodzi na nowy poziom

Wprowadzenie do problemu / definicja

Ujawniony w lipcu 2026 roku incydent związany z infrastrukturą tajlandzkiego Ministerstwa Finansów pokazuje nowy etap wykorzystania sztucznej inteligencji w operacjach ofensywnych. W centrum zdarzenia znalazł się otwartoźródłowy agent Hermes AI, którego nie użyto do uzyskania pierwszego dostępu do środowiska, lecz do automatyzacji działań prowadzonych już po kompromitacji systemu.

To istotna zmiana perspektywy. Zamiast traktować AI wyłącznie jako narzędzie pomocnicze do pisania skryptów czy analizy danych, należy coraz częściej postrzegać agentów zdolnych do wykonywania poleceń systemowych jako półautonomicznych operatorów, którzy przejmują żmudne zadania rozpoznawcze i administracyjne wykonywane dotąd ręcznie przez intruza.

W skrócie

Atakujący uruchomił Hermes AI na serwerze pośredniczącym w trybie pozwalającym na samodzielne wykonywanie komend.
Agent realizował typowe działania post-exploitation, w tym enumerację hosta, analizę systemu plików i wyszukiwanie ścieżek eskalacji uprawnień.
Materiały wskazują na wcześniejsze osadzenie web shella oraz przygotowanie skryptów ukierunkowanych na środowisko Hadoop i HiveServer2.
Nie potwierdzono publicznie eksfiltracji danych, ale incydent pokazuje praktyczne użycie AI do przyspieszania działań po włamaniu.

Kontekst / historia

Sprawa wyszła na jaw po odkryciu niechronionego serwera z włączonym listingiem katalogów. Na zasobie pozostawiono logi agenta, zestaw narzędzi ofensywnych oraz inne artefakty operacyjne, które umożliwiły badaczom odtworzenie części aktywności napastnika. Z dostępnych materiałów wynika, że operator dysponował już wcześniej dostępem do środowiska ofiary, a Hermes służył do automatyzowania kolejnych etapów działań.

W szerszym ujęciu incydent wpisuje się w rosnący trend praktycznego zastosowania modeli i agentów AI w cyberatakach. Wcześniej najczęściej mówiono o wykorzystaniu modeli językowych do przygotowywania treści socjotechnicznych, analizowania danych lub wspierania tworzenia skryptów. Tym razem kluczowe było przejście od wsparcia analitycznego do operacyjnego wykonawstwa, czyli realizacji sekwencji działań na zainfekowanym systemie bez ciągłej interwencji człowieka.

Analiza techniczna

Z ujawnionych informacji wynika, że Hermes został uruchomiony w trybie pracy umożliwiającym wykonywanie ryzykownych poleceń bez każdorazowego zatwierdzania. W praktyce oznacza to możliwość odbierania instrukcji, uruchamiania komend powłoki, analizowania rezultatów i kontynuowania działań na podstawie uzyskanych wyników.

Logi wskazują na klasyczny łańcuch aktywności post-exploitation. Agent miał wykonywać skrypty służące do wykrywania ścieżek eskalacji uprawnień w systemach Linux, wyszukiwać pliki oraz binaria z podwyższonymi uprawnieniami, listować zasoby i rekurencyjnie przeszukiwać katalogi dostępne z poziomu zainfekowanego hosta. W artefaktach pojawiały się także narzędzia enumeracyjne oraz elementy związane z lokalnymi scenariuszami podnoszenia uprawnień.

Szczególnie istotny był wątek środowiska Hadoop i usługi HiveServer2. Jeden z przygotowanych skryptów miał wykorzystywać konfigurację uwierzytelniania ustawioną w sposób niedający realnej weryfikacji hasła. W takim scenariuszu możliwe staje się dostarczenie złośliwego komponentu w formie biblioteki JAR implementującej funkcję użytkownika, a następnie wykonywanie poleceń systemowych za pośrednictwem zapytań do warstwy SQL. To nie tyle klasyczne włamanie do bazy, ile przekształcenie zaplecza analitycznego w punkt wykonania kodu na poziomie konta usługi.

Odzyskane materiały sugerowały również obecność web shella ukrytego w strukturze katalogów serwera WWW, testowanie domyślnych poświadczeń oraz składowanie dodatkowych implantów dla systemów Linux i Windows. Najważniejsze pozostaje jednak to, że Hermes pełnił głównie rolę automatycznego wykonawcy: odczytywał wyniki, ponawiał enumerację, przechodził przez kolejne katalogi i dokumentował stan środowiska w sposób przypominający nieprzerwaną pracę operatora terminala.

Konsekwencje / ryzyko

Największe znaczenie incydentu polega na obniżeniu kosztu operacyjnego działań po uzyskaniu dostępu do systemu. W tradycyjnym modelu intruz musi aktywnie sterować sesją, interpretować wyniki i ręcznie podejmować kolejne decyzje. W modelu wspieranym przez agenta AI duża część tych czynności może zostać zautomatyzowana, co skraca czas rozpoznania środowiska i zwiększa skalowalność kampanii.

Dla zespołów bezpieczeństwa oznacza to bardziej intensywne, ale pozornie znajome wzorce aktywności. Agent nie musi korzystać z egzotycznych technik. Wystarczy, że będzie wykonywać standardowe komendy administracyjne, uruchamiać popularne narzędzia audytowe i poruszać się po systemie w logicznej sekwencji. To utrudnia odróżnienie ręcznie sterowanego ataku od półautonomicznej aktywności wspieranej przez AI.

Dodatkowe ryzyko wynika z błędów konfiguracyjnych oraz nadmiernych uprawnień usług. Jeżeli komponenty takie jak HiveServer2 są wdrożone bez właściwego uwierzytelniania albo pozwalają na zbyt szerokie ładowanie dodatkowych bibliotek, mogą stać się dogodnym punktem do ruchu bocznego, wykonywania kodu i dostępu do dużych wolumenów danych. W sektorze publicznym konsekwencje mogą obejmować narażenie dokumentów wewnętrznych, danych kadrowych oraz informacji wspierających dalsze etapy operacji.

Rekomendacje

Organizacje powinny traktować agentów AI posiadających dostęp do powłoki, systemu plików i sieci jako nową klasę ryzyka operacyjnego. Takie narzędzia należy monitorować równie rygorystycznie jak frameworki zdalnej administracji, komponenty C2 czy zestawy używane przez zespoły red team.

Zweryfikować konfigurację HiveServer2 oraz innych elementów ekosystemu Hadoop, zwłaszcza ustawienia uwierzytelniania i możliwość ładowania bibliotek JAR.
Monitorować połączenia między warstwą serwerów WWW a usługami zaplecza analitycznego, w tym nietypowy ruch do portów administracyjnych i danych.
Wzmocnić detekcję działań post-exploitation, takich jak seryjna enumeracja, przeszukiwanie web rootów, masowe listowanie katalogów oraz gwałtowny wzrost liczby poleceń wykonywanych przez pojedynczy proces lub konto.
Aktualizować systemy Linux, ograniczać uprawnienia kont usługowych i regularnie przeglądać zasoby WWW pod kątem ukrytych skryptów i web shelli.
Rozszerzyć threat hunting o artefakty charakterystyczne dla agentów AI, w tym katalogi wyników, przewidywalne nazwy logów, wzorce sesji terminalowych i iteracyjny sposób wykonywania poleceń.

Podsumowanie

Incydent z użyciem Hermes AI pokazuje, że skuteczne wykorzystanie sztucznej inteligencji w cyberatakach nie wymaga jeszcze w pełni autonomicznych systemów. Wystarczy agent, który po uzyskaniu przez intruza dostępu do środowiska potrafi konsekwentnie realizować długą serię znanych czynności technicznych bez ciągłego nadzoru człowieka.

Dla obrońców to wyraźny sygnał, że faza post-exploitation może stać się szybsza, tańsza i łatwiejsza do skalowania. Odpowiedzią powinno być połączenie bezpiecznej konfiguracji usług, twardego ograniczania uprawnień, monitoringu ruchu wewnętrznego oraz detekcji wzorców przypominających zautomatyzowaną aktywność operatora na powłoce.