Podatności OpenStack Keystone

W OpenStack Keystone przed wersją 29.0.3 tokeny uzyskane przez delegowane metody uwierzytelniania (poświadczenia EC2, poświadczenia aplikacji, tokeny dostępu OAuth1 i zaufania) nie są blokowane przed tworzeniem, modyfikowaniem i usuwaniem poświadczeń przez API /v3/credentials. Tokeny pochodne EC2 mogą dodatkowo odczytywać bloby poświadczeń, ujawniając ziarna TOTP MFA i inne sekrety. Ponadto PATCH /v3/credentials nie waliduje żądanego project_id po aktualizacji, co pozwala dowolnemu delegowanemu tokenowi przenieść poświadczenie do nieautoryzowanego projektu.

W OpenStack Keystone przed wersją 29.0.3, każdy uwierzytelniony użytkownik z rolą reader na dowolnym projekcie może wyświetlić wszystkie przypisania ról w obrębie dowolnej domeny, przekazując ID domeny jako scope.project.id z parametrem include_subtree do punktu końcowego GET /v3/role_assignments. Rekord projektu domeny ma pole domain_id=null, co powoduje, że sprawdzenie polityki domain_id przechodzi dla każdego wywołującego. Z include_names odpowiedź ujawnia nazwy i ID domen macierzystych wszystkich użytkowników, grup, projektów i ról. Atakujący może zbierać ID domen i powtarzać zapytania, aby zmapować przypisania ról w całej chmurze.

W OpenStack Keystone przed wersją 29.0.3 tokeny uzyskane za pomocą delegowanych mechanizmów uwierzytelniania (tokeny dostępu OAuth1, poświadczenia aplikacji, zaufania) mogły być przesyłane do ścieżki uwierzytelniania metodą tokena w celu ponownego uwierzytelnienia, aby uciec od zamierzonego zakresu projektu. Gdy token poświadczeń aplikacji został przedstawiony bez jawnego zakresu, Keystone wydawał nowy token o zakresie domyślnego projektu właściciela poświadczeń, a nie projektu, dla którego poświadczenie zostało wydane, omijając zamierzoną granicę projektu. Wszystkie wdrożenia Keystone, które zezwalają na delegowane uwierzytelnianie przez tokeny dostępu OAuth1, poświadczenia aplikacji lub zaufania, są dotknięte.

W OpenStack Keystone przed wersją 29.0.3 tokeny uzyskane za pomocą tokena dostępu OAuth1, poświadczeń aplikacji lub uwierzytelniania z zakresem zaufania mogły tworzyć nowe długotrwałe poświadczenia lub autoryzować nowe delegacje, które utrzymują się niezależnie od poświadczenia użytego do ich uzyskania i go przeżywają. Ograniczenia delegacji, które blokują te operacje, nie były spójnie stosowane do wszystkich typów tokenów delegowanych, co pozwalało na przykład tokenowi z zakresem OAuth1 na tworzenie poświadczeń aplikacji lub autoryzację tokenów żądań OAuth1, mimo że te operacje były ograniczone dla innych typów tokenów delegowanych. Wszystkie wdrożenia Keystone, które zezwalają na delegowane uwierzytelnianie przez tokeny dostępu OAuth1, poświadczenia aplikacji lub zaufania, są dotknięte.

W OpenStack Keystone przed wersją 29.0.2 wykryto podatność, która w połączeniu z eskalacją uprawnień przez poświadczenia aplikacji pozwala atakującemu z rolą member na projekcie na eskalację do admina. Atakujący tworzy nieograniczone poświadczenia aplikacji i łączy je z trustami Keystone, podszywając się pod ofiarę i przejmując jej rolę admina.

W OpenStack Keystone przed wersją 29.0.2, mechanizm wymuszania polityk RBAC w funkcji enforce_call bezwarunkowo scala surowe JSONowe ciało żądania do słownika wymuszania polityk za pomocą policy_dict.update(json_input.copy()), nadpisując zaufane dane docelowe ustawione wcześniej z zapytań do bazy danych. Ponieważ flask.request.get_json jest wywoływane z force=True, działa to niezależnie od Content-Type lub metody HTTP. Każdy uwierzytelniony użytkownik może wstrzyknąć dowolne atrybuty docelowe polityki (np. user_id, project_id) do ciała żądania, aby ominąć kontrole RBAC i wykonać nieautoryzowane operacje na zasobach należących do innych użytkowników lub projektów. Podatność została wprowadzona w commicie 5ea59f52 (Rocky/14.0.0).

W OpenStack Keystone przed wersją 29.0.2 brak walidacji projektu w żądaniu POST /v3/credentials dla poświadczeń EC2. Atakujący z nieograniczonym poświadczeniem aplikacji dla projektu A mógł utworzyć poświadczenie EC2 dla projektu B, a następnie wymienić je na token Keystone dla projektu B, zachowując oryginalne ID poświadczenia aplikacji.

W OpenStack Keystone przed wersją 28.0.1, backend tożsamości LDAP nie konwertuje atrybutu enabled użytkownika na wartość logiczną, gdy opcja konfiguracyjna user_enabled_invert ma wartość False (domyślnie). Powoduje to, że użytkownicy wyłączeni w LDAP są traktowani jako włączeni przez Keystone, co pozwala im na uwierzytelnianie i wykonywanie działań.

W OpenStack Keystone stwierdzono podatność, która pozwala zdalnemu atakującemu wysłać duże żądanie HTTP z długą nazwą dzierżawcy (tenant name) podczas żądania tokena, co prowadzi do nadmiernego zużycia CPU i pamięci, powodując odmowę usługi (DoS).