Ceph: cztery luki łamią zaufanie do CephX, STS, Monitora i SigV4

Cztery rekordy CVE opublikowane 28 sierpnia opisują odrębne sposoby przejścia z ograniczonego dostępu do szerokich uprawnień w Ceph. CVE-2025-30156 dotyczy podatnego mechanizmu kryptograficznego CephX, CVE-2026-39944 — modyfikowalnych tokenów sesyjnych STS w RADOS Gateway, CVE-2026-50152 — nieuprawnionego odczytu magazynu config-key Monitora, a CVE-2026-54330 — dodatkowych, niepodpisanych nagłówków x-amz-* w żądaniach SigV4.

Wszystkie cztery problemy naprawiono w wydaniach Ceph 20.2.4 i 19.2.6. Biuletyny projektu są datowane na 19 sierpnia; dzisiejszą nowością jest publikacja spójnych rekordów CVE w katalogach. To ważne operacyjnie: systemy, które nie zareagowały na mailing producenta, mogą dopiero teraz utworzyć zgłoszenia na podstawie identyfikatorów CVE.

Wspólny motyw jest szerszy niż Ceph. Poufność bez integralności nie chroni poświadczenia, podpis obejmujący tylko część żądania nie autoryzuje całości, a uprawnienie do czytania statusu Monitora nie powinno automatycznie otwierać magazynu sekretów. Każdy przypadek pokazuje inną wersję zasady: decyzja bezpieczeństwa musi obejmować cały obiekt i cały kontekst, który później wykorzysta system.

CVE-2025-30156: CephX szyfruje, ale nie uwierzytelnia danych

CephX używał AES-128-CBC bez kodu uwierzytelniającego wiadomość i ze stałym wektorem inicjalizującym. Szyfrowanie mogło ukrywać tekst jawny, ale nie wykrywało modyfikacji szyfrogramu. W trybie CBC kontrolowana zmiana bloku może przewidywalnie zmienić fragment danych po odszyfrowaniu. Jeżeli protokół nie sprawdza integralności, odbiorca może potraktować zmienione dane jako autentyczne.

Advisory opisuje dwa mechanizmy eskalacji. W pierwszym atakujący ma skompromitowany klucz o niskich uprawnieniach i możliwość obserwowania ruchu CephX. Monitor może następnie działać jak oracle szyfrujący wybrane nazwy encji. Bloki szyfrogramu można łączyć w poświadczenia uprzywilejowanych komponentów, takich jak Manager, MDS lub OSD. W drugim wariancie użytkownik z uprawnieniami CephX modyfikuje pojedynczy bit biletu usługi tak, aby pole allow_all stało się prawdziwe.

Wynik biuletynu to CVSS 3.1: 8,9 (High). To nie jest atak bez żadnego punktu zaczepienia: wymaga klucza lub dostępu do biletu, a w pierwszym wariancie także pozycji pozwalającej obserwować szyfrogramy. Skutek może jednak objąć cały klaster, ponieważ sfałszowana tożsamość daemona przekracza pierwotny zakres konta klienta.

CVE-2026-39944: ten sam problem kryptograficzny w tokenie RGW STS

RADOS Gateway używał tego samego nieuwierzytelnionego mechanizmu AES-CBC do ochrony tokenów sesyjnych STS. Atakujący posiadający dowolny ważny token mógł zmienić szyfrogram bez wykrycia i wpłynąć na pola acct_type, perm_type oraz is_admin. Ustawienie wartości administracyjnej uruchamiało globalne obejście kontroli capabilities w RGW.

Różnica względem CephX ma znaczenie dla priorytetu. Ten wariant jest osiągalny przez endpoint S3, gdy STS jest włączony. Nie wymaga obserwowania wewnętrznej sieci ani korzystania z Monitora jako oracle. Punktem startowym jest legalny, nawet nieuprzywilejowany token STS. GitHub ocenia lukę na 8,5 (High) w CVSS 3.1.

To dobry przykład, dlaczego „token jest zaszyfrowany” nie jest wystarczającym wymaganiem. Poświadczenie przenosi decyzje autoryzacyjne, więc musi być także odporne na modyfikację. Współczesny projekt powinien używać uwierzytelnionego szyfrowania albo osobnego, poprawnie związanego MAC i odrzucać token przed interpretacją pól, jeżeli integralność nie została potwierdzona.

CVE-2026-50152: mon allow r otwiera magazyn sekretów

Trzecia luka nie jest kryptograficzna. Handler subskrypcji Monitora nie sprawdzał poprawnie uprawnienia do magazynu config-key. Użytkownik CephX z capability mon allow r mógł odczytać całą zawartość za pomocą wiadomości subskrypcji.

Magazyn może zawierać hasła LUKS używane przez OSD, a w klastrach zarządzanych przez cephadm także prywatny klucz SSH do łączenia się ze wszystkimi hostami. Przy domyślnej konfiguracji cephadm ten klucz prowadzi do dostępu root. Ograniczone konto obserwacyjne staje się więc drogą do kompromitacji danych, warstwy zarządzania i systemów operacyjnych węzłów.

Advisory przyznaje CVSS 3.1: 8,2 (High) i wymaga skompromitowanego konta z mon allow r oraz dostępu do sieci klastra. Administrator nie powinien wnioskować, że konto „tylko do odczytu” jest z definicji nieszkodliwe. W systemie rozproszonym zakres odczytu ma znaczenie: odczyt stanu to inna klasa niż odczyt sekretów pozwalających zmienić cały stan.

CVE-2026-54330: podpis SigV4 nie obejmuje wszystkich nagłówków

W prawidłowym żądaniu AWS Signature Version 4 lista X-Amz-SignedHeaders określa podpisane nagłówki, ale serwer powinien również odrzucić dodatkowe nagłówki x-amz-*, które wpływają na semantykę operacji, a nie zostały podpisane. Ceph RGW weryfikował wymieniony zestaw i nie odrzucał dodatkowych nagłówków tej rodziny.

Posiadacz presigned URL do operacji PUT mógł zatem dołączyć niepodpisane informacje, które RGW honorował. Podpis pozostawał matematycznie poprawny dla pierwotnego zestawu, lecz faktyczne żądanie wykonywane przez serwer miało szerszą semantykę niż intencja wystawcy adresu. Advisory podaje CVSS 3.1: 8,2 (High).

To nie oznacza, że każdy presigned URL ujawnia cały bucket. Warunkiem jest adres do zapisu i możliwość dodania odpowiednich nagłówków. Lekcja architektoniczna jest jednak jednoznaczna: weryfikator nie może pozwalać, aby niepodpisane pole zmieniało autoryzowany skutek. Canonical request musi obejmować wszystkie security-sensitive elementy albo jawnie je blokować.

Które klastry są dotknięte

Projekt oznacza jako podatne wydania wcześniejsze niż 20.2.4 i 19.2.6. Organizacje korzystające z dystrybucji Red Hat, IBM, OpenShift Data Foundation albo CLYSO powinny mapować wersję produktu na faktyczny build Ceph i korzystać z backportu dostawcy. Sam numer platformy nadrzędnej nie wystarcza.

Ekspozycję trzeba oceniać osobno. Dla CephX zinwentaryzuj klucze klientów, segmentację sieci messenger i możliwość przechwycenia ruchu. Dla STS sprawdź, czy funkcja jest włączona oraz kto może uzyskać token. Dla config-key ustal, komu przyznano mon allow r i jakie sekrety znajdują się w magazynie. Dla SigV4 wyszukaj systemy generujące presigned PUT URL i rodzaje nagłówków dozwolonych przez bramy, proxy oraz SDK.

Aktualizacja i bezpieczna kolejność działań

Najpierw przygotuj kontrolowany upgrade do 20.2.4 lub 19.2.6 albo odpowiadającego im wydania dostawcy. Sprawdź quorum Monitorów, stan PG, zdrowie OSD, kompatybilność klientów i ścieżkę cofnięcia. W klastrze przechowującym krytyczne dane nie należy aktualizować wszystkich węzłów jednocześnie bez potwierdzonego planu utrzymania dostępności.

Po instalacji poprawki oceń konieczność rotacji materiału uwierzytelniającego. Rotacja jest szczególnie uzasadniona, jeśli niezaufane konto miało mon allow r, STS było dostępne dla szerszego grona lub wykryto anomalie. Obejmuje to klucze CephX, klucz SSH cephadm, tokeny i potencjalnie hasła LUKS. Kolejność musi uwzględniać zależności: przed unieważnieniem starego klucza zarządzającego trzeba zapewnić działanie nowego kanału administracyjnego.

Nie wystarczy wyczyścić aktywne sesje RGW. Jeżeli atakujący uzyskał trwałe uprawnienia, zmienił użytkowników, capabilities, polityki bucketów lub obiekty, stan trzeba odtworzyć z dzienników i porównać z zatwierdzonym baseline’em.

Detekcja i przygotowanie do incydentu

Dla CephX szukaj nietypowych nazw encji, częstych żądań biletów, nowych klientów i użycia tożsamości daemonów z nieoczekiwanych adresów. Dla RGW koreluj wystawienie tokenu STS z późniejszymi operacjami administracyjnymi. Legalny token o małym zakresie nie powinien nagle wykonywać globalnych akcji.

Dla Monitora istotne są subskrypcje i odczyty config-key wykonywane przez konta z mon allow r, zwłaszcza jeśli nie korzystały wcześniej z tych wiadomości. Dla SigV4 loguj zarówno listę podpisanych nagłówków, jak i faktyczne nagłówki x-amz-*. Różnica pomiędzy zestawami jest silnym sygnałem do zbadania, choć proxy może wymagać odpowiedniego poziomu telemetrii.

W analizie zachowaj mapowanie encji na klucze, audyt capabilities, logi Monitora i RGW, informacje o wystawieniu STS oraz historię polityk. Nie publikuj pełnych tokenów ani sekretów w centralnym SIEM. Do korelacji wystarczą bezpieczne identyfikatory i hashe.

Fakty źródłowe i wnioski Breachroad

Opisy mechanizmów, warunków, ocen CVSS i wersji naprawczych pochodzą z biuletynów projektu Ceph oraz rekordów CVE. Rekomendacje dotyczące kolejności rotacji, korelacji telemetrii i osobnej oceny czterech ścieżek są wnioskami obronnymi Breachroad. Publiczne źródła nie stwierdzają aktywnego wykorzystania tych luk w konkretnym incydencie, więc obecność podatnej wersji jest ekspozycją, a nie dowodem włamania.

Źródła pierwotne

• GHSA-7q3q-3975-qw3q — AES-CBC w CephX
• GHSA-j73r-qrgx-jvq2 — tokeny RGW STS
• GHSA-rg9p-5xcp-wm8h — magazyn config-key Monitora
• GHSA-rmjq-ffrm-j6vj — niepodpisane nagłówki SigV4
• Ceph 20.2.4
• Ceph 19.2.6

Takie luki powstają na granicy kryptografii, protokołu i modelu uprawnień. Na szkoleniu z cyberbezpieczeństwa dla zespołów technicznych uczymy, jak testować integralność tokenów i zakres autoryzacji w systemach rozproszonych. Jeżeli potrzebujesz weryfikacji rzeczywistej ekspozycji, testy penetracyjne aplikacji i API mogą objąć bramy S3, federację tożsamości i ścieżki administracyjne w uzgodnionym zakresie.