Podatności ZITADEL

ZITADEL przed wersją 3.4.14 oraz 4.x przed 4.16.2 zawiera obejście uwierzytelniania w hostowanym interfejsie Login V1, ponieważ punkt końcowy rejestracji 'external account not found' ufa dostarczonym przez klienta polom tożsamości zewnętrznej bez ukończonego wywołania zwrotnego IdP. Nieuwierzytelnieni atakujący mogą przesłać sfałszowane wartości IDPConfigID i ExternalUserID, aby wstępnie utworzyć konto powiązane z tożsamością zewnętrznego IdP ofiary, do którego późniejsze autentyczne logowanie zewnętrzne ofiary uzyska dostęp.

ZITADEL 3.x przed 3.4.15 oraz 4.x przed 4.17.1 zawiera podatność nieprawidłowej autoryzacji: przy wydawaniu kodów rejestracji passkey lub logowania bez hasła sprawdza tylko organizację w nagłówku x-zitadel-orgid, a nie organizację docelowego użytkownika. Atakujący z uprawnieniami do zapisu użytkownika w jednej organizacji może uzyskać kod rejestracji dla użytkownika w innej organizacji w tej samej instancji i zarejestrować własny uwierzytelniacz, aby przejąć to konto.

ZITADEL 3.0.0 do 3.4.15 oraz 4.0.0 przed 4.17.3 tworzy powiązania między kontami użytkowników a zewnętrznymi dostawcami tożsamości bez weryfikacji czynnika podstawowego lub uprawnień wywołującego, w tym w sesjach Login V2 typu identify-only oraz przez punkt końcowy User Service V2 AddIDPLink. Nieuwierzytelniony atakujący znający login ofiary może powiązać własną tożsamość zewnętrznego IdP z kontem ofiary, a następnie zalogować się jako ofiara.

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.

Podatność w procesie federacji ZITADEL pozwalała na automatyczne powiązanie użytkownika z zewnętrznego dostawcy tożsamości z istniejącym kontem wewnętrznym, nawet gdy dany IdP był wyłączony lub organizacja nie zezwalała na uwierzytelnianie federacyjne. Wynikało to z nieegzekwowania polityk bezpieczeństwa organizacji podczas logowania. Wersje 2.71.19, 3.4.4 i 4.6.6 naprawiają problem poprzez prawidłową walidację polityki logowania przed automatycznym powiązaniem.

W wersjach Zitadel od 2.53.6, 2.54.3 i 2.55.0 wymagane było uwierzytelnianie wieloskładnikowe tylko wtedy, gdy polityka logowania miała włączone requireMFA lub requireMFAForLocalUsers. Jeśli użytkownik skonfigurował MFA bez tego wymogu, Zitadel uznawał sesje z pojedynczym składnikiem za ważne i nie wymagał wielu składników. Pominięcie drugiego składnika osłabia MFA i umożliwia atakującemu obejście bezpieczniejszego składnika, np. atak na sam kod TOTP (sześć cyfr) z pominięciem weryfikacji hasła. Podatność naprawiono w wersjach 4.6.0, 3.4.3 i 2.71.18.

Zitadel przed wersjami 4.6.0, 3.4.3 i 2.71.18 pozwala atakującemu na przeprowadzenie ataku brute-force online na OTP, TOTP i hasła. Mechanizm blokady konta, który może temu zapobiec, nie jest domyślnie włączony i może powodować odmowę usługi dla danego użytkownika, jeśli zostanie włączony. Ponadto strategie mitygacji nie zostały w pełni wdrożone w nowszych API opartych na zasobach.

ZITADEL w wersjach od 3.0.0 do 3.4.15 oraz od 4.0.0 przed 4.19.5 zawiera podatność braku autoryzacji w Login V2, która pozwala atakującym zatwierdzić autoryzacje urządzeń OAuth 2.0 przy użyciu istniejącej sesji ofiary bez jej zgody. Atakujący może wysłać zalogowanemu użytkownikowi link z własnym kodem użytkownika, aby uzyskać tokeny ofiary, oraz obejść ustawienia dostępu projektu przez API autoryzacji urządzeń OIDC.

ZITADEL w wersjach 4.0.0 przed 4.19.5 zawiera podatność obejścia uwierzytelniania w interfejsie Login V2, która pozwala nieuwierzytelnionym atakującym ustawić pierwsze poświadczenie użytkowników niemających żadnej metody uwierzytelniania. Atakujący może obliczyć ważny plik cookie verificationCheck na podstawie identyfikatora użytkownika i odcisku przeglądarki, aby ustawić hasło, zarejestrować passkey lub powiązać dostawcę tożsamości, przejmując konto.

W ZITADEL w wersjach od 4.0.0 do 4.19.5 występuje podatność na wstrzyknięcie nagłówka hosta w interfejsie Login V2. Nieuwierzytelniony atakujący może zatruć linki do resetowania hasła, zaproszeń i weryfikacji e-mail, dostarczając niezaufane nagłówki x-zitadel-public-host, x-zitadel-forward-host lub x-forwarded-host.

ZITADEL 3.0.0 przed 4.19.2 zawiera lukę pozwalającą na eskalację uprawnień w wymianie tokenów OIDC, która umożliwia podszywanie się pod administratorów, w tym IAM_OWNER, z pominięciem mechanizmów kontrolnych. Atakujący posiadający role IAM_END_USER_IMPERSONATOR lub ORG_END_USER_IMPERSONATOR mogą logować się do aplikacji polegających na tym systemie jako administratorzy.

ZITADEL 3.0.0 przed 4.19.2 zawiera podatność obejścia uwierzytelniania w interfejsie Login V2, która pozwala nieuwierzytelnionym atakującym na uzyskanie tokenów sesji innych użytkowników poprzez fałszowanie niepodpisanych ciasteczek sesji. Atakujący mogą odgadnąć uporządkowane czasowo identyfikatory sesji wokół logowania ofiary i dostarczyć je z pustymi tokenami, aby otrzymać rotowane tokeny, przejmując konta, w tym sesje administratorów z ukończonym MFA.

ZITADEL 4.x przed 4.19.2 oraz 3.x do 3.4.15 zawiera obejście uwierzytelniania w wywołaniu zwrotnym intencji dostawcy tożsamości SAML. Weryfikacja podpisu asercji odbywa się względem dostawcy wskazanego w URL, ale użytkownik jest rozwiązywany z intencji logowania bez sprawdzenia zgodności. Atakujący z uprawnieniami administratora organizacji może zarejestrować dostawcę SAML z własnym kluczem podpisującym, aby uzyskać uwierzytelnione sesje jako dowolny użytkownik powiązany z innym dostawcą SAML w instancji, w tym w innych organizacjach.

ZITADEL 3.0.0 przed 4.18.0 zawiera podatność na brak uwierzytelniania w hostowanym interfejsie Login V1, gdzie procedura zmiany nazwy użytkownika działa na koncie powiązanym z przepływem logowania przed weryfikacją jakiegokolwiek czynnika. Nieuwierzytelnieni atakujący mogą przesłać nazwę logowania ofiary, a następnie wysłać nową nazwę użytkownika, aby zmienić nazwę dowolnego aktywnego użytkownika, w tym administratorów, blokując im dostęp.

Zitadel przed wersją 4.16.2 zawiera podatność na podrabianie żądań po stronie serwera (SSRF), która umożliwia atakującym zmuszenie serwera do wysyłania żądań do wewnętrznych zasobów poprzez weryfikację domen organizacji. Pobieranie wyzwania używa domyślnego http.Get zamiast chronionego klienta, więc atakujący mogą rejestrować domeny przekierowujące na adresy loopback, wewnętrzne lub metadane chmury, aby skanować porty i mapować sieć wewnętrzną.

ZITADEL 4.x przed 4.17.1 nie sprawdza stanu nieaktywności organizacji podczas uwierzytelniania Login V2, weryfikując tylko status indywidualnego użytkownika. Użytkownicy zdezaktywowanej organizacji, którzy posiadają ważne poświadczenia, istniejącą sesję lub token odświeżania, mogą nadal logować się, tworzyć sesje oraz uzyskiwać lub odświeżać tokeny.

ZITADEL 3.x przed 3.4.14 oraz 4.x przed 4.16.2 zawiera obejście uwierzytelniania w hostowanych interfejsach Login V1 i Login V2, które akceptuje rejestrację passkey lub innych uwierzytelniaczy w sesjach typu identify-only, przed weryfikacją jakiegokolwiek czynnika podstawowego. Nieuwierzytelnieni atakujący znający tylko login ofiary mogą zarejestrować uwierzytelniacz kontrolowany przez atakującego i zalogować się jako ten użytkownik, omijając istniejące hasła i MFA.

ZITADEL przed 4.17.1 zawiera podatność obejścia uwierzytelniania w Login V2, która pozwala nieuwierzytelnionym atakującym na przejęcie kont poprzez uzyskanie kodów OTP za pomocą typu dostarczania returnCode. Atakujący znający login ofiary z włączonymi OTP-Email i OTP-SMS mogą odczytać oba kody z odpowiedzi akcji serwera, aby uzyskać sesje uwierzytelnione MFA, w tym przejęcie administratora.

ZITADEL 3.x przed 3.4.15 oraz 4.x przed 4.17.1 zawiera brak uwierzytelniania w hostowanym interfejsie Login V1, którego procedury rejestracji i inicjalizacji drugiego czynnika działają na sesji identify-only przed weryfikacją jakiegokolwiek czynnika podstawowego. Atakujący znający tylko login ofiary mogą zarejestrować kontrolowane przez siebie czynniki TOTP, OTP-SMS, OTP-Email lub U2F, nadpisać zweryfikowany numer telefonu oraz enumerować użytkowników poprzez rozbieżne błędy.

ZITADEL 4.x przed 4.17.3 oraz 3.x do 3.4.15 chroni tokeny intencji IdP nieuwierzytelnionym, modyfikowalnym szyfrowaniem, co pozwala uwierzytelnionym użytkownikom manipulować własnym tokenem, aby został on zaakceptowany dla intencji logowania zewnętrznego innego użytkownika. Atakujący, który przewidzi identyfikator intencji ofiary w locie i wygra wyścig czasowy, może wywołać /v2/idp_intents lub /v2/sessions, aby ukraść tokeny IdP ofiary lub przejąć jej sesję.

ZITADEL w wersjach od 3.0.0 do 3.4.15 oraz 4.x przed 4.17.3 zawiera błąd nieprawidłowej autoryzacji w User Service API, który weryfikuje uprawnienie user.read względem organizacji wywołującego, a nie organizacji będącej właścicielem docelowego użytkownika. Uwierzytelniony członek z uprawnieniem user.read w zakresie organizacji może odpytać GET /v2/users/{userId}/authentication_methods, aby poznać typy metod uwierzytelniania zarejestrowanych przez użytkowników z innych organizacji.

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.

ZITADEL, narzędzie do zarządzania tożsamością, w wersjach 2.44.0 do 3.4.4 oraz 4.0.0-rc.1 do 4.7.1 ujawnia uwierzytelnionym użytkownikom całkowitą liczbę użytkowników instancji, niezależnie od ich uprawnień. Chociaż nie ujawnia to danych osobowych, informacja ta może być wrażliwa w niektórych kontekstach.

ZITADEL w wersjach 4.0.0-rc.1 do 4.7.0 zawiera podatność DOM-Based XSS w punkcie końcowym wylogowania V2. Endpoint /logout w niebezpieczny sposób przekierowuje do wartości podanej w parametrze GET post_logout_redirect, co pozwala nieuwierzytelnionemu zdalnemu atakującemu na wykonanie złośliwego kodu JavaScript w przeglądarce użytkownika. Do przeprowadzenia ataku wymagane jest, aby w tej samej przeglądarce było aktywnych wiele sesji użytkownika, a przejęcie konta jest ograniczone przy użyciu MFA lub uwierzytelniania bezhasłowego. Podatność została naprawiona w wersji 4.7.1.

ZITADEL, oprogramowanie infrastruktury tożsamości, w wersjach przed 4.6.0, 3.4.3 i 2.71.18 zawiera podatność w mechanizmie resetowania hasła. ZITADEL używa nagłówka Forwarded lub X-Forwarded-Host z przychodzących żądań do konstruowania URL linku potwierdzającego reset hasła, który następnie jest wysyłany e-mailem. Jeśli atakujący może manipulować tymi nagłówkami (np. poprzez wstrzyknięcie nagłówka hosta), może spowodować wygenerowanie linku resetowania hasła wskazującego na złośliwą domenę i przechwycić kod resetowania, a następnie użyć go do zmiany hasła i uzyskania nieautoryzowanego dostępu. Wektor jest łagodzony dla kont z włączonym MFA lub uwierzytelnianiem bezhasłowym.