Krytyczna podatność Azure Cosmos DB mogła ujawnić klucz platformowy i narazić bazy wielu klientów - Security Bez Tabu

Krytyczna podatność Azure Cosmos DB mogła ujawnić klucz platformowy i narazić bazy wielu klientów

Cybersecurity news

Wprowadzenie do problemu / definicja

W lipcu 2026 roku ujawniono szczegóły poważnego łańcucha podatności w Azure Cosmos DB, który mógł umożliwić przełamanie izolacji środowiska Gremlin i uzyskanie dostępu do sekretu o zasięgu całej platformy. W praktyce oznaczało to ryzyko pobrania kluczy głównych wybranych kont oraz uzyskania szerokich uprawnień do danych wielu klientów.

To istotne rozróżnienie, ponieważ problem nie wynikał z błędnej konfiguracji po stronie użytkowników, lecz z architektury i wewnętrznych mechanizmów usługi chmurowej. Tego typu podatności są szczególnie groźne w środowiskach wielodzierżawczych, gdzie błąd w jednym komponencie może potencjalnie wpłynąć na wiele organizacji jednocześnie.

W skrócie

  • Łańcuch ataku nazwano CosmosEscape.
  • Punktem wejścia było spreparowane zapytanie do interfejsu Gremlin.
  • Badacze opisali możliwość ucieczki z sandboxa i zdalnego wykonania kodu.
  • Następnie możliwe miało być uzyskanie dostępu do sekretu podpisującego o szerokim zasięgu.
  • W efekcie atakujący mógł potencjalnie pobrać klucze główne wybranych kont Cosmos DB.
  • Microsoft zablokował podatny punkt wejścia w ciągu 48 godzin od zgłoszenia z listopada 2025 roku, a pełne poprawki wdrożono globalnie w lipcu 2026 roku.
  • Producent poinformował, że nie stwierdził oznak wpływu na klientów.

Kontekst / historia

Azure Cosmos DB to zarządzana, wielomodelowa usługa bazodanowa w chmurze, obsługująca różne interfejsy API, w tym NoSQL, MongoDB, Cassandra i Gremlin. Ze względów bezpieczeństwa szczególnie wrażliwym elementem są klucze główne kont, ponieważ zapewniają one bardzo szerokie uprawnienia do zasobów zapisanych w danym koncie.

Sprawa wpisuje się w szerszą historię incydentów związanych z bezpieczeństwem Cosmos DB. W 2021 roku głośna podatność ChaosDB również prowadziła do ryzyka pozyskania kluczy klientów, jednak dotyczyła innego komponentu, czyli funkcji Jupyter Notebook. Najnowszy przypadek jest technicznie odrębny i wskazuje na problem związany z wykonaniem zapytań Gremlin oraz zaufaniem do wewnętrznych granic bezpieczeństwa platformy.

Analiza techniczna

Z ujawnionych informacji wynika, że silnik Gremlin w Cosmos DB tłumaczył zapytania do kodu .NET uruchamianego w ograniczonym środowisku. Mechanizmy ochronne miały uniemożliwiać wykonywanie nieautoryzowanych operacji, jednak według badaczy restrykcje nie uwzględniały w wystarczającym stopniu możliwości refleksji .NET.

To z kolei miało pozwolić na zbudowanie prymitywów odczytu i zapisu plików, a następnie doprowadzić do zdalnego wykonania kodu. Po przejęciu możliwości wykonywania kodu atak przesuwał się do współdzielonego komponentu bramowego, który obsługuje ruch klientów i posiada uprawnienia niezbędne do pobierania kluczy głównych kont na potrzeby działania usługi.

Kluczowym elementem całego scenariusza był opisany przez badaczy sekret podpisujący o zasięgu platformowym, określany jako Cosmos Master Key. Taki sekret miał umożliwiać pobieranie kluczy głównych dowolnych kont w różnych tenantach, regionach i interfejsach API. Dodatkowo miał zapewniać dostęp do regionalnego magazynu konfiguracji zawierającego między innymi nazwy kont, identyfikatory subskrypcji i tenantów, ustawienia sieciowe oraz tagi.

Z perspektywy bezpieczeństwa architektury chmurowej oznacza to, że kompromitacja pośredniczącej warstwy usługowej mogła nie dawać bezpośredniego dostępu do samych danych, ale umożliwiać pozyskanie materiału uwierzytelniającego, który taki dostęp otwierał. To klasyczny przykład sytuacji, w której zabezpieczenia perymetryczne tracą znaczenie po przejęciu zaufanej warstwy control plane lub data plane.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem takiej podatności byłaby możliwość przejęcia klucza głównego wybranego konta Cosmos DB. W praktyce dawałoby to pełne uprawnienia do odczytu, zapisu, modyfikacji i usuwania danych, a także możliwość utrzymania dostępu do czasu rotacji poświadczeń.

W środowiskach produkcyjnych skutki mogłyby obejmować naruszenie poufności danych, sabotaż operacyjny, manipulację rekordami biznesowymi oraz utratę integralności systemów zależnych od tych baz. Szczególnie poważny był międzydzierżawczy charakter ryzyka, ponieważ atakujący mógł teoretycznie przejść z kontrolowanego przez siebie konta do współdzielonej infrastruktury, a stamtąd do zasobów innych klientów.

Dodatkowym problemem pozostaje wykrywalność. Jeżeli pobranie klucza następowałoby przez wewnętrzny komponent platformy, standardowe mechanizmy monitoringu po stronie klienta mogłyby nie zapewniać pełnego obrazu zdarzeń. To znacząco utrudnia analizę po incydencie i ocenę, czy doszło do nadużycia legalnie wyglądających poświadczeń.

Rekomendacje

Organizacje korzystające z Azure Cosmos DB powinny potraktować ten przypadek jako ważny sygnał ostrzegawczy i ograniczać zależność od długowiecznych kluczy głównych. Tam, gdzie to możliwe, warto preferować mechanizmy kontroli dostępu oparte na tożsamości i rolach, a użycie kluczy konta sprowadzać do minimum operacyjnego.

  • Regularnie rotować klucze primary i secondary.
  • Zweryfikować, które aplikacje i integracje korzystają z kluczy konta.
  • Ograniczać stosowanie nadmiernie uprzywilejowanych poświadczeń.
  • Monitorować nietypowe wzorce dostępu, skoki liczby operacji i zmiany konfiguracji.
  • Korelować logi aplikacyjne, telemetrię sieciową i zdarzenia administracyjne.
  • Utrzymywać aktualny rejestr zasobów korzystających z Cosmos DB.
  • Stosować zasadę defense in depth, w tym segmentację, prywatne endpointy i minimalne uprawnienia.

Nawet jeśli dostawca poinformował o braku konieczności działań po stronie klientów, rotacja kluczy pozostaje jedną z najskuteczniejszych metod ograniczania skutków potencjalnego historycznego wycieku poświadczeń. W środowiskach o podwyższonych wymaganiach bezpieczeństwa warto dodatkowo przeglądać klasyfikację danych przechowywanych w kontach Cosmos DB i plany reagowania na incydenty.

Podsumowanie

CosmosEscape pokazuje, jak lokalny z pozoru błąd w mechanizmie wykonywania zapytań może przerodzić się w scenariusz prowadzący do kompromitacji warstwy pośredniczącej i dostępu do kluczowych poświadczeń klientów. Najważniejszy wniosek ma charakter architektoniczny: bezpieczeństwo usług chmurowych zależy nie tylko od izolacji tenantów, ale również od ścisłego ograniczania zaufania do komponentów wewnętrznych i eliminacji sekretów o zbyt szerokim zasięgu.

Choć poprawki zostały wdrożone, przypadek ten przypomina, że organizacje powinny zakładać możliwość awarii mechanizmów bezpieczeństwa po stronie dostawcy i budować własne warstwy ograniczania skutków. W praktyce oznacza to lepszą kontrolę poświadczeń, silniejszy monitoring i architekturę odporną na kompromitację pojedynczej warstwy usługi.

Źródła