Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
W usłudze Azure Automation ujawniono krytyczną lukę bezpieczeństwa, która w określonych warunkach mogła doprowadzić do przejęcia zarządzanej tożsamości innego klienta chmury. Problem wynikał z połączenia niebezpiecznej konfiguracji domyślnej oraz dodatkowych błędów logicznych i implementacyjnych, co otwierało drogę do naruszenia izolacji między tenantami.
Z perspektywy bezpieczeństwa chmury jest to szczególnie poważny scenariusz, ponieważ Azure Automation często działa na uprzywilejowanych tożsamościach i obsługuje zadania związane z administracją, wdrożeniami, rotacją sekretów oraz utrzymaniem środowisk produkcyjnych.
W skrócie
Luka dotyczyła sytuacji, w której atakujący posiadający własne konto Azure Automation mógł wykorzystać publicznie dostępny punkt końcowy oraz dwa dodatkowe błędy w mechanizmach usługi, aby przejąć tożsamość automatyzacji należącą do innej organizacji. Podatność otrzymała identyfikator CVE-2025-29827 i została oceniona jako krytyczna.
- Dotknięta usługa: Azure Automation
- Typ zagrożenia: przejęcie tożsamości cross-tenant
- Identyfikator: CVE-2025-29827
- Współczynnik CVSS: 9.9
- Potencjalny skutek: dostęp do zasobów, sekretów i procesów automatyzacji ofiary
Kontekst / historia
Azure Automation od lat pozostaje atrakcyjnym celem dla badaczy bezpieczeństwa, ponieważ koncentruje w sobie uprawnienia administracyjne oraz dostęp do kluczowych procesów operacyjnych. Konta automatyzacji są często zintegrowane z usługami takimi jak Key Vault, konta magazynu, wdrożenia infrastruktury czy mechanizmy zarządzania zasobami.
To nie pierwszy przypadek, gdy ta usługa znajduje się w centrum zainteresowania społeczności bezpieczeństwa. W 2021 roku opisano podatność AutoWarp, również związaną z możliwością pozyskiwania tokenów zarządzanych tożsamości z kontekstu Azure Automation. Obecny przypadek opiera się jednak na innym łańcuchu eksploatacji i pokazuje, że usługi automatyzacji nadal stanowią newralgiczny punkt środowisk cloud-native.
Analiza techniczna
Atak nie opierał się na pojedynczym błędzie, lecz na łańcuchu kilku słabości. Pierwszym elementem była domyślna konfiguracja, która mogła prowadzić do publicznej ekspozycji punktu końcowego powiązanego z kontem Azure Automation. Taka ekspozycja zwiększała powierzchnię ataku i umożliwiała interakcję z komponentami, które nie powinny być dostępne z zewnątrz.
Kolejnymi elementami były błędy implementacyjne i logiczne związane z kontrolą dostępu oraz egzekwowaniem granic zaufania między tenantami. Ich połączenie umożliwiało atakującemu rozpoczęcie działań z własnego środowiska, a następnie doprowadzenie do przejęcia tożsamości automatyzacji innej organizacji.
Kluczowe jest to, że nie był to klasyczny scenariusz zdalnego wykonania kodu. Mechanizm zagrożenia opierał się na obejściu izolacji oraz uzyskaniu możliwości działania jako zaufana tożsamość usługi. W praktyce oznacza to, że nawet bez bezpośredniego przejęcia maszyny czy procesu ofiary możliwe było wykonywanie działań w jej imieniu przez interfejsy API, portal lub narzędzia administracyjne.
Jeżeli przejęta zarządzana tożsamość miała szerokie role RBAC lub dostęp do zasobów o wysokiej wartości, kompromitacja mogła objąć nie tylko samą usługę Automation, ale również znaczną część infrastruktury chmurowej organizacji.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem luki była możliwość przełamania granicy między tenantami, co w środowisku wielodzierżawnym należy do najbardziej niebezpiecznych klas incydentów. Tego rodzaju podatność podważa fundamentalne założenia bezpieczeństwa chmury opartej na izolacji klientów.
- Przejęcie zarządzanej tożsamości przypisanej do konta Azure Automation
- Dostęp do runbooków, konfiguracji i procesów automatyzacyjnych
- Możliwość odczytu lub modyfikacji wrażliwych danych konfiguracyjnych
- Dalsza eskalacja uprawnień w subskrypcji lub grupach zasobów
- Ruch boczny do innych usług zaufanych wobec przejętej tożsamości
- Ryzyko naruszenia poufności, integralności i dostępności systemów
Skala skutków zależała bezpośrednio od zakresu uprawnień przypisanych do przejętej tożsamości. W organizacjach, które wykorzystują automatyzację do operacji administracyjnych, wdrożeń i obsługi sekretów, taki incydent mógłby mieć bardzo szeroki zasięg operacyjny i biznesowy.
Rekomendacje
Organizacje korzystające z Azure Automation powinny potraktować ten przypadek jako impuls do przeglądu całego modelu bezpieczeństwa usług automatyzacji oraz zarządzanych tożsamości.
- Zweryfikować, czy punkty końcowe i powiązane komponenty Azure Automation nie są niepotrzebnie publicznie dostępne
- Przeprowadzić audyt wszystkich managed identities używanych przez konta automatyzacji
- Ograniczyć uprawnienia zgodnie z zasadą najmniejszych uprawnień
- Rozdzielić zadania wysokiego ryzyka od automatyzacji o niższym poziomie uprzywilejowania
- Monitorować użycie tożsamości, uruchamianie runbooków, zmiany ról i nietypowe wywołania API
- Przeanalizować dostęp do sekretów, certyfikatów i connection assets oraz rozważyć ich rotację
- Modelować pełne ścieżki ataku, a nie tylko pojedyncze błędy techniczne
W praktyce szczególnego znaczenia nabiera regularny przegląd ról RBAC, segmentacja automatyzacji oraz objęcie usług automatyzacyjnych takimi samymi kontrolami jak systemów administracyjnych i platform CI/CD.
Podsumowanie
Luka w Azure Automation pokazuje, że krytyczne incydenty w chmurze coraz częściej wynikają z połączenia błędnych ustawień domyślnych, słabości logicznych i nadmiernych uprawnień tożsamości. W tym przypadku skutkiem mogło być przejęcie tożsamości między tenantami, a następnie uzyskanie dostępu do danych, skryptów i zasobów należących do innej organizacji.
Dla zespołów bezpieczeństwa najważniejsza lekcja jest jednoznaczna: usługi automatyzacji należy traktować jak uprzywilejowany element infrastruktury. Ich ekspozycja sieciowa, model zaufania, zakres ról i poziom monitoringu powinny podlegać rygorystycznej kontroli.
Źródła
- Dark Reading — Default Azure Automation Setting Enables Cross-Tenant Identity Takeover — https://www.darkreading.com/cloud-security/default-azure-automation-setting-cross-tenant-identity-takeover
- Microsoft Security Response Center — CVE-2025-29827 — https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-29827
- NIST National Vulnerability Database — CVE-2025-29827 — https://nvd.nist.gov/vuln/detail/CVE-2025-29827
- Orca Security Research Pod — AutoWarp: Critical Cross-Account Vulnerability in Microsoft Azure Automation Service — https://orca.security/resources/blog/autowarp-microsoft-azure-automation-service-vulnerability/