Wprowadzenie do problemu / definicja
Dell udostępnił poprawki bezpieczeństwa dla pakietu Container Storage Modules (CSM), eliminujące zestaw krytycznych podatności w komponentach odpowiedzialnych za autoryzację, integrację pamięci masowej oraz operacje w środowiskach Kubernetes. Luki dotyczą mechanizmów uwierzytelniania, zarządzania uprawnieniami i obsługi tokenów, co w praktyce może prowadzić do przejęcia warstwy autoryzacji, ujawnienia poświadczeń backendów storage, a choćby uzyskania uprawnień root na węzłach klastra.
Problem jest szczególnie istotny dla organizacji wykorzystujących Dell CSM jako warstwę pośredniczącą między orkiestracją kontenerów a infrastrukturą pamięci masowej. Tego typu komponenty zwykle działają z szerokimi uprawnieniami, dlatego ich kompromitacja może gwałtownie przełożyć się na utratę kontroli nad klastrem i powiązanymi zasobami storage.
W skrócie
Najpoważniejsze błędy otrzymały ocenę CVSS sięgającą 10.0. Obejmują one brak uwierzytelniania dla funkcji krytycznych, użycie zakodowanych na stałe poświadczeń, możliwość fałszowania tokenów JWT oraz błędy eskalacji uprawnień.
- atakujący może uzyskać administracyjny dostęp do usług CSM Authorization,
- możliwe jest pozyskanie poświadczeń administratora backendów storage,
- część luk pozwala obejść mechanizmy kontroli dostępu między tenantami,
- w najgorszym scenariuszu dochodzi do uzyskania uprawnień root na węzłach Kubernetes,
- według producenta zagrożone są wersje wcześniejsze niż 1.17.0, a poprawki udostępniono w wydaniu 1.18.0.
Dell wskazuje, iż poza aktualizacją nie ma skutecznych obejść, które w pełni ograniczałyby ryzyko.
Kontekst / historia
Dell Container Storage Modules to zestaw rozszerzeń dla platform kontenerowych, umożliwiających integrację Kubernetes z systemami pamięci masowej producenta. W nowoczesnych środowiskach chmurowych i hybrydowych moduły te odpowiadają za zadania wymagające wysokiego poziomu zaufania, takie jak autoryzacja operacji na wolumenach, zarządzanie politykami dostępu czy komunikacja z macierzami storage.
To właśnie architektura i zakres uprawnień sprawiają, iż podatności w CSM są tak niebezpieczne. Błędy nie ograniczają się do pojedynczego kontenera ani jednej aplikacji, ale mogą wpływać na granice tenantów, polityki RBAC, sekrety klastra oraz poświadczenia administracyjne do zaplecza storage. W omawianym przypadku producent opisał kilka odrębnych błędów, które razem tworzą bardzo szeroką i krytyczną powierzchnię ataku.
Analiza techniczna
Jedną z najpoważniejszych luk jest CVE-2026-63688, dotycząca braku uwierzytelniania w serwerze gRPC komponentu csm-authorization-storage. Podatność pozwala zdalnemu, nieuwierzytelnionemu napastnikowi uzyskać nieuprawniony dostęp do poświadczeń administratora backendu storage dla wszystkich zarejestrowanych macierzy. Taki dostęp umożliwia obejście modelu bezpieczeństwa CSM Authorization i otwiera drogę do przejęcia kontroli nad warstwą pamięci masowej.
Kolejna krytyczna podatność, CVE-2026-63692, obejmuje authorization proxy oraz tenant service. Również tutaj problem wynika z braku odpowiedniego uwierzytelniania dla funkcji krytycznych, co pozwala ominąć mechanizmy kontroli dostępu i uzyskać uprawnienia administracyjne. W środowiskach wielodostępnych może to prowadzić do manipulacji zasobami storage ponad granicami tenantów.
Bardzo groźna jest także CVE-2026-67269 w operatorze CSM. Luka wynika z nieprawidłowego zarządzania uprawnieniami w reconcilerze zasobu ContainerStorageModule Custom Resource. Atakujący posiadający niskie uprawnienia może wykorzystać ją do eskalacji przywilejów i uzyskania dostępu root na węzłach klastra. Według opisu producenta kompromitacja wszystkich węzłów może nastąpić poprzez pojedyncze przesłanie odpowiednio przygotowanego custom resource.
Na warstwę tożsamości i tokenów wpływają również CVE-2026-54472 oraz CVE-2026-61421. Pierwsza z nich wynika z użycia hard-coded credentials w module CSM Authorization, co umożliwia generowanie poprawnych kryptograficznie tokenów administracyjnych. Druga dotyczy zakodowanego na stałe klucza kryptograficznego w komponencie JWT powiązanym z karavi-authorization. o ile środowisko zostało wdrożone zgodnie z wcześniejszą dokumentacją i nie przeprowadzono zmiany sekretu podpisującego, atakujący znający ujawniony sekret może samodzielnie fałszować tokeny i uzyskać uprawnienia administratora.
Istotna pozostaje również CVE-2026-67273, związana z nieprawidłową neutralizacją specjalnych elementów w silniku szablonów. Luka może prowadzić do eskalacji uprawnień, ujawnienia danych oraz nieautoryzowanych zmian w RBAC. Producent wskazuje, iż skuteczny atak może umożliwić odczyt sekretów Kubernetes w całym klastrze oraz tworzenie zasobów RBAC o zakresie klastrowym.
Konsekwencje / ryzyko
Ryzyko dla organizacji korzystających z Dell CSM należy ocenić jako krytyczne. Część podatności nie wymaga uwierzytelnienia, co znacząco obniża próg wejścia dla atakującego. Dodatkowo luki dotyczą komponentów kontrolujących dostęp do storage i integrację z Kubernetes, czyli warstw o bardzo wysokim poziomie zaufania.
- przejęcie administracyjnej kontroli nad usługą autoryzacji CSM,
- dostęp do poświadczeń backendów storage,
- fałszowanie tokenów JWT i trwałe obchodzenie uwierzytelniania,
- modyfikację polityk dostępu między tenantami,
- odczyt sekretów Kubernetes w skali całego klastra,
- tworzenie lub modyfikowanie zasobów RBAC,
- uzyskanie uprawnień root na węzłach Kubernetes,
- pełną kompromitację klastra oraz podłączonej infrastruktury storage.
W praktyce oznacza to ryzyko utraty poufności danych, naruszenia integralności wolumenów, zakłócenia ciągłości działania oraz możliwość trwałego utrzymania dostępu przez napastnika. W skrajnym scenariuszu podatności mogą zostać wykorzystane jako element ataku ransomware na poziomie infrastruktury.
Rekomendacje
Organizacje korzystające z Dell Container Storage Modules powinny pilnie zidentyfikować wszystkie klastry i komponenty, w których wdrożono CSM Authorization, CSM Operator oraz usługi powiązane z karavi-authorization. Następnie należy przeprowadzić aktualizację do wersji wskazanej przez producenta jako naprawiającej problem.
- zaktualizować wszystkie instancje Dell CSM do wersji naprawionej,
- założyć, iż wcześniejsze sekrety JWT mogły zostać ujawnione, i przeprowadzić ich rotację,
- skontrolować konfiguracje proxy, tenant service i komponentów gRPC,
- przejrzeć logi pod kątem nietypowych operacji administracyjnych, tworzenia custom resources i zmian RBAC,
- zweryfikować, czy nie doszło do nieautoryzowanego dostępu do Kubernetes Secrets,
- przeprowadzić audyt kont uprzywilejowanych i tokenów serwisowych,
- ograniczyć ekspozycję sieciową komponentów CSM wyłącznie do niezbędnych segmentów,
- rozważyć dodatkowe polityki admission control i walidację niestandardowych zasobów w klastrze,
- wdrożyć monitoring zdarzeń związanych z tworzeniem cluster-scoped RBAC resources oraz zmianami w storage policies.
Jeżeli środowisko korzystało z wcześniejszej dokumentacji zawierającej przykładowe sekrety lub konfiguracje testowe, takie wdrożenia należy traktować jako potencjalnie skompromitowane do czasu pełnej weryfikacji.
Podsumowanie
Zestaw podatności ujawnionych w Dell Container Storage Modules pokazuje, jak krytyczne dla bezpieczeństwa są komponenty łączące Kubernetes z infrastrukturą pamięci masowej. Połączenie braków w uwierzytelnianiu, błędów w obsłudze tokenów oraz nieprawidłowego zarządzania uprawnieniami tworzy scenariusz, w którym atakujący może przejść od braku dostępu do pełnej kontroli nad klastrem i warstwą storage.
Dla zespołów bezpieczeństwa oraz administratorów oznacza to konieczność natychmiastowej aktualizacji, rotacji sekretów oraz dokładnego przeglądu integralności całego środowiska. Zwłoka w reakcji może znacząco zwiększyć skalę skutków potencjalnego incydentu.