JWT

Stateful Authentication vs Stateless Authentication :

Stateful Authentication

Stateless Authentication

Attacking signature verification

Il existe plusieurs moyen :

• Le serveur ne vérifie pas la signature et bingo on peut tamper le JWT et il sera accepté

None Algorithm attack

• L'attaque None Algorithm qui va nous permettre de faire passer l'algorithme à None et la signature ne sera pas vérifier

Attacking the Signing Secret

JWT supports three symmetric algorithms based on potentially guessable secrets: HS256, HS384, and HS512.

Comment cracker le secret ?

En utilisant hashcat et une wordlist on peut :

hashcat -m 16500 jwt.txt /opt/SecLists/Passwords/Leaked-Databases/rockyou.txt
hashcat -m 16500 jwt.txt /usr/share/wordlists/rockyou.txt
hashcat -m 16500 jwt.txt /usr/share/wordlists/rockyou.txt --show
hashcat -m 16500 jwt.txt /opt/SecLists/Passwords/Leaked-Databases/rockyou.txt --show

On aurait pu aussi jwt_tools :

python3 jwt_tool.py JWT_HERE -C -d dictionary.txt

hashcat

jwttools

Algorithm confusion attack

La confusion d'algorithme est une attaque ciblant les JWT (JSON Web Tokens) qui oblige une application web à utiliser un algorithme différent pour vérifier la signature du JWT par rapport à celui utilisé pour le créer.

Principe de fonctionnement : Lorsqu'une application web utilise un algorithme asymétrique comme RS256, une clé privée est utilisée pour calculer la signature, tandis qu'une clé publique est employée pour vérifier cette signature. Ces clés sont différentes : la clé privée reste secrète, tandis que la clé publique est partagée.

Cependant, si un attaquant crée un token utilisant un algorithme symétrique comme HS256, la signature peut être vérifiée avec la même clé que celle utilisée pour signer le JWT. Si l'application web utilise la clé publique (destinée uniquement à la vérification) pour vérifier ces tokens symétriques, elle acceptera tout JWT signé avec cette clé publique. Comme cette clé publique est accessible à tous, l'attaquant peut créer un JWT valide en le signant avec cette clé.

Conditions de réussite de l'attaque :

• L'application web détermine l'algorithme à utiliser pour vérifier la signature en se basant uniquement sur la valeur de la revendication alg dans le JWT.

• L'application n'impose pas un algorithme spécifique pour vérifier les signatures.

Comment obtenir la clé publique

Elle est soit disponible dans les chemins suivant :

• jwks.json

• /.well-known/jwks.json

Si on la trouve pas on peut utiliser l'outil suivant qui se chargera de la retrouver à l'aide de deux JWT :

GitHub - silentsignal/rsa_sign2n: Deriving RSA public keys from message-signature pairsGitHub

Commande :

docker run -it sig2n /bin/bash
python3 jwt_forgery.py <jwt1> <jwt2>
cat cat <data>_x509.pem

L'outils ce qui est bien nous donne aussi des JWT qui sont tamper avec l'algo HS256 :

Du coup on a la clé publique on peut forger un JWT via cyberchef, à savoir on doit ajouter un \n à la fin de la clé :

Et boom ça fonctionne :

Réutilisation des secrets JWT

Lorsqu'une entreprise héberge plusieurs applications web utilisant des JWT (JSON Web Tokens) pour l'authentification, chaque application doit utiliser un secret de signature différent. Si ce n'est pas le cas, un attaquant pourrait réutiliser un JWT obtenu à partir d'une application web pour s'authentifier sur une autre. Cette situation est particulièrement préoccupante si l'une des applications accorde un niveau de privilège élevé et que ce niveau est encodé dans le JWT.

Exemple pratique : Supposons qu'une entreprise héberge deux réseaux sociaux distincts : socialA.htb et socialB.htb. De plus, un utilisateur est modérateur sur socialA, ce qui signifie que son JWT contient la revendication "role": "moderator". Cependant, sur socialB, cet utilisateur n'a aucun privilège particulier, et son JWT contient donc la revendication "role": "user". Si les deux réseaux sociaux utilisent le même secret JWT, l'utilisateur pourrait réutiliser son JWT de socialA sur socialB pour obtenir les privilèges de modérateur, créant ainsi une faille de sécurité majeure.

Exploiter les jwks

Injection de paramètres dans l’en-tête JWT

Selon la spécification JWS (JSON Web Signature), seul le paramètre d’en-tête alg est obligatoire. Toutefois, en pratique, les en-têtes JWT (souvent appelés en-têtes JOSE) contiennent fréquemment plusieurs autres paramètres. Certains de ces paramètres sont particulièrement intéressants pour les attaquants :

• jwk (JSON Web Key) : Permet d’intégrer un objet JSON représentant la clé directement dans le token.

• jku (JSON Web Key Set URL) : Fournit une URL permettant au serveur de récupérer un ensemble de clés contenant la clé correcte.

• kid (Key ID) : Fournit un identifiant permettant au serveur de choisir la clé appropriée parmi plusieurs clés disponibles. Ce paramètre peut correspondre à une valeur associée à la clé.

Ces paramètres, contrôlables par l’utilisateur, indiquent au serveur destinataire quelle clé utiliser pour vérifier la signature. En exploitant ces paramètres, un attaquant peut injecter des JWT modifiés et signés avec une clé arbitraire, au lieu d'utiliser le secret du serveur.

Injection de JWT auto-signés via le paramètre jwk

La spécification JWS décrit le paramètre d’en-tête optionnel jwk, qui permet au serveur d’intégrer sa clé publique directement dans le JWT, au format JSON Web Key (JWK).

Principe d’exploitation : Un attaquant peut créer un JWT contenant :

1. Une clé publique dans le paramètre jwk (qui correspond à une clé privée détenue par l'attaquant).

2. Une signature générée en utilisant la clé privée correspondante.

Lors de la vérification, si le serveur accepte et utilise la clé publique intégrée dans le JWT via jwk, l’attaquant peut faire valider des tokens qu’il a lui-même signés, permettant d’usurper des identités ou de contourner des mécanismes d’autorisation.