Prowler: SAML Domain Claiming Enables Cross-Tenant Account Takeover

Beschreibung

Zusammenfassung Prowlers SAML-Authentifizierungsfluss vertraute der E-Mail-Domain, die in einer SAMLResponse bei der Entscheidung, welcher Mieter das endgültige Token erhalten soll, geltend gemacht wurde. Ein bösartiger Mandant mit einer eigenen SAML-Konfiguration und einem selbstgesteuerten IdP könnte einen gültigen SAML-Flow für seine eigene konfigurierte Domain abschließen und gleichzeitig eine E-Mail-Adresse von einer anderen konfigurierten Domain angeben. Im anfälligen Fluss leitete die ACS-Finish-Logik später den Mandanten von der behaupteten E-Mail-Domäne ab, anstatt die Token-Ausgabe an den Mandanten zu binden, der mit der validierten SAML-Konfiguration verknüpft ist. Dies könnte dazu führen, dass ein Token für den falschen Mieter ausgegeben wird. Der angreifer muss im allgemeinen nicht die e-mail-domain des opfers beanspruchen. Wenn der Opfer-Mandant bereits SAML für diese Domain konfiguriert hat, kann ein anderer Mandant dies nicht beanspruchen, da `SAMLConfiguration.email domain` und `SAMLDomainIndex.email domain` weltweit einzigartig sind. ### Details Die bestätigte Ursache liegt im SAML ACS-Finish und Token-Emissionsfluss. Der Fluss wählte eine SAML-Konfiguration über die ACS-Route aus, berechnete aber später den Mandanten aus der behaupteten Benutzer-E-Mail-Domain: ``python email domain = user.email.split("@")[-1] Mandanten = (SAMLConfiguration.objects.using(MainRouter.admin db) .get(email domain=email domain) .tenant) ``` Dies ist unsicher, da `user.email` von der SAML-Behauptung abgeleitet wird. Der für Mitgliedschaftsaktualisierungen und Token-Ausgabe verwendete Mandant muss aus der für die aktuelle ACS-Route validierten SAML-Konfiguration stammen, nicht aus der behaupteten E-Mail-Domain. Der Angriff wird durch mehrere Schwachstellen ermöglicht: 1. **Kein Domainbesitznachweis** (`api/src/backend/api/models.py:2100, 2130-2152`): `SAMLConfiguration.email domain` ist auf Format und globale Einzigartigkeit validiert, nicht aber auf Domainbesitz. Jeder authentifizierte Mandantenadministrator kann eine nicht beanspruchte Domänenzeichenfolge beanspruchen, aber keine Domäne, die bereits von einem anderen Mandanten konfiguriert wurde. 2. **Globaler SAML-Domainindex** (`api/src/backend/api/models.py:2200-2201`): `SAMLDomainIndex.update or create(email domain=self.email domain, defaults={'tenant': self.tenant})` ordnet jede konfigurierte Domain ihrem Mandanten zu. Wenn die Token-Ausgabe später der behaupteten E-Mail-Domain vertraut, kann sie einen anderen Mieter als den von der ACS-Route ausgewählten auflösen. 3. **Hardcoded auto-connect** (`api/src/backend/config/settings/social login.py:23, 25`): `SOCIALACCOUNT EMAIL AUTHENTICATION = True` und `SOCIALACCOUNT EMAIL AUTHENTICATION AUTO CONNECT = True` sind fest codiert und können zur Laufzeit nicht deaktiviert werden. 4. **IdP-initiierte SSO aktiviert ** (`api/src/backend/config/settings/social login.py:78`): `reject idp initiated sso: False` ermöglicht es dem Angreifer, den Fluss zu initiieren, ohne dass eine Aktion des Opfers erforderlich ist. 5. **Token-Ausgabe für den falschen Mandanten** (`api/src/backend/api/v1/views.py:853-873`): Nach der SAML-Authentifizierung könnte der anfällige ACS-Finish-Flow eine Mitgliedschaft erstellen und einen `SAMLToken` mit einem Mandanten ausgeben, der aus dem Arsch abgeleitet ist

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

Was ist zur Behebung zu tun?

Auf eine behobene Version aktualisieren: 5.30.3.

Empfohlene Schritte

• Betroffene Systeme identifizieren: prowler prowler-cloud.
• Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
• Update/Rollout auf behobene Version vorbereiten und priorisiert einspielen.
• Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

• Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
• WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
• Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.
• Administrative Zugänge besonders absichern: MFA, Passwortrotation, Session-Invalidierung.