SSO Injection: Vom Login zur Domänen-Übernahme

Single Sign-On (SSO) soll den Benutzerkomfort erhöhen und gleichzeitig die Sicherheit verbessern. Doch wie bei jeder zentralisierten Architektur hängt alles an der Implementierung – und an der Validierung der Datenflüsse. In einem Red Team Projekt fanden wir eine fatale Schwachstelle in der SSO-Implementierung eines großen Mittelständlers.

Der Einstiegspunkt: Manipulierbare Assertion

Das Zielsystem nutzte SAML-basiertes SSO über einen Identity Provider (IdP), der uns auf den ersten Blick korrekt konfiguriert erschien. Doch über einen angebundenen Drittanbieter-Service (welcher SAML-Assertions nur teilweise prüfte) konnten wir eine manipulierte Assertion injizieren und dem Zielsystem einen anderen Benutzer vorgaukeln – mit Adminrechten.

Angriff im Detail

Der Third-Party-Service prüfte lediglich die digitale Signatur des SAML-Requests, nicht jedoch den Inhalt der Assertion selbst. Durch das Austauschen des NameID-Wertes gegen einen bekannten Administrator-Account (z. B. admin@firma.local) erhielten wir ein aktives Session-Cookie für das interne Portal – ganz ohne Passwort.

Von Web zu Windows

Über das kompromittierte Portal hatten wir Zugriff auf einen Self-Service-Bereich, der automatisch einen Benutzer in Active Directory anlegte. Dabei wurde ein nicht validierter API-Call an einen internen Dienst ausgelöst – mit den Rechten des kompromittierten Admins.

• Benutzer anlegen mit beliebigem Passwort
• Benutzer zur Gruppe Domain Admins hinzufügen
• Einloggen via RDP und Mimikatz-Dump

Die vollständige Kompromittierung der Active Directory-Domäne war in unter 90 Minuten abgeschlossen.

Lessons Learned

• SSO-Integrationen mit Drittanbietern immer vollständig validieren
• Nur korrekt signierte und geprüfte Assertions zulassen
• IdP- und SP-seitige Logging- & Alerting-Mechanismen nutzen

Weiterführende Referenzen

PortSwigger: SAML vulnerability abuses SSO
SAMLTool.io – Assertion Editor & Validator

👉 Zurück zur Blog-Übersicht