Podatności ZITADEL

ZITADEL to narzędzie infrastruktury tożsamości open-source. Wersje 4.7.0 i niższe są podatne na nieuwierzytelnioną podatność SSRF z pełnym odczytem. Interfejs logowania ZITADEL (V2) traktuje nagłówek x-zitadel-forward-host jako zaufany fallback dla wszystkich wdrożeń, w tym samodzielnie hostowanych instancji. Pozwala to nieuwierzytelnionemu atakującemu zmusić serwer do wykonywania żądań HTTP do dowolnych domen, takich jak adresy wewnętrzne, i odczytywania odpowiedzi, co umożliwia eksfiltrację danych i obejście kontroli segmentacji sieci. Problem został naprawiony w wersji 4.7.1.

ZITADEL to platforma open source do zarządzania tożsamością. Podatność w procesie federacji pozwala na automatyczne powiązanie użytkowników z zewnętrznych dostawców tożsamości (IdP) z istniejącymi kontami użytkowników, nawet jeśli dany IdP jest wyłączony lub organizacja nie zezwala na uwierzytelnianie federacyjne. Problem wynika z nieprawidłowego sprawdzania ustawień bezpieczeństwa organizacji podczas procesu logowania.

ZITADEL, open-source platforma zarządzania tożsamością, w wersjach od 3.0.0 do 3.4.13 oraz 4.16.1 zawiera podatność w Actions V1, która umożliwia korzystanie z rejestru require() kompatybilnego z Node.js (goja) bez ograniczenia ładowania plików z systemu plików. Autor akcji organizacji z uprawnieniami ORG_OWNER, org.action.write i org.flow.write może uruchamiać JavaScript w punktach wyzwalania OIDC, SAML i przepływu logowania oraz ładować pliki czytelne dla procesu serwera ZITADEL. Może to ujawnić zamontowaną konfigurację i sekrety, w tym poświadczenia przechowywane przez ZITADEL_FIRSTINSTANCE_LOGINCLIENTPATPATH lub ZITADEL_FIRSTINSTANCE_MACHINEKEYPATH, a odzyskane poświadczenia bootstrap mogą umożliwić eskalację z administratora organizacji do administratora instancji. Problem naprawiono w wersjach 3.4.13 i 4.16.1.

ZITADEL, open-source platforma zarządzania tożsamością, w wersjach od 4.0.0 do 4.16.1 zawiera podatność w Login V2, która tworzy sesję przeglądarki po weryfikacji hasła i może użyć tej sesji do późniejszego żądania uwierzytelnienia bez weryfikacji zarejestrowanego drugiego składnika TOTP, OTP lub U2F. Gdy krok MFA zostanie porzucony, a logowanie rozpocznie się ponownie, kontrole ważności sesji wymagają MFA tylko wtedy, gdy organizacja włączy Force MFA lub Force MFA tylko dla użytkowników lokalnych, więc dobrowolnie zarejestrowany czynnik może zostać pominięty podczas kończenia callbacku OIDC lub SAML dla aplikacji klienta. Login V1, ZITADEL Console, Management i Admin APIs oraz samoobsługa użytkownika nie są dotknięte. Problem naprawiono w wersji 4.16.1.

ZITADEL to otwartoźródłowa platforma zarządzania tożsamością. Przed wersją 4.16.0 błąd w aktualizacji uprawnień przy jednoczesnym usuwaniu wielu ról projektowych może powodować pominięcie niektórych uprawnień użytkownika. Problem dotyczy User Grants w Granted Projects (projektach współdzielonych między organizacjami) i może pozwolić użytkownikom zachować prawa dostępu, które powinny zostać całkowicie usunięte.

W ZITADEL od 2.43.0 do 2.71.19, od 3.0.0 do 3.4.11 i od 4.0.0 do 4.15.1, API do zarządzania e-mailem i telefonem pozwalało użytkownikom na żądanie zwróconych kodów weryfikacyjnych bez wymaganych uprawnień. Umożliwia to przejęcie adresów e-mail lub numerów telefonów innych użytkowników i ominięcie polityk bezpieczeństwa opartych na e-mailu lub telefonie.

Podatność w ZITADEL przed wersją 4.15.3 umożliwia wymianę tokena o niskich uprawnieniach na token z podwyższonymi uprawnieniami w innej aplikacji. Dzieje się tak, ponieważ punkt końcowy OAuth2 Token Exchange nie weryfikuje, czy token podmiotu należy do żądającego klienta ani czy żądane zakresy mieszczą się w zakresach oryginalnego tokena.

W ZITADEL przed wersją 4.15.3, w ścieżkach błędów logowania Login V2 OIDC i SAML, parametr loginSettings.defaultRedirectUri jest przekazywany do router.push bez walidacji isSafeRedirectUri. Umożliwia to administratorowi organizacji lub instancji przechowanie URI javascript lub data, który może zostać wykonany w przeglądarce użytkownika po trafieniu na podatną ścieżkę błędu logowania.

W ZITADEL przed wersją 4.15.3, procedura obsługi zewnętrznego dostawcy tożsamości (IdP) sprawdzała, czy e-mail lokalnego użytkownika jest zweryfikowany, ale nie weryfikowała, czy zewnętrzny IdP potwierdził posiadanie tego samego adresu e-mail przed automatycznym powiązaniem kont. Umożliwiało to atakującemu posiadającemu konto u zewnętrznego dostawcy z adresem e-mail ofiary powiązanie go z lokalnym kontem ofiary.

Podatność w ZITADEL (wersje 3.0.0-rc.1 do 3.4.11 oraz 4.0.0-rc.1 do 4.15.1) powoduje, że walidacja zewnętrznych tokenów JWT pomija sprawdzanie wygaśnięcia, gdy token nie zawiera pola exp. Token z zaufanego wystawcy jest traktowany jako ważny bez automatycznego terminu ważności.

W ZITADEL przed wersjami 3.4.12 i 4.15.2, walidacja zewnętrznego JWT Identity Provider pomija sprawdzenie maksymalnego wieku tokena, gdy brakuje w nim deklaracji iat. Umożliwia to uwierzytelnienie dowolnie starych tokenów od zaufanego wystawcy.

W ZITADEL przed wersjami 3.4.12 i 4.15.2, przepływy OAuth2 i OIDC (CodeExchange, RefreshToken, device token) nie weryfikują, czy żądający klient jest zgodny z klientem, który zainicjował przepływ autoryzacji. Umożliwia to wymianę przechwyconych grantów lub tokenów odświeżania pod innym klientem.

Podatność w ZITADEL od wersji 4.0.0-rc.1 do 4.15.1 umożliwia ataki SSRF poprzez niespójne walidowanie adresów URL w kanałach powiadomień HTTP, wylogowaniu OIDC BackChannel i pobieraniu metadanych SAML. Atakujący może wykorzystać DNS rebinding, przekierowania lub downgrade protokołu, aby wysłać żądania do pętli zwrotnej, wewnętrznych IP lub link-local.

W ZITADEL przed wersją 4.15.1 walidacja magazynu zdarzeń może zachować oryginalnego właściciela zasobu dla usuniętego identyfikatora użytkownika, co powoduje, że późniejszy użytkownik odtworzony z tym samym identyfikatorem w innej organizacji zostanie przypisany do oryginalnej organizacji i narażony na dostęp administratora tej organizacji. Problem został naprawiony w wersji 4.15.2.

ZITADEL, platforma do zarządzania tożsamością open source, przed wersjami 3.4.12 i 4.15.2 nie weryfikuje roszczenia aud (audience) w zewnętrznym JWT Identity Provider. Pozwala to na akceptację poprawnie podpisanego tokena od zaufanego wystawcy, ale przeznaczonego dla innej aplikacji.