Podatności Logto

Logto wykonuje wyszukiwanie główne bez normalizacji adresów email i identyfikatorów, co umożliwia kolizję główną i nieautoryzowany dostęp do konta poprzez użycie tożsamości różniących się wielkością liter lub znakami Unicode.

Logto nie wymusza lokalnie skonfigurowanego MFA podczas uwierzytelniania SSO, co umożliwia użytkownikom ominięcie wymogów drugiego czynnika i uzyskanie nieautoryzowanego dostępu.

Logto pomija walidację nonce OIDC, gdy roszczenie nonce jest nieobecne w id_token, co umożliwia odtwarzanie tokenów uwierzytelniających i osłabia wiązanie sesji.

Logto umożliwia łączenie kont SSO na podstawie niezweryfikowanego adresu email, co pozwala atakującemu zarejestrować tożsamość u dostawcy tożsamości używając adresu email ofiary i uzyskać nieautoryzowany dostęp do jej konta.

Logto do wersji 1.42.0 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w endpointcie tworzenia łącznika OIDC SSO, który nie waliduje parametru adresu URL wystawcy. Administratorzy dzierżawy z poświadczeniami Management API mogą podać dowolne wewnętrzne adresy URL, aby wywołać żądania HTTP GET do usług w sieci prywatnej, a treść odpowiedzi jest zwracana w odpowiedziach API.

Logto do wersji 1.42.0 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w endpointcie POST /api/hooks/:id/test, który akceptuje dowolne adresy URL bez walidacji hosta. Administratorzy dzierżawy z tokenami Management API mogą sprawić, że serwer wyśle żądania HTTP POST do wewnętrznych adresów URL i odczyta treść odpowiedzi z usług w sieci prywatnej.

Logto, nowoczesna infrastruktura uwierzytelniania open-source, w wersjach od 1.40.1 do 1.41.0 zawiera podatność w workflow GitHub Actions, gdzie tytuł pull requesta jest bezpośrednio interpolowany do polecenia echo w kroku commitlint. Tytuł zawierający pojedynczy cudzysłów może przerwać ciąg echo i dołączyć dowolne polecenia powłoki na runnerze GitHub Actions. Atakujący może zakłócić działanie ephemeral workflow, ale nie ma dostępu do sekretów repozytorium.

Logto przed wersją 1.41.0 ma podatność na katastrofalne cofanie się (catastrophic backtracking) w wyrażeniu regularnym używanym do blokowania subadresów e-mail. Atakujący może wysłać specjalnie skonstruowany adres e-mail, powodując zablokowanie pętli zdarzeń i niedostępność usług uwierzytelniania.

Logto pomija walidację elementu SAML <Conditions>, co umożliwia atakującym usunięcie ograniczeń czasowych i dotyczących odbiorców oraz wielokrotne odtwarzanie asercji.

Logto po cichu nie usuwa sesji SAML inicjowanych przez IdP, co umożliwia odtwarzanie sesji i ponowne użycie w oknie ważności sesji.

Logto przed wersją 1.41.0 zawiera podatność na wstrzykiwanie XML w SAML, gdzie atrybuty profilu użytkownika (np. nazwa, email) są podstawiane do szablonu SAML bez odpowiedniego escapowania. Uwierzytelniony użytkownik z niskimi uprawnieniami może wstawić znaczniki XML do atrybutu profilu, co pozwala na sfałszowanie atrybutów SAML, takich jak rola, i eskalację uprawnień w zaufanych serwisach.

Logto przed wersją 1.41.0 zawiera podatność w mechanizmie weryfikacji wieloetapowej (step-up) w Centrum Konta. Atakujący z tokenem API może utworzyć i zweryfikować rejestrację WebAuthn dla nowego klucza dostępu, a następnie użyć jej jako potwierdzenia tożsamości, co pozwala na zarządzanie czynnikami MFA bez posiadania hasła, identyfikatora lub istniejącego czynnika MFA.

Logto przed wersją 1.41.0 zawiera podatność w weryfikacji TOTP, która pozwala na ponowne użycie tego samego kodu TOTP w oknie akceptacji RFC 6238. Atakujący, znając pierwszy czynnik uwierzytelniania i przechwytując aktywny kod TOTP, może go powtórzyć, aby ominąć MFA.

Podatność w Logto przed wersją 1.41.0 pozwala na wstrzyknięcie skryptu (XSS) poprzez odbicie niesprawdzonego parametru SAML RelayState, SAMLResponse lub actionUrl w formularzu HTML. Atakujący może wykorzystać spreparowane żądanie do endpointu SAML, aby po zalogowaniu użytkownika wykonać dowolny kod JavaScript w kontekście domeny Logto.