ZITADEL Login V2 genehmigt OAuth-2.0-Geräteautorisierungen mit der bestehenden angemeldeten Sitzung des Browsers, ohne Zustimmung abzufragen oder den auf dem Gerät angezeigten Benutzercode zu verlangen. Ein Angreifer, der eine Geräteautorisierung startet und einen angemeldeten Benutzer dazu bringt, einen einzigen Link zu öffnen, kann die Tokens dieses Benutzers erhalten, inklusive API-Zugriff mit dem ZITADEL-Projekt-Scope. Dieselbe fehlende Prüfung erlaubt über die OIDC-Geräteautorisierungs-API die Umgehung der Projektzugriffseinstellungen.
ZITADEL · ZITADEL
Die gehostete Login-V2-Oberfläche von ZITADEL vertraut einem verificationCheck-Cookie, das nur aus der Benutzer-ID und dem Browser-Fingerprint abgeleitet wird und daher von jedem berechnet werden kann. Ein nicht authentifizierter Angreifer, der die Benutzer-ID oder den Loginnamen eines aktiven Benutzers ohne jegliche Authentifizierungsmethode kennt, kann dessen erstes Passwort setzen, einen Passkey registrieren oder ein externes Identity Provider-Konto verknüpfen und sich anschliessend als dieser Benutzer anmelden. Benutzer, die bereits ein Passwort, einen Passkey oder eine Identity-Provider-Verknüpfung besitzen, sind nicht betroffen, und die ZITADEL-APIs sind nicht betroffen.
ZITADEL · ZITADEL
ZITADEL-Versionen 4.0.0 bis 4.19.4 akzeptieren in der Login-V2-Benutzeroberfläche unvertrauenswürdige Public-Host-Header. Ein nicht authentifizierter Angreifer, der den Login-Namen eines Opfers kennt, kann erreichen, dass echte E-Mails zum Zurücksetzen des Passworts, zu Einladungen und zur E-Mail-Verifizierung Links auf seinen eigenen Host enthalten. Öffnet das Opfer den Link oder ruft ihn ein automatischer Mail-Scanner ab, erbeutet der Angreifer den Einmalcode und kann das Konto übernehmen, einschliesslich Instanz-Administratoren. Es ist eine Benutzerinteraktion nötig, und die Standardkonfiguration mit Login V2 ist betroffen.
ZITADEL · ZITADEL
ZITADEL 4.0.0 bis 4.19.1 und 3.0.0 bis 3.4.15 enthalten eine Schwachstelle im gehosteten Login-UI Login V2: Das Session-Cookie ist weder signiert noch wird es validiert. Ein nicht authentifizierter Angreifer, der das Login-UI erreichen und die zeitlich geordnete Session-ID eines Opfers erraten kann, kann ein neues Token für die authentifizierte Session des Opfers erhalten, einschliesslich Sessions, in denen MFA abgeschlossen wurde. Dies kann zur vollständigen Übernahme eines Instanz-Administratorkontos führen; der Angriff hängt vom Zeitpunkt ab und davon, dass die Session-ID erratbar ist.
ZITADEL · ZITADEL
ZITADEL weist eine Authentifizierungsumgehung im SAML-Identity-Provider-Intent-Callback auf, der von Login V2 und benutzerdefinierten Login-Oberflächen verwendet wird. Ein Angreifer mit Organisationsadministrator-Berechtigung kann einen SAML-Identity-Provider mit einem selbst kontrollierten Signaturschlüssel registrieren und eine authentifizierte Sitzung als beliebiger Benutzer erlangen, der mit einem anderen SAML-Provider auf derselben Instanz verknüpft ist, auch in anderen Organisationen. Die Schwachstelle betrifft nur Instanzen mit mindestens zwei SAML-Identity-Providern und gewährt für sich allein keine administrativen Rechte.
ZITADEL · ZITADEL
Die gehostete Login-V1-Oberfläche von ZITADEL ändert einen Benutzernamen, bevor der Login-Ablauf einen Authentifizierungsfaktor geprüft hat. Ein nicht authentifizierter Angreifer, der den Login-Namen eines Opfers kennt, kann jeden aktiven menschlichen Benutzer umbenennen, einschliesslich Instanz-Administratoren, wodurch der legitime Inhaber ausgesperrt wird. Der Angreifer kann das Konto nicht übernehmen, da kein Passwort, keine Session und kein Token offengelegt werden.
ZITADEL · ZITADEL
Die gehostete Login-V1-Oberfläche von ZITADEL vertraut im Registrierungsendpunkt für «externes Konto nicht gefunden» vom Client gelieferten externen Identitätsfeldern. Ein nicht authentifizierter Angreifer kann ein Konto vorab erstellen, das an die externe IdP-Identität eines Opfers gebunden ist; der spätere echte externe Login des Opfers meldet sich dann in dieses vom Angreifer vorbereitete Konto an. Voraussetzung ist, dass Login V1 verwendet wird und mindestens ein externer IdP die manuelle Kontoerstellung erlaubt. Login V2 ist nicht betroffen.
ZITADEL · ZITADEL
ZITADEL 4.x vor 4.17.1 prüft bei der Authentifizierung über Login V2 nur den Status des einzelnen Benutzers und ignoriert, ob dessen Organisation deaktiviert wurde. Benutzer einer deaktivierten Organisation, die noch gültige Zugangsdaten, eine bestehende Sitzung oder ein Refresh-Token besitzen, können sich anmelden, Sitzungen erstellen und Tokens beziehen oder erneuern. Login V1 ist nicht betroffen, und vor der Deaktivierung ausgestellte Sitzungen und Tokens können bis zu ihrem Ablauf weiterhin funktionieren.
ZITADEL · ZITADEL
Die gehosteten Login-Oberflächen V1 und V2 von ZITADEL akzeptieren die Registrierung von Passkeys oder anderen Authentifikatoren in identifizierenden Login-Sitzungen, bevor ein primärer Faktor geprüft wurde. Ein nicht authentifizierter Angreifer, der nur den Login-Namen eines Opfers kennt, kann einen eigenen Authentifikator registrieren und sich als dieser Benutzer anmelden, wodurch Passwörter und MFA umgangen werden. Anwendungen, die Benutzer über die betroffenen gehosteten Login-Oberflächen authentifizieren, sind gefährdet.
ZITADEL · ZITADEL
Die gehostete Login-V2-Oberfläche von ZITADEL kann von einem nicht authentifizierten Angreifer missbraucht werden, der nur den Login-Namen eines Opfers kennt. Sind bei diesem Opfer sowohl OTP-E-Mail als auch OTP-SMS hinterlegt, kann der Angreifer beide Einmalcodes aus den Antworten der Server-Aktionen auslesen und eine vollständig MFA-authentifizierte Sitzung erhalten. Ist das Opfer ein Instanz-Administrator, kann dies zur vollständigen Übernahme der Instanz führen.
ZITADEL · ZITADEL
Die gehostete Login-V1-Oberfläche von ZITADEL nimmt Registrierungs- und Initialisierungsanfragen für einen zweiten Faktor an, bevor der primäre Faktor geprüft wurde. Ein Angreifer, der nur den Login-Namen eines Opfers kennt, kann eigene TOTP-, OTP-SMS-, OTP-E-Mail- oder U2F-Faktoren registrieren, die verifizierte Telefonnummer überschreiben und durch unterschiedliche Fehlermeldungen gültige Benutzer ermitteln. Die Schwachstelle erlaubt für sich allein keine Kontoübernahme, da das Passwort weiterhin benötigt wird. Anwendungen, die Benutzer über Login V1 authentifizieren, sind betroffen; Login V2 ist nicht betroffen.
ZITADEL · ZITADEL
ZITADEL 3.x vor 3.4.15 und 4.x vor 4.17.1 prüft beim Ausstellen von Passkey- oder passwortlosen Registrierungscodes die Organisation des Zielbenutzers nicht. Geprüft wird nur die Organisation im Header x-zitadel-orgid. Ein Angreifer mit Benutzer-Schreibrechten in einer Organisation kann einen Registrierungscode für einen Benutzer in einer anderen Organisation derselben Instanz erhalten, eigenen Authenticator hinterlegen und das Konto übernehmen. Die Schwachstelle betrifft nur Instanzen mit mehreren Organisationen und setzt ein authentifiziertes Konto mit Benutzer-Schreibrechten voraus. Der CVE-Eintrag bewertet sie mit 9.3 (CVSS v4.0); das GitHub-Advisory mit 9.6 (CVSS v3.1).
ZITADEL · ZITADEL
ZITADEL, ein Open-Source-Identity-Provider, schützt IdP-Intent-Tokens für externe Identity-Provider-Anmeldungen mit einer Verschlüsselung ohne Integritätsprüfung. Ein authentifizierter Benutzer mit gültigem Konto auf derselben Instanz kann sein eigenes Token so verändern, dass das Backend es für die ausstehende externe Anmeldung eines anderen Benutzers akzeptiert. Wenn der Angreifer zusätzlich die Intent-Kennung des Opfers vorhersagt und ein Timing-Rennen gewinnt, kann er die externen IdP-Tokens des Opfers auslesen oder dessen Sitzung übernehmen. Der Angriff ist probabilistisch und zeitlich begrenzt, und Instanzen ohne externe Identity Provider sind nicht betroffen.
ZITADEL · ZITADEL
ZITADEL-Versionen 3.0.0 bis 3.4.15 und 4.0.0 bis 4.17.2 verknüpfen Benutzerkonten mit externen Identity Providern (IdPs), ohne einen primären Faktor oder die Berechtigung des Aufrufers zu prüfen. Ein nicht authentifizierter Angreifer, der den Benutzernamen eines Opfers kennt, kann über die Login-V2-Oberfläche seine eigene externe IdP-Identität mit dem Konto des Opfers verknüpfen und sich anschliessend als Opfer anmelden. Jeder authentifizierte Benutzer kann zudem über die AddIDPLink-API der User Service V2 externe Identitäten vorab beanspruchen. Der Login-V2-Pfad setzt voraus, dass eine Organisation die Verknüpfung externer IdP-Konten erlaubt.
ZITADEL · ZITADEL
