Usługi chmurowe od lat promowane są jako rozwiązania zapewniające wysoki poziom bezpieczeństwa i izolacji pomiędzy klientami. Jednym z fundamentów takiego modelu jest przekonanie, że dane jednej organizacji są całkowicie odseparowane od zasobów innych klientów korzystających z tej samej platformy.

Autor: 7 min czytania

Najnowsze badania firmy Wiz pokazały jednak, że nawet niewielki błąd architektoniczny może zachwiać tym założeniem. Odkryta podatność, nazwana CosmosEscape, umożliwiała przełamanie izolacji w usłudze Azure Cosmos DB i – w teorii – uzyskanie pełnego dostępu do baz danych należących do innych klientów Microsoft Azure, a nawet do części wewnętrznych usług Microsoftu. Producent usunął już lukę i poinformował, że nie odnotowano żadnych oznak jej wykorzystania poza kontrolowanymi próbami pentesterów.

Azure Cosmos DB – serce wielu usług chmurowych

Azure Cosmos DB to jedna z najważniejszych usług bazodanowych dostępnych w chmurze Microsoft Azure. Korzystają z niej tysiące organizacji do przechowywania danych aplikacji webowych, systemów IoT, platform e-commerce czy rozwiązań wykorzystujących sztuczną inteligencję.

Co istotne, Cosmos DB stanowi również element infrastruktury wielu usług Microsoft, takich jak Teams, Copilot czy Entra ID. Oznacza to, że podatność w tej warstwie może mieć znacznie większe konsekwencje niż klasyczny błąd w pojedynczej aplikacji.

Od jednego zapytania do przejęcia całej platformy

Punktem wejścia okazał się interfejs Gremlin API, wykorzystywany do obsługi grafowych baz danych.

Badacze zauważyli, że odpowiednio przygotowane zapytanie pozwalało na opuszczenie ograniczonego środowiska wykonywania kodu (sandbox) i uzyskanie możliwości wykonywania poleceń na współdzielonym komponencie infrastruktury odpowiedzialnym za obsługę zapytań klientów. To właśnie ten element był kluczowy dla całego łańcucha ataku.

Po uzyskaniu wykonania kodu na serwerze obsługującym wielu klientów badacze znaleźli dane uwierzytelniające wykorzystywane przez samą usługę Azure Cosmos DB. Dzięki nim możliwe było przejście do kolejnego etapu ataku.

Cosmos Master Key – klucz otwierający wszystkie drzwi

Najgroźniejszym odkryciem był tzw. Cosmos Master Key – platformowy klucz wykorzystywany przez usługę do wykonywania operacji administracyjnych.

Nie był to klucz przypisany do pojedynczej bazy danych ani konkretnego klienta. Pozwalał on na wygenerowanie Primary Key praktycznie dla dowolnego konta Azure Cosmos DB, niezależnie od regionu, typu API czy właściciela.

W praktyce oznaczałoby to możliwość uzyskania pełnych uprawnień do odczytu, modyfikacji i usuwania danych znajdujących się w wybranej bazie.

Badacze podkreślają, że problem miał charakter architektoniczny – pojedynczy sekret posiadał zbyt szerokie uprawnienia, obejmujące całą platformę.

Poniżej znajduje się schemat ataku przygotowany przez Wiz:

Źródło: wiz.io

Atak nie kończył się na zdobyciu klucza

Uzyskanie dostępu do platformowego sekretu otwierało również drogę do specjalnej bazy konfiguracyjnej wykorzystywanej przez Azure Cosmos DB.

Znajdowały się w niej informacje o kontach klientów, identyfikatorach subskrypcji, identyfikatorach tenantów, konfiguracji sieciowej oraz innych metadanych potrzebnych do działania usługi.

Dzięki temu atakujący mógł nie tylko uzyskać dostęp do przypadkowych baz danych, ale również wyszukać konkretną organizację, a następnie pobrać klucze umożliwiające pełną kontrolę nad jej środowiskiem.

Co istotne, potencjalnie zagrożone były również instancje odizolowane sieciowo, ponieważ kontrola dostępu była egzekwowana właśnie przez przejęty komponent infrastruktury.

Microsoft zareagował bardzo szybko

Wiz zgłosił podatność do Microsoftu jeszcze pod koniec 2025 roku.

Pierwsze zabezpieczenia zostały wdrożone w ciągu kilkudziesięciu godzin poprzez zablokowanie podatnego punktu wejścia w Gremlin API. Następnie Microsoft przygotował znacznie większą przebudowę architektury usługi, całkowicie eliminując mechanizm platformowego klucza oraz wprowadzając dodatkowe zabezpieczenia izolujące poszczególnych klientów.

Pełne wdrożenie zmian zakończyło się w lipcu 2026 roku, a publiczne ujawnienie podatności nastąpiło dopiero po zakończeniu procesu naprawy. Microsoft podkreślił, że analiza logów nie wykazała żadnych oznak wykorzystania podatności poza badaniami prowadzonymi przez Wiz i że klienci nie muszą wykonywać dodatkowych działań.

Dlaczego takie podatności są wyjątkowo groźne?

Większość błędów bezpieczeństwa dotyczy pojedynczej aplikacji lub jednego serwera. Tutaj sytuacja wyglądała zupełnie inaczej.

CosmosEscape uderzał w samą warstwę infrastruktury chmurowej, obsługującą tysiące klientów jednocześnie. Oznacza to, że pojedynczy błąd mógł potencjalnie doprowadzić do naruszenia granic pomiędzy tenantami – jednego z najważniejszych mechanizmów bezpieczeństwa środowisk multi-tenant.

To właśnie dlatego tego typu podatności należą do najcenniejszych znalezisk dla badaczy bezpieczeństwa i jednocześnie do najbardziej niebezpiecznych z punktu widzenia dostawców usług chmurowych.

Jak organizacje mogą ograniczać ryzyko?

Choć w tym przypadku klienci nie musieli instalować żadnych poprawek, incydent pokazuje, że bezpieczeństwo chmury nie kończy się na odpowiedniej konfiguracji własnych zasobów.

Warto monitorować operacje wykonywane z wykorzystaniem kluczy dostępowych, ograniczać ich użycie tam, gdzie to możliwe, oraz stopniowo przechodzić na uwierzytelnianie oparte o Microsoft Entra ID i mechanizmy zarządzania tożsamością – zamiast statycznych kluczy API.

Dobrą praktyką jest również monitorowanie nietypowych operacji odczytu danych, zmian uprawnień oraz masowego pobierania informacji z baz danych. Nawet jeśli podatność została usunięta po stronie dostawcy chmury, szybkie wykrycie anomalii nadal pozostaje jednym z najważniejszych elementów obrony.

Podsumowanie

CosmosEscape pokazuje, że największe zagrożenia dla środowisk chmurowych coraz częściej wynikają nie z błędów klientów, lecz z podatności w samej infrastrukturze dostawcy.

Choć Microsoft skutecznie usunął problem i nie znaleziono dowodów na jego wykorzystanie przez cyberprzestępców, przypadek ten przypomina, jak ogromne znaczenie ma właściwa izolacja usług współdzielonych. Jeden nadmiernie uprzywilejowany komponent może stać się punktem wyjścia do ataku o skali obejmującej tysiące organizacji jednocześnie.