lucastran05/cve-2023-48223Preuve de concept démontrant la confusion d'algorithme JWT dans la bibliothèque fast-jwt. Comprend un serveur vulnérable, un script de falsification de jetons et une correction de vérification pour l'éducation à la sécurité.
Ce dépôt démontre une confusion d'algorithme JWT dans fast-jwt lorsque la vérification du token ne verrouille pas les algorithmes autorisés.
Depuis la racine du projet, exécutez :
npm install
L'application attend ces fichiers :
keys/private.pemkeys/public.pemExécutez l'un des jeux de commandes suivants.
PowerShell (Windows) :
New-Item -ItemType Directory -Path keys -Force | Out-Null
openssl genrsa -out keys/private.pem 2048
openssl rsa -in keys/private.pem -RSAPublicKey_out -out keys/public.pem
Linux/macOS/Git Bash :
mkdir -p keys
openssl genrsa -out keys/private.pem 2048
openssl rsa -in keys/private.pem -RSAPublicKey_out -out keys/public.pem
node server.js
Sortie attendue :
Server running at http://localhost:3000
curl http://localhost:3000/generateToken
node sign.js
Copiez le token affiché.
node checkAdmin.js <JWT_TOKEN>
Si l'attaque réussit, la réponse contient Welcome Admin!.
Dans server.js, le vérificateur ne restreint pas les algorithmes :
const verifySync = createVerifier({
key: publicKey,
});
Sans une liste blanche d'algorithmes, le serveur peut accepter un token HS256 malveillant signé en utilisant la clé publique comme secret HMAC.
Dans les démonstrations CVE de notre groupe, l'objet vulnérable est la bibliothèque (elle ne peut pas être exécutée de manière indépendante). Il est donc nécessaire d'utiliser une application simulée pour reproduire la manière dont un système réel appelle l'API de cette bibliothèque. Dans ce dépôt, le fichier server.js est la couche applicative de simulation.
createSigner de fast-jwt avec RS256 pour générer un token valide pour un utilisateur normal (admin=false). Le but est de créer un token de base « normal » à comparer avec un token forgé.createVerifier de fast-jwt pour vérifier le token et déterminer le privilège admin selon payload.admin. Le point intentionnellement vulnérable se trouve dans le fait que le vérificateur ne verrouille pas les algorithmes, conduisant à une confusion d'algorithme.Code PoC auxiliaire :
createSigner avec HS256 et utilisant la clé publique comme secret pour signer un token falsifié (admin=true).En résumé, nous n'avons pas réécrit les fonctions de la bibliothèque. Nous utilisons simplement l'API originale de la bibliothèque vulnérable (createSigner, createVerifier) à l'intérieur de l'application simulée pour reproduire le contexte d'exploitation.
Restreindre la vérification à RS256 :
const verifySync = createVerifier({
key: publicKey,
algorithms: ["RS256"],
});
Ce projet est destiné à l'apprentissage de la sécurité dans un environnement de laboratoire contrôlé uniquement.