JWT Algorithm Confusion: RS256 zu HS256 Angriff ausnutzen

Verständnis des kritischen Sicherheitsfehlers, der öffentliche Schlüssel in Geheimnisse verwandelt

Im Bereich der modernen Webanwendungssicherheit sind JSON Web Tokens (JWTs) allgegenwärtig für Authentifizierung und Autorisierung. Doch eine subtile, aber verheerende Schwachstelle lauert in vielen JWT-Implementierungen: Algorithmus-Verwirrungsangriffe. Dieser Angriffsvektor nutzt die Art und Weise aus, wie Server JWT-Signaturen validieren, und ermöglicht Angreifern, Tokens zu fälschen, indem sie den im Token-Header angegebenen Algorithmus manipulieren.

Was ist JWT Algorithm Confusion?

Schwachstellen durch Algorithmus-Verwirrung entstehen typischerweise durch fehlerhafte Implementierungen von JWT-Bibliotheken, bei denen viele Bibliotheken eine einzige, algorithmus-unabhängige Methode zur Signaturüberprüfung bereitstellen. Die Schwachstelle tritt auf, wenn ein Server nicht richtig durchsetzt, welcher kryptografische Algorithmus zur Verifizierung eines JWT verwendet werden soll.

Algorithmus-Verwirrung entsteht, wenn ein System die Art der Signatur in einem JWT nicht korrekt überprüft, was einem Angreifer ermöglicht, durch unzureichende Unterscheidung zwischen verschiedenen Signaturmethoden auszunutzen. Die gefährlichste Variante besteht darin, vom RS256 (RSA mit SHA-256, asymmetrischer Algorithmus) auf HS256 (HMAC mit SHA-256, symmetrischer Algorithmus) umzuschalten.

Der grundlegende Unterschied zwischen RS256 und HS256

Das Verständnis von Algorithmus-Verwirrung erfordert das Erfassen des grundlegenden Unterschieds zwischen symmetrischer und asymmetrischer Kryptografie:

RS256 (RSA + SHA-256) - Asymmetrisch: - Verwendet einen privaten Schlüssel zum Signieren - Verwendet einen mathematisch verwandten öffentlichen Schlüssel zur Verifizierung - Der private Schlüssel muss geheim gehalten werden - Der öffentliche Schlüssel kann offen geteilt werden - Zwei verschiedene Schlüssel für unterschiedliche Zwecke

HS256 (HMAC + SHA-256) - Symmetrisch: - Verwendet einen einzigen geheimen Schlüssel für Signatur und Überprüfung - Beide Operationen nutzen denselben Schlüssel - Das Geheimnis muss vertraulich bleiben - Jeder mit dem Geheimnis kann Tokens erstellen und verifizieren

Wie funktioniert der Angriff: Der tödliche Switch

Der häufigste Fall besteht darin, ein RS256-Token auf HS256 umzuschalten und dann den RSA-öffentlichen Schlüssel als HMAC-Geheimnis zu verwenden. Hier ist der Ablauf:

Schritt 1: Ein gültiges JWT erhalten

Der Angreifer erhält zunächst ein legitimes JWT, meist signiert mit RS256:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwicm9sZSI6InVzZXIifQ.signature

Dieses Token besteht aus drei Teilen: - Header: {"alg":"RS256","typ":"JWT"} - Payload: {"sub":"user123","role":"user"} - Signature: Wird mit dem öffentlichen RSA-Schlüssel des Servers verifiziert

Schritt 2: Den öffentlichen Schlüssel beschaffen

Server geben ihre öffentlichen Schlüssel manchmal als JSON Web Key (JWK) Objekte über einen Standard-Endpunkt aus, z.B. /jwks.json oder /.well-known/jwks.json. Angreifer können öffentliche Schlüssel auf verschiedene Weisen erhalten:

Standard-JWKS-Endpunkte (/.well-known/jwks.json)
Serverdokumentation oder Konfigurationsdateien
SSL/TLS-Zertifikate
Ableiten von Schlüsseln aus mehreren abgefangenen JWTs mit Tools wie jwt_forgery.py

Schritt 3: Header und Payload des Tokens modifizieren

Der Angreifer ändert den Algorithmus im Header von RS256 auf HS256 und passt die Payload an, um Privilegien zu erhöhen:

{
  "alg": "HS256",
  "typ": "JWT"
}

{
  "sub": "user123",
  "role": "admin"
}

Schritt 4: Signieren mit dem öffentlichen Schlüssel als HMAC-Geheimnis

Das Fälschen von Tokens erfolgt durch Signieren der Payload mit dem PEM-formatierten öffentlichen Schlüssel als HMAC-Schlüssel. Der Angreifer signiert das modifizierte Token mit HS256, wobei er den öffentlichen RSA-Schlüssel des Servers als HMAC-Geheimnis verwendet.

Schritt 5: Server akzeptiert das gefälschte Token

Wenn der Server dieses bösartige Token empfängt, zeigt sich die Schwachstelle darin, wie die Verifizierungsmethode es verarbeitet:

Probleme entstehen, wenn Entwickler annehmen, die verify-Methode würde ausschließlich Tokens mit asymmetrischer Signatur wie RS256 behandeln und immer einen festen öffentlichen Schlüssel verwenden.

// Anfälliges Code-Muster
publicKey = public-key-of-server;
token = request.getCookie("session");
verify(token, publicKey);

Wenn der Server ein Token mit symmetrischer Signatur wie HS256 erhält, behandelt die generische verify-Methode den öffentlichen Schlüssel fälschlicherweise als HMAC-Geheimnis. Der Server nutzt unbewusst seinen eigenen öffentlichen Schlüssel als HMAC-Geheimnis, um die Signatur des Angreifers zu überprüfen, was erfolgreich ist, weil der Angreifer denselben öffentlichen Schlüssel zum Erstellen der Signatur verwendet hat.

Auswirkungen in der Praxis: Aktuelle Schwachstellen

Algorithmus-Verwirrung ist kein rein theoretisches Risiko. Neuere Entdeckungen zeigen, dass sie weiterhin verbreitet ist:

CVE-2024-54150 (Dezember 2024)

Eine Schwachstelle wurde in der cjwt-Bibliothek entdeckt, bei der die Funktion cjwt_decode keine Algorithmus-Auswahl erfordert, und der Code für HMAC- und RSA-Schlüssel identisch ist. Der Switch-Statement der Bibliothek würde HS256-Tokens mit dem bereitgestellten Schlüssel verarbeiten, ohne zu erkennen, dass ein öffentlicher Schlüssel als Geheimnis übergeben wurde.

CVE-2024-37568 (2024)

Diese kritische Schwachstelle in Authlib, einer populären Python-Bibliothek für OAuth und OpenID Connect, trat auf, wenn die ‘alg’-Anspruch fehlt oder falsch ist, was dazu führte, dass Authlib fälschlicherweise auf HMAC-Überprüfung standardisierte, obwohl ein öffentlicher Schlüssel vorhanden war.

CVE-2023-48238 (2023)

Die json-web-token-Bibliothek wurde anfällig, weil der Algorithmus zur Signaturüberprüfung aus dem JWT-Token selbst entnommen wurde, der zu diesem Zeitpunkt noch unüberprüft war und nicht vertraut werden sollte.

Warum existiert diese Schwachstelle: Die Ursachen

Fehlerhaftes Bibliotheksdesign

Der JWT-Header enthält einen alg-Parameter, der dem Server mitteilt, welcher Algorithmus zum Signieren verwendet wurde und welcher Algorithmus bei der Verifizierung genutzt werden soll. Das ist grundsätzlich fehlerhaft, weil der Server keine andere Wahl hat, als benutzerkontrollierte Eingaben aus dem Token zu vertrauen, die noch nicht verifiziert wurden.

Missverständnis bei Entwicklern

Viele Entwickler missverstehen die Sicherheitsimplikationen generischer Verifikationsmethoden. Sie gehen fälschlicherweise davon aus, dass das Übergeben eines öffentlichen Schlüssels automatisch bedeutet, dass die Bibliothek nur asymmetrische Signaturen akzeptiert, ohne zu realisieren, dass die Bibliothek dem im unüberprüften Header angegebenen Algorithmus vertraut.

Unzureichende Validierung

Anwendungen versäumen oft, zu validieren, ob der Algorithmus im Header mit dem erwarteten Algorithmus übereinstimmt. Ohne diese Prüfung können Angreifer beliebige Algorithmen austauschen.

Demonstration des Angriffs: Praktische Ausnutzung

So könnte ein Angreifer diesen Angriff mit gängigen Tools durchführen:

Verwendung von jwt_tool

# Öffentlichen Schlüssel vom JWKS-Endpunkt extrahieren
curl https://target.com/.well-known/jwks.json  jwks.json

# Gefälschtes Token erstellen
python jwt_tool.py original_token.txt -X k -pk public_key.pem

Manuelle Python-Implementierung

import jwt
import base64

# Öffentlichen Schlüssel lesen
with open('public_key.pem', 'r') as f:
    public_key = f.read()

# Bösartige Nutzlast erstellen
payload = {
    'sub': 'user123',
    'role': 'admin',
    'iat': 1234567890
}

# Mit HS256 signieren, öffentlichen Schlüssel als Geheimnis verwenden
forged_token = jwt.encode(
    payload,
    public_key,
    algorithm='HS256'
)

print(forged_token)

Verwendung von Burp Suite

Sobald der öffentliche Schlüssel in geeignetem Format vorliegt, kann der JWT beliebig modifiziert werden, wobei der alg-Header auf HS256 gesetzt wird. Dann wird das Token mit HS256 signiert, wobei der RSA-öffentliche Schlüssel als Geheimnis dient.

Erweiterte Exploitation-Techniken

Wiederherstellung des öffentlichen Schlüssels

Wenn der öffentliche Schlüssel nicht direkt verfügbar ist, kann man dennoch Algorithmus-Verwirrung testen, indem man den Schlüssel aus einem Paar bestehender JWTs mit Tools wie jwt_forgery.py ableitet.

Die mathematische Beziehung zwischen mehreren Signaturen, die mit demselben privaten Schlüssel erstellt wurden, kann ausgenutzt werden, um den öffentlichen Schlüssel zu rekonstruieren. Dafür sind nur zwei JWTs erforderlich, die mit demselben Schlüssel signiert wurden.

Format-Sensitivität

Der verwendete öffentliche Schlüssel muss exakt mit dem auf dem Server gespeicherten übereinstimmen, inklusive Format und Nicht-Printable-Charakteren wie Zeilenumbrüchen. Angreifer müssen oft mit verschiedenen Schlüssel-Formaten experimentieren:

PEM-Format mit Header
Rohdaten des Schlüssels
Verschiedene Zeilenendungen (CRLF vs LF)
Mit oder ohne abschließende Zeilen

Erkennung und Tests

Identifikation anfälliger Anwendungen

Sicherheitsforscher können Algorithmus-Verwirrung testen durch:

Analyse der JWT-Header zur Identifikation des verwendeten Signaturalgorithmus
Beschaffung der öffentlichen Schlüssel über JWKS-Endpunkte oder andere Wege
Angriffsversuch durch Manipulation des Algorithmus und Signierung mit dem öffentlichen Schlüssel
Beobachtung des Serververhaltens, ob das gefälschte Token akzeptiert wird

Automatisierte Scans

Ab Burp Suite Professional 2022.5.1 kann der Burp Scanner automatisch eine Reihe von Schwachstellen in JWT-Mechanismen erkennen, inklusive Algorithmus-Verwirrungsangriffe.

Abwehrstrategien: Schutz Ihrer Anwendungen

1. Explizite Angabe erwarteter Algorithmen

JWT-Bibliotheken sollten einen Algorithmus-Parameter in ihrer Verifizierungsfunktion hinzufügen, und der Server sollte bereits wissen, welchen Algorithmus er zum Signieren verwendet.

Sichere Implementierung:

// Node.js mit jsonwebtoken
jwt.verify(token, publicKey, { algorithms: ['RS256'] });

# Python mit PyJWT
jwt.decode(token, public_key, algorithms=['RS256'])

// Java mit jjwt
Jwts.parserBuilder()
    .setSigningKey(publicKey)
    .requireAlgorithm(SignatureAlgorithm.RS256)
    .build()
    .parseClaimsJws(token);

2. Verwendung von Algorithmus-Whitelist

Es ist vorzuziehen, eine Whitelist zu verwenden, die explizit die autorisierten Algorithmen wie HS256 oder RS256 definiert. Das garantiert eine strikte Kontrolle und vermeidet Schlupflöcher durch lax interpretierte Algorithmen.

3. Trennung der Verifizierungslogik nach Schlüsseltyp

Verwenden Sie niemals dieselbe Verifizierungsmethode für symmetrische und asymmetrische Schlüssel. Implementieren Sie separate Codepfade:

function verifyToken(token, expectedAlgorithm, key) {
    // Algorithmus aus Header nur für Logging extrahieren
    const header = JSON.parse(
        Buffer.from(token.split('.')[0], 'base64').toString()
    );
    
    // Algorithmus im Header niemals vertrauen
    // Immer den erwarteten Algorithmus verwenden
    if (expectedAlgorithm === 'RS256') {
        return verifyRS256(token, key);
    } else if (expectedAlgorithm === 'HS256') {
        return verifyHS256(token, key);
    }
    
    throw new Error('Nicht unterstützter Algorithmus');
}

4. Implementierung von Typprüfungen

Einige Bibliotheken enthalten inzwischen Schutzmechanismen, die erkennen, wenn ein öffentlicher Schlüssel anstelle eines symmetrischen Geheimnisses verwendet wird:

function isPublicKey(key) {
    return key.includes('BEGIN PUBLIC KEY') || 
           key.includes('BEGIN RSA PUBLIC KEY');
}

function verifyHS256(token, secret) {
    if (isPublicKey(secret)) {
        throw new Error('Öffentlicher Schlüssel kann nicht als HMAC-Geheimnis verwendet werden');
    }
    return jwt.verify(token, secret, { algorithms: ['HS256'] });
}

5. Ablehnung des “none”-Algorithmus

Der “none”-Algorithmus ist für Fälle gedacht, in denen die Integrität des Tokens bereits überprüft wurde. Leider behandeln einige Bibliotheken Tokens mit “none”-Signatur fälschlicherweise als gültig.

In der Produktion immer explizit Tokens mit “none”-Algorithmus ablehnen:

const decoded = jwt.verify(token, key, {
    algorithms: ['RS256', 'HS256'],
    // Der 'none'-Algorithmus wird automatisch abgelehnt
});

6. Verwendung starker Geheimnisse für HMAC

Bei der Implementierung von JWT-Anwendungen machen Entwickler manchmal Fehler, indem sie Standard- oder Platzhalter-Geheimnisse nicht ändern, was es einem Angreifer erleichtert, das Geheimnis des Servers mit Wörterbüchern zu brute-forcen.

Für HS256-Implementierungen: - Verwendung kryptografisch zufälliger Geheimnisse mit mindestens 256 Bit - Geheimnisse sicher in Umgebungsvariablen oder Secrets-Management-Systemen speichern - Geheimnisse regelmäßig rotieren - Geheimnisse niemals im Quellcode hardcoden

7. Alle Ansprüche gründlich validieren

Neben der Algorithmus-Validierung sollten auch alle Claims umfassend geprüft werden:

jwt.verify(token, publicKey, {
    algorithms: ['RS256'],
    issuer: 'https://trusted-issuer.com',
    audience: 'your-application',
    clockTolerance: 60 // Sekunden Toleranz bei Zeitvergleichen
});

8. Bibliotheken aktuell halten

Um CVE-2024-37568 zu beheben, ist es unerlässlich, Authlib auf Version 1.3.1 oder höher zu aktualisieren, die robuste Fixes enthalten, um Algorithmus-Verwirrung zu verhindern und eine korrekte JWT-Validierung sicherzustellen.

Regelmäßig JWT-Bibliotheken aktualisieren, um Sicherheitsupdates und verbesserte Validierungslogik zu nutzen.

Beste Praktiken für JWT-Sicherheit

Umfassende Sicherheits-Checkliste

Algorithmus-Management: - ✅ Explizit erlaubte Algorithmen in Verifizierungsaufrufen angeben - ✅ Nie den Algorithmus aus dem Token-Header vertrauen - ✅ Den “none”-Algorithmus in der Produktion deaktivieren - ✅ Asymmetrische Algorithmen (RS256, ES256) für die meisten Anwendungsfälle verwenden - ✅ Algorithmus-Whitelist auf Anwendungsebene implementieren

Schlüsselverwaltung: - ✅ Private Schlüssel sicher in Schlüsselmanagementsystemen speichern - ✅ Starke, zufällig generierte Geheimnisse für HMAC verwenden - ✅ Schlüssel regelmäßig rotieren, mit Übergangsfristen - ✅ Öffentliche Schlüssel zugänglich halten, private Schlüssel schützen - ✅ Schlüssel niemals im Quellcode oder in Konfigurationsdateien einbetten

Token-Handling: - ✅ Kurze Ablaufzeiten setzen (15 Minuten oder weniger für Zugriffstokens) - ✅ Rotation von Refresh-Tokens - ✅ Alle Standard-Claims validieren (iss, aud, exp, nbf, iat) - ✅ Nur HTTPS für Token-Übertragung verwenden - ✅ Tokens sicher speichern (HttpOnly-Cookies für Web-Apps)

Implementierung: - ✅ Gut gepflegte, aktuelle JWT-Bibliotheken verwenden - ✅ Fehlerbehandlung richtig implementieren, ohne Informationen zu leaken - ✅ Sicherheitsereignisse protokollieren für Monitoring und Incident Response - ✅ Regelmäßige Sicherheitsüberprüfungen und Penetrationstests durchführen - ✅ Entwickler in JWT-Sicherheitsprinzipien schulen

Auswahl des richtigen Algorithmus

Für neue Anwendungen: - RS256 oder ES256: Für die meisten Szenarien mit öffentlicher Schlüsselausgabe - PS256: Verbesserte Sicherheit gegenüber RS256 mit probabilistischen Signaturen - EdDSA: Sehr sicher und effizient, ideal für neue Implementierungen

Vermeiden: - HS256 für öffentliche APIs, bei denen das Geheimnis exponiert werden könnte - Schwache Schlüssel: Mindestens 2048 Bit für RSA, 256 Bit für ECDSA - Algorithmus-Flexibilität: Nicht mehrere Algorithmen unterstützen, es sei denn, unbedingt notwendig

Testen Ihrer Implementierung

Schritte zur Schwachstellenbewertung

Überprüfung des Verifizierungscodes auf explizite Angabe der Algorithmen
Test mit modifizierten Tokens, bei denen der Algorithmus geändert wurde
Versuch der öffentlichen Schlüssel-Substitution, um Schutzmechanismen zu prüfen
Überprüfung der Akzeptanz des “none”-Algorithmus in allen Umgebungen
Prüfung der Sensitivität des Schlüssel-Formats, um Sicherheitslücken zu vermeiden

Sicherheitstools

jwt_tool: Umfassendes JWT-Test-Toolkit
Burp Suite: Webanwendungssicherheitstests mit JWT-Erweiterungen
OWASP ZAP: Open-Source-Sicherheitsscanner mit JWT-Unterstützung
Eigene Skripte: Python- oder Node.js-Skripte für spezielle Tests

Der breitere Kontext: JWT-Sicherheitslandschaft

Algorithmus-Verwirrung ist nur eine von mehreren Schwachstellen bei JWTs, gegen die Anwendungen sich schützen müssen:

Schwache Geheimnisse: Brute-Force-Angriffe auf HMAC-Geheimnisse
Fehlende Signaturüberprüfung: Akzeptieren unsignierter Tokens
Token-Leakage: Offenlegung durch Logs, URLs oder clientseitige Speicherung
Replay-Angriffe: Wiederverwendung abgefangener Tokens
JKU/X5U-Injektion: Manipulation von Header-Parametern
Kid-Injektion: Pfadüberlauf durch Schlüssel-Identifikator

JWTs sind nicht per se sicher, nur weil sie JWTs sind; es kommt auf die Nutzung an, ob sie sicher sind oder nicht.

Fazit: Wachsamkeit ist essenziell

JWT-Algorithmus-Verwirrung stellt eine kritische Sicherheitslücke dar, die große Bibliotheken betroffen hat und in neuen Implementierungen weiterhin auftaucht. Der Angriff nutzt ein grundlegendes Vertrauensproblem aus: Das Zulassen unüberprüfter Tokens, die vorgeben, wie sie verifiziert werden sollen.

Vertrauen Sie niemals dem “alg”-Feld im JWT selbst und erzwingen Sie den erwarteten Algorithmus auf Konfigurationsebene. Durch explizite Algorithmus-Validierung, Verwendung algorithmusspezifischer Verifizierungsmethoden und Befolgung bewährter Sicherheitspraktiken können Entwickler ihre Anwendungen vor diesem verheerenden Angriffsvektor schützen.

Der wichtigste Grundsatz: Vertrauen Sie niemals Benutzereingaben, insbesondere wenn sie sicherheitskritische Operationen bestimmen. Das “alg”-Feld im JWT-Header ist benutzerkontrollierte Eingabe aus einer unüberprüften Quelle. Behandeln Sie es mit derselben Skepsis wie jede andere untrustworthy Eingabe und setzen Sie Ihre Sicherheitsrichtlinien immer explizit im Code durch.

Da Authentifizierungsmechanismen sich weiterentwickeln, ist es unerlässlich, über Schwachstellen wie Algorithmus-Verwirrung informiert zu bleiben und Verteidigungsstrategien in der Tiefe umzusetzen. Regelmäßige Sicherheitsüberprüfungen, Entwickler-Schulungen und proaktives Monitoring sind die Grundpfeiler einer robusten JWT-Sicherheitsstrategie.

Ressourcen für weiterführende Informationen:

OWASP JWT Security Cheat Sheet
RFC 7519: JSON Web Token (JWT)
RFC 8725: JWT Best Current Practices
PortSwigger Web Security Academy: JWT-Angriffe
Burp Suite JWT Testing Tools

Bleiben Sie sicher, prüfen Sie explizit und vertrauen Sie niemals dem algorithmus-Header! 🔒