lucastran05/cve-2023-48223Prueba de concepto que demuestra la confusión de algoritmo JWT en la librería fast-jwt. Incluye un servidor vulnerable, un script de falsificación de tokens y una corrección de verificación para educación en seguridad.
Este repositorio demuestra la confusión de algoritmos JWT en fast-jwt cuando la verificación del token no bloquea los algoritmos permitidos.
Desde la raíz del proyecto, ejecuta:
npm install
La aplicación espera estos archivos:
keys/private.pemkeys/public.pemEjecuta uno de los siguientes conjuntos de comandos.
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
Salida esperada:
Server running at http://localhost:3000
curl http://localhost:3000/generateToken
node sign.js
Copia el token impreso.
node checkAdmin.js <JWT_TOKEN>
Si el ataque tiene éxito, la respuesta contiene Welcome Admin!.
En server.js, el verificador no restringe algoritmos:
const verifySync = createVerifier({
key: publicKey,
});
Sin una lista blanca de algoritmos, el servidor puede aceptar un token HS256 malicioso firmado usando la clave pública como secreto HMAC.
En las demostraciones de CVE del grupo, el objeto vulnerable es la biblioteca (no puede ejecutarse de forma independiente). Por lo tanto, se necesita una aplicación simulada para emular cómo un sistema real llama a la API de esa biblioteca. En este repositorio, el archivo server.js es la capa de aplicación simulada.
createSigner de fast-jwt con RS256 para crear un token válido para un usuario normal (admin=false). El propósito es crear un token base "normal" para comparar con el token falsificado.createVerifier de fast-jwt para verificar el token y decide el permiso de administrador según payload.admin. El punto intencionalmente vulnerable es que el verificador no bloquea algoritmos, lo que lleva a una confusión de algoritmos.El flujo de código complementario del PoC es:
createSigner con HS256 y usa la clave pública como secreto para firmar un token falso (admin=true).En resumen, el grupo no reescribe funciones de la biblioteca. Solo utiliza las API originales de la biblioteca vulnerable (createSigner, createVerifier) dentro de la aplicación simulada para recrear correctamente el contexto de explotación.
Restringir la verificación a RS256:
const verifySync = createVerifier({
key: publicKey,
algorithms: ["RS256"],
});
Este proyecto es únicamente para aprendizaje de seguridad en un entorno de laboratorio controlado.