Unternehmen möchten Benutzererfahrungen optimieren und das gilt auch für Identifikationsverfahren. Mit einer einzigen Anmeldung sollen Benutzer auf verschiedene Dienste und Anwendungen, die ein Unternehmen bereitstellt, zugreifen können. Dafür gibt es verschieden Authentifizierungsmechanismen, auf die ich in diesem Beitrag eingehen möchte und welche möglichen Sicherheitslücken diese mit sich bringen.
– Authentifizierung: Ist der Prozess zur Bestätigung der Identität eines Benutzers (Wer bin ich?) – Autorisierung: Bezieht sich auf die Berechtigungen eines Benutzers (Was bin ich – Administrator, Kunde usw.)
Im heutigen Beitrag schauen wir uns die drei bekanntesten Authentifizierungsverfahren an und welche möglichen Angriffsvektoren diese bieten.
Das JSON Web Token ist ein Access-Token, mit dem Kommunikationspartner Objekte sicher austauschen können und häufig für Authentifizierungsaufgaben genutzt. Ein JWT besteht immer aus drei Teilen: Header, Payload und Signatur.
Der Header enthält Metadaten über das Token. Der Payload enthält die eigentlichen Claims, also standardisierte und benutzerdefinierte Daten. Die Signatur wird unter Verwendung eines geheimen bzw. privaten Schlüssels erstellt und stellt die Integrität und Authentizität des Tokens sicher.
Mögliche Angriffe:
None Algorithm Attack -> Der Webserver akzeptiert ein unsigniertes Token Schwaches Signaturgeheimnis -> Das Password zum Signieren ist leicht erratbar wie password oder secret. Mit hashcat -m 16500 jwt.txt /opt/SecLists/Passwords/Leaked-Databases/rockyou.txt können wir das Geheimnis per Brute-Force knacken und anschließend ein beliebiges JWT erstellen und es selbst signieren. Algorithm Confusion -> Wir können die Webanwendung dazu bringen zur Überprüfung der JWT-Signatur einen anderen Algorithmus zu verwenden als bei dessen Erstellung, indem wir im Header den alg Wert verändern. Damit können wir, wenn für die Erstellung ein asymmetrisches Verfahren genutzt wurde, für die Überprüfung einen symmetrischen Algorithmus erzwingen und das JWT mit dem öffentlichen Schlüssel aus dem asymmertrischen signieren. JWT header parameter injections -> ein Angreifer kann zusätzliche oder manipulierte Header-Parameter (z. B. jkw oder jku) in ein JWT einfügen, um die Signaturprüfung zu beeinflussen. Dadurch kann der Server dazu gebracht werden, einen falschen Algorithmus oder einen vom Angreifer kontrollierten Schlüssel zu verwenden und manipulierte Tokens als gültig zu akzeptieren.
Tools: Mit dem jwt_tool können wir viele Angriffe auf JWTs automatisieren.
OAuth ist ein Autorisierungsframework, das es Anwendungen erlaubt, im Namen eines Benutzers auf geschützte Ressourcen zuzugreifen, ohne dessen Zugangsdaten preiszugeben. Stattdessen erhält die Anwendung zeitlich begrenzte Zugriffstoken, die den erlaubten Zugriffsumfang (Scope) definieren.
OAuth-Flow:
Mögliche Angriffe:
Stealing Access Token -> Ein Angreifer kann die Identität des Opfers annehmen und dessen Zugriffstoken stehlen, indem er den Parameter redirect_uri so manipuliert, dass ein Opfer zu einem System unter Kontrolle des Angreifers weitergeleitet wird. Improper CSRF Protection -> Fehlt der sogenannte state Parameter in einer Autorisierungsanfrage kann so ein CSRF-Angriff auf den OAuth-Flow möglch sein.
SAML ist ein XML-basierter Standard, der die Authentifizierung und Autorisierung zwischen Parteien ermöglicht und zur Implementierung von SSO verwendet werden kann. Bei SAML werden Daten in digital signierten XML-Dokumenten ausgetauscht, um die Datenintegrität zu gewährleisten.
SAML besteht aus drei Komponenten:
1. Identity Provider (IdP) – Die Instanz, die Benutzer authentifiziert. 2. Service Provider (SP): Die Instanz, die dem Benutzer einen Dienst oder eine Ressource bereitstellt. 3. SAML-Assertions: XML-basierte Daten, die Informationen über den Authentifizierungs- und Autorisierungsstatus eines Benutzers enthalten
SAML-Flow:
Signature Exclusion Attack -> Ein Angreifer kann die digitale Signatur aus einer SAML-Response oder Assertion entfernt. Akzeptiert der Service Provider dennoch die Nachricht, können manipulierte Identitäten oder Berechtigungen verwendet werden. Signature Wrapping Attack -> Ein Angreifer kann zusätzliche, manipulierte Assertion in die SAML-Response (IdP an SP) einfügen. Die gültige Signatur bleibt erhalten, verweist jedoch auf ein harmloses Element, während die Anwendung fälschlich die unsignierte oder manipulierte Assertion verarbeitet XXE Injection -> Wenn ein SAML-SP einen falsch konfigurierten XML-Parser verwendet, der externe Entitäten lädt, kann dieser für XXE-Injektionen anfällig sein XSLT Server-side Injection -> Möglich wen der XML-Parser die Daten nicht korrekt verarbeitet.
