Wprowadzenie do problemu / definicja
Azure Cosmos DB to zarządzana, wielomodelowa usługa bazodanowa w chmurze, zaprojektowana z myślą o wysokiej dostępności, globalnej replikacji i niskich opóźnieniach. W takich środowiskach szczególnie groźne są podatności naruszające izolację między tenantami, ponieważ pojedynczy błąd może potencjalnie wpłynąć na wielu klientów jednocześnie.
Opisana luka, nazwana CosmosEscape, dotyczyła mechanizmu wykonywania zapytań w interfejsie Gremlin. Według badaczy mogła ona umożliwić przełamanie ograniczeń środowiska wykonawczego, a następnie uzyskanie dostępu do kluczy głównych kont Cosmos DB, co w praktyce oznaczałoby pełną kontrolę nad danymi ofiary.
W skrócie
Badacze bezpieczeństwa ujawnili krytyczną podatność w Azure Cosmos DB, która mogła prowadzić do wykonania kodu w komponencie pośredniczącym w obsłudze zapytań Gremlin. W dalszym etapie możliwe miało być wykorzystanie wewnętrznego mechanizmu platformy do pobrania kluczy podstawowych klientów.
Taki scenariusz dawałby atakującemu możliwość pełnego odczytu i zapisu danych, a także enumeracji zasobów w skali całej usługi. Producent wdrożył działania ograniczające ryzyko, a następnie przeprowadził szerszą poprawę architektoniczną.
Kontekst / historia
Usługi wielodostępne od lat pozostają jednym z najbardziej wymagających obszarów bezpieczeństwa chmurowego. Każda luka pozwalająca ominąć granice między klientami jest traktowana jako incydent wysokiej wagi, ponieważ podważa podstawowe założenia modelu współdzielonej infrastruktury.
W przypadku CosmosEscape problem nie sprowadzał się do pojedynczego błędu aplikacyjnego. Z opisu badaczy wynika, że był to wieloetapowy łańcuch exploitacyjny obejmujący obejście sandboxa, wykonanie kodu, dostęp do wewnętrznych mechanizmów usługi oraz możliwość pobierania kluczy dostępowych klientów.
Znaczenie sprawy zwiększa fakt, że Cosmos DB jest wykorzystywana jako warstwa danych dla wielu aplikacji i usług krytycznych biznesowo. W efekcie podatność tej klasy mogłaby prowadzić do skutków wykraczających daleko poza pojedyncze konto czy region.
Analiza techniczna
Punktem wejścia miał być interfejs Gremlin API, używany do realizacji zapytań grafowych. Mechanizm ten opierał się na niestandardowym silniku kompilującym zapytania do kodu .NET wykonywanego w środowisku ograniczonym przez sandbox.
Problem polegał na tym, że zastosowane restrykcje nie uwzględniały w wystarczającym stopniu możliwości refleksji .NET. Badacze mieli wykorzystać tę właściwość do zbudowania prymitywów prowadzących do arbitralnego wykonania kodu, czyli wyjścia poza przewidziany model bezpiecznej obsługi zapytań.
Po uzyskaniu możliwości wykonania kodu celem stał się komponent DB Gateway, odpowiedzialny za obsługę żądań klientów. Według opisu to właśnie tam znajdował się mechanizm wykorzystujący wewnętrzny klucz podpisujący do pobierania kluczy podstawowych kont Cosmos DB.
Najbardziej niepokojący był szeroki zakres tego mechanizmu. Jeśli jeden klucz platformowy pozwalał pobierać primary key dla dowolnego konta, to lokalna podatność w ścieżce zapytań mogła zostać przekształcona w zagrożenie obejmujące wielu klientów jednocześnie.
Badacze wskazali również możliwość dostępu do magazynu konfiguracji zawierającego metadane o kontach, takie jak nazwy, identyfikatory subskrypcji i tenantów. Taki dostęp mógłby ułatwić precyzyjne wskazywanie celów oraz pobieranie odpowiadających im kluczy, co znacząco podnosiłoby skuteczność ataku ukierunkowanego.
- obejście sandboxa w ścieżce zapytań Gremlin,
- uzyskanie wykonania kodu w komponencie pośredniczącym,
- dostęp do mechanizmu pobierania kluczy klientów,
- możliwość enumeracji zasobów i przejęcia danych ofiary.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem potencjalnego wykorzystania CosmosEscape byłaby utrata poufności i integralności danych. Klucz podstawowy konta Cosmos DB daje bowiem bardzo szerokie uprawnienia, obejmujące pełny odczyt i zapis.
W praktyce oznacza to możliwość kradzieży danych, ich modyfikacji, usunięcia, a także przygotowania dalszych etapów ataku. Dodatkowym ryzykiem była możliwość enumeracji klientów i ich zasobów na dużą skalę, co zwiększa atrakcyjność podatności dla grup APT i aktorów prowadzących działania szpiegowskie.
Istotne jest również to, że taki scenariusz mógłby dotknąć środowisk uznawanych za lepiej chronione, w tym instancji prywatnych czy odizolowanych sieciowo. Jeśli wektor ataku rozpoczynał się od publicznie dostępnego endpointu usługi, tradycyjna izolacja sieciowa nie musiała stanowić skutecznej bariery ochronnej.
Rekomendacje
Organizacje korzystające z zarządzanych usług bazodanowych powinny traktować podobne przypadki jako sygnał do przeglądu własnego modelu zaufania wobec chmury. Nawet gdy dostawca deklaruje pełne wdrożenie poprawek, warto przeprowadzić własną ocenę ryzyka oraz analizę śladów operacyjnych.
- przeprowadzić przegląd logów dostępowych i operacyjnych dla instancji Cosmos DB,
- zweryfikować użycie kluczy, sekretów i nadmiarowych uprawnień aplikacyjnych,
- wdrożyć dodatkowe mechanizmy detekcji anomalii przy dostępie do danych,
- ograniczać blast radius poprzez segmentację logiczną i minimalizację uprawnień,
- przygotować procedury reagowania obejmujące rotację sekretów i ocenę integralności danych,
- regularnie analizować ryzyka cross-tenant w usługach PaaS.
Z perspektywy dostawców chmury incydent ten pokazuje, że bezpieczeństwo sandboxingu nie może być oceniane wyłącznie na poziomie funkcjonalnym. Konieczne jest modelowanie zagrożeń uwzględniające refleksję, dynamiczną kompilację i nadużycie mechanizmów wewnętrznych działających z uprawnieniami platformowymi.
Podsumowanie
CosmosEscape to przykład podatności o potencjalnie systemowym charakterze, w której problem nie ograniczał się do pojedynczego błędu w interfejsie API. Kluczowe znaczenie miał cały łańcuch prowadzący od publicznego punktu wejścia do możliwości przejęcia kluczy umożliwiających zarządzanie danymi klientów.
Najważniejsza lekcja płynąca z tej sprawy jest jasna: w środowiskach wielotenantowych krytyczna jest nie tylko izolacja wykonywania kodu, lecz także ścisła kontrola nad wewnętrznymi sekretami i ograniczenie ich zasięgu. Jeden zbyt uprzywilejowany mechanizm może zamienić lokalną lukę w zagrożenie obejmujące całą platformę.