OpenStack Keystone: delegowane tokeny mogły tworzyć trwałe poświadczenia i uciekać z projektu
OSSA-2026-037 opisuje CVE-2026-80182 i CVE-2026-80184: delegowane tokeny mogły rozszerzyć czas życia dostępu i przekroczyć zakres projektu.
- AUTOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLIKACJA
- 26 sierpnia 2026
- CZAS CZYTANIA
- 17 min czytania
- TEMAT
- Tożsamość i dostęp
OpenStack opublikował OSSA-2026-037 dla dwóch błędów w Keystone, które podważały ograniczenia delegowanych poświadczeń. CVE-2026-80182 pozwalało tokenowi uzyskanemu przez OAuth1 access token, application credential lub trust tworzyć nowe długowieczne poświadczenia albo kolejne delegacje. CVE-2026-80184 pozwalało przesłać delegowany token do ścieżki token-method authentication i w określonym przypadku uzyskać nowy token dla domyślnego projektu właściciela zamiast projektu, do którego pierwotnie ograniczono application credential.
Oba problemy mają CVSS 4.0 7,6 (High). Advisory OpenStack ukazało się 25 sierpnia, a rekordy CVE weszły do nocnego obiegu 26 sierpnia czasu polskiego. Poprawki są dostępne dla utrzymywanych gałęzi, a zakres dotyczy Keystone od 13.0.0 do wersji poprzedzających 27.0.3, 28.0.3 i 29.0.3. Administrator nie powinien wdrażać tylko połowy rozwiązania: projekt zaznacza, że dwa zestawy zmian są współzależne.
Co oznacza delegacja w Keystone
Keystone wydaje tokeny reprezentujące tożsamość, zakres i metody uwierzytelnienia w chmurze OpenStack. Użytkownik może przekazać aplikacji ograniczone uprawnienia przez application credential, ustanowić trust dla innego użytkownika lub korzystać z OAuth1. Celem jest uniknięcie udostępniania głównego hasła oraz zawężenie tego, co automatyzacja może zrobić i jak długo zachowuje dostęp.
Bezpieczna delegacja powinna być monotoniczna: pochodne poświadczenie nie może mieć szerszego zakresu, dłuższego niezależnego życia ani prawa do tworzenia kolejnych delegacji, jeżeli rodzic takiego prawa nie posiadał. W przeciwnym razie ograniczony token staje się trampoliną do trwałości. Atakujący nie musi łamać kryptografii ani fałszować podpisu; wykorzystuje dozwolone endpointy w kolejności, której polityka nie zablokowała.
Te luki nie są anonimowym obejściem logowania. CVSS wskazuje wymagane niskie uprawnienia i dodatkowy warunek ataku. Napastnik musi już posiadać ważne delegowane poświadczenie. Skutek jest jednak poważny, bo właśnie takie tokeny trafiają do narzędzi CI/CD, operatorów, skryptów i usług, którym organizacja świadomie ograniczyła zasięg.
CVE-2026-80182: ograniczony token tworzył następcę
Keystone miał blokować operacje, które pozwalają delegowanemu tokenowi tworzyć application credentials, zarządzać trustami lub autoryzować następny etap OAuth1. Kontrola nie była stosowana spójnie do wszystkich metod delegacji. Advisory podaje przykład tokenu o zakresie wynikającym z OAuth1, który mógł utworzyć application credential albo autoryzować OAuth1 request token.
Nowe poświadczenie mogło istnieć niezależnie i przeżyć token, z którego je utworzono. W praktyce psuje to czasową granicę incydentu. Administrator może unieważnić pierwotny trust lub zaczekać na wygaśnięcie krótkiego tokenu, ale utworzony wcześniej credential nadal zapewnia dostęp. Tożsamość, która miała tylko wykonać ograniczony job, zyskuje mechanizm zakotwiczenia.
Ocena ekspozycji wymaga odpowiedzi na dwa pytania: czy wdrożenie zezwala na OAuth1, application credentials lub trusts oraz czy delegowane tożsamości mają role pozwalające osiągnąć chronione endpointy. Samo wykrycie pakietu Keystone w SBOM nie wystarcza. Trzeba przejrzeć polityki, włączone metody i historię tworzenia poświadczeń.
CVE-2026-80184: reauthentication zmieniało projekt
Drugi błąd dotyczy ścieżki, w której istniejący token zostaje użyty jako metoda uwierzytelnienia do wydania kolejnego tokenu. Delegowane tokeny z OAuth1, application credential lub trust mogły wejść do token-method authentication. Gdy token application credential został przedstawiony bez jawnego zakresu, Keystone potrafił użyć domyślnego projektu właściciela.
Jeżeli credential utworzono dla projektu A, a konto właściciela ma domyślny projekt B, następny token mógł otrzymać zakres B. To jest ucieczka przez zmianę kontekstu, nie klasyczne podniesienie roli wewnątrz jednego projektu. Rzeczywisty skutek zależy od ról właściciela w projekcie domyślnym. W środowisku, gdzie B zawiera szersze zasoby lub uprawnienia administracyjne, naruszenie może przekroczyć zamierzoną granicę tenant’a.
Jawne podanie zakresu nie powinno być jedyną ochroną. Serwer musi wiedzieć, że metoda źródłowa jest delegowana i nie może być użyta do „odtworzenia” głównej tożsamości w innym scope. Poprawka centralizuje klasyfikację metod oraz wykorzystuje ją do blokowania wrażliwych operacji.
Zakres wersji i dwuczęściowa poprawka
OSSA wymienia następujące zakresy: Keystone >=13.0.0 i <27.0.3, >=28.0.0 i <28.0.3 oraz >=29.0.0 i <29.0.3. Zmiany przygotowano dla gałęzi 2025.1 Epoxy, 2025.2 Flamingo, 2026.1 Gazpacho i rozwojowej 2026.2 Hibiscus. Dystrybucje OpenStack mogą stosować backporty i własne numery pakietów, dlatego ocena powinna opierać się na advisory dostawcy oraz obecności konkretnych poprawek, nie wyłącznie numerze upstream.
Projekt wyraźnie stwierdza, że pary patchy są współzależne i muszą być zastosowane razem. Pierwsza część wprowadza klasyfikację delegacji oraz opcję [auth] additional_primary_auth_methods; druga opiera na tej informacji guard dla reauthentication i wrażliwych operacji. Wdrożenie tylko drugiej zmiany bez modelu klasyfikacji nie jest wspieraną kombinacją.
Po aktualizacji każda metoda uwierzytelniania niewbudowana w Keystone jest domyślnie traktowana jako delegowana. To bezpieczne fail-closed, ale ma skutek kompatybilnościowy. Jeśli chmura używa własnego lub zewnętrznego pluginu jako pierwotnej metody, administrator musi dodać go do additional_primary_auth_methods. W przeciwnym razie legalne przepływy zarządzania trustami, application credentials, OAuth1 i reauthentication zaczną być odrzucane.
Inwentaryzacja przed wdrożeniem
Zacznij od listy regionów i endpointów Keystone wraz z wersją pakietu, dostawcą dystrybucji i aktywnymi metodami auth. Zidentyfikuj OAuth1, trusts, application credentials, token-method authentication oraz wszystkie niestandardowe pluginy. W dużej chmurze konfiguracja może różnić się między control plane’ami, dlatego pojedynczy plik z repozytorium IaC nie jest dowodem stanu efektywnego.
Następnie zmapuj konta, których domyślny projekt różni się od zakresu używanych application credentials. Szczególnie ważne są konta automatyzacji o szerokich rolach w projekcie domyślnym. Przejrzyj też, które delegowane tożsamości mogły tworzyć credentials, trusts albo żądania OAuth1 i czy utworzyły takie obiekty w czasie ważności poświadczenia rodzica.
Przed restartem dodaj prawidłowe niestandardowe metody pierwotne do nowej konfiguracji i wykonaj testy negatywne. Nie wpisuj pluginu na listę tylko po to, by przywrócić działanie: potwierdź, że faktycznie ustanawia główną tożsamość, a nie kolejną formę delegacji. Błędna klasyfikacja odtworzy tę samą klasę problemu na lokalnym rozszerzeniu.
Detekcja i analiza historyczna
Dla CVE-2026-80182 szukaj tworzenia application credential, trust lub artefaktu OAuth1 przez token, którego lista metod wskazuje delegowane pochodzenie. Oś czasu powinna zawierać wydanie tokenu rodzica, utworzenie obiektu potomnego, wygaśnięcie lub unieważnienie rodzica oraz późniejsze użycie potomka. Szczególnie podejrzane jest użycie po zakończeniu zaplanowanego joba.
Dla CVE-2026-80184 koreluj reauthentication z brakiem jawnego scope i zmianą project_id między tokenem wejściowym i wyjściowym. Porównaj projekt application credential z domyślnym projektem użytkownika. Alarm powinien uwzględniać legalne odświeżenia i automatyzację, ale przekroczenie projektu przez delegowaną metodę jest sygnałem wysokiej jakości.
Jeśli potwierdzisz nadużycie, samo zablokowanie pierwotnego tokenu nie wystarczy. Unieważnij utworzone credentials, trusts i tokeny OAuth1, usuń nieautoryzowane delegacje, zmień poświadczenia osiągalnych kont usługowych oraz sprawdź działania w usługach Nova, Neutron, Cinder, Glance i Swift. Keystone powie, kto uzyskał token, ale skutek znajduje się w logach usług korzystających z tej tożsamości.
Testy regresji po aktualizacji
Przygotuj kontrolowaną macierz obejmującą główne hasło lub federację, application credential, trust, OAuth1 i każdy własny plugin. Dla każdej metody sprawdź wydanie tokenu z prawidłowym zakresem, próbę bez zakresu, zmianę projektu, tworzenie application credential, tworzenie trustu i autoryzację OAuth1. Delegowane metody powinny zostać odrzucone w chronionych operacjach, a prawidłowe primary methods muszą działać.
Obserwuj kody 401/403, logi klasyfikacji metody i błędy klientów automatyzacji. Canary w jednym regionie ogranicza ryzyko masowego przerwania CI/CD. Po potwierdzeniu kompatybilności wdrażaj kolejne control plane’y, a na końcu usuń tymczasowe wyjątki i porównaj konfigurację, aby uniknąć driftu.
Advisory zaznacza, że powiązana słabość obsługi EC2 credentials nie jest objęta OSSA-2026-037 i będzie opisana osobno jako OpenStack Security Note. Nie należy zatem uznawać aktualizacji za dowód, że każdy przepływ poświadczeń zgodnych z EC2 ma już tę samą ochronę.
Fakty źródłowe i wnioski Breachroad
Mechanizmy obu luk, zakres wersji, CVSS, lista gałęzi z patchami, wymóg zastosowania pary zmian, zachowanie additional_primary_auth_methods i wyłączenie sprawy EC2 pochodzą z OSSA-2026-037 oraz rekordów CVE. Źródła nie zgłaszają aktywnej eksploatacji. Proponowane zapytania detekcyjne, kolejność canary i analiza działań w usługach OpenStack są wnioskami Breachroad.
Szkolenia z bezpieczeństwa chmury i zarządzania tożsamością pomagają zespołom projektować bezpieczne delegacje, a audyty aplikacji i infrastruktury mogą zweryfikować skuteczny zakres tokenów, polityki Keystone i ścieżki automatyzacji.
