API AUTHENTICATION ATTACKS

Técnicas para averiguar usuarios y credenciales de autenticación. Estas incluyen técnicas como Brute Forcing (con
codificación en base 64) and Password Spraying. Las API RESTful (REST: arquitectura de intercambio de información
por HTTP a través de verbos GET, POST, PUT, etc.) no mantienen un estado, por lo que si la API utilizara la
autenticación básica en todos los puntos finales, habría que emitir un nombre de usuario y una contraseña cada vez.
En su lugar, el proveedor puede utilizar la autenticación básica una vez utilizando un portal de autenticación, y
después de proporcionar las credenciales correctas, se emitiría un token que se utilizaría en las solicitudes
posteriores.
PASSWORD BRUTE-FORCE ATTACKS
Es una de las técnicas de obtención de credenciales, es similar a la fuerza bruta en otros servicios, solo que en API
enviarás una petición a un API endpoint (el payload suele estar en JSON) y los valores de autenticación deberán
estar codificados en base 64.

1. Generar contraseñas: podemos sacar ventaja de vulnerabilidades como ‘Excessive Data Exposure’ para crear una
lista de usuarios y contraseñas.
2. Herramientas a usar: Burp Suite’s Intruder o Wfuzz.

BURP SUITE
Utilizaremos la extensión INTRUDER de BurpSuite para enviar un payload que fuerce las contraseñas. Podremos
utilizar el Cluster Bomb attack (varias posiciones a las que hacer el ataque: email & contraseña).

A la hora de usar el Payload, quitar el Payload Encoding.

WFUZZ
Entre los elementos importantes a tener en cuenta para las pruebas de API se incluyen la opción de cabeceras (-H),
ocultar respuestas (--hc, --hl, --hw, --hh) y las peticiones POST body (-d), lo que permite fuzzear el contenido enviado
en la petición POST. Todas estas opciones serán útiles a la hora de comprobar APIs. Tendremos que especificar las
cabeceras de tipo de contenido para las API, que serán "Content-Type: application/json" para crAPI. El cuerpo POST
para el login de crAPI es '{"email": "a@email.com", "password": "FUZZ"}'. Observa que FUZZ es la posición de ataque
de WFuzz. Finalmente, si estamos recibiendo muchas respuestas irrelevantes podemos limpiar nuestro ataque
ocultando ciertas respuestas.

- Comando: wfuzz -d '{"email":"a@email.com","password":"FUZZ"}' -H 'Content-Type: application/json' -z file(el

payload va a ser un fichero),/usr/share/wordlists/rockyou.txt -u http://127.0.0.1:8888/identity/api/auth/login --
hc 405 ================================================================== ID Response Lines Word
Chars Payload ==================================================================
000000007: 200 0 L 1 W 225 Ch "Password1!" 000000005: 400 0 L 34 W 474 Ch "win"

La opción -d permite filtrar el contenido que se envía en el cuerpo de una solicitud POST. Las llaves que siguen
contienen el cuerpo de la petición POST.

Para descubrir el formato de solicitud utilizado en este ejemplo, intenté autenticarme en una aplicación web
utilizando un navegador y, a continuación, capturé el intento de autenticación y reproduje su estructura aquí. En este
caso, la aplicación web emite una petición POST con los parámetros "email" y "password". La estructura de este
cuerpo cambiará para cada API. En este ejemplo, puedes ver que hemos especificado un correo electrónico conocido
y utilizado el parámetro FUZZ como contraseña (si tenemos más parámetros, como email/usuario/id, se indica con
FUZnZ, siendo n el número de parámetro). La opción --hc oculta las respuestas con determinados códigos de
respuesta. Esto es útil si a menudo recibe el mismo código de estado, longitud de palabra y número de caracteres en
muchas peticiones. Si sabe cómo es una respuesta típica de fallo para su objetivo, no hay necesidad de ver cientos o
miles de esa misma respuesta. La opción -hc le ayuda a filtrar las respuestas que no desea ver. En la instancia
probada, la solicitud típica que falla da como resultado un código de estado 405, pero esto también puede diferir con
cada API. A continuación, la opción -H le permite añadir una cabecera a la solicitud. Algunos proveedores de API
pueden responder con un código de error HTTP 415 Unsupported Media Type si no incluye la cabecera Content -
Type:application/json al enviar datos JSON en el cuerpo de la solicitud. Una vez enviada la solicitud, puede revisar
los resultados en la línea de comandos. Si su opción -hc Wfuzz ha funcionado, sus resultados deberían ser bastante
fáciles de leer. De lo contrario, los códigos de estado 200 y 300 deberían ser buenos indicadores de que has forzado
las credenciales con éxito.
PASSWORD SPRAYING
Muchos controles de seguridad pueden impedirte forzar la autenticación de una API. Una técnica llamada
pulverización de contraseñas puede evadir muchos de estos controles combinando una larga lista de usuarios con
una corta lista de contraseñas objetivo.

Ejemplo: Digamos que sabes que el proceso de autenticación de una API tiene una política de bloqueo y sólo permite
10 intentos de inicio de sesión. Podrías elaborar una lista de las nueve contraseñas más probables (una contraseña
menos que el límite) y utilizarlas para intentar iniciar sesión en muchas cuentas de usuario. Cuando estés rociando
contraseñas, las listas de palabras grandes y obsoletas como rockyou.txt no funcionarán. Hay demasiadas
contraseñas improbables en ese archivo como para tener éxito. En su lugar, elabora una lista corta de contraseñas
probables, teniendo en cuenta las restricciones de la política de contraseñas del proveedor de la API, que puedes
descubrir durante el reconocimiento. La mayoría de las políticas de contraseñas probablemente requieren una
longitud mínima de caracteres, letras mayúsculas y minúsculas, y tal vez un número o carácter especial. Utilice
contraseñas que sean lo suficientemente sencillas de adivinar, pero lo suficientemente complejas como para cumplir
los requisitos básicos de las contraseñas (por lo general, un mínimo de ocho caracteres, un símbolo, letras
mayúsculas y minúsculas y un número). El primer tipo incluye contraseñas obvias como QWER!@#$, Password1! y la
fórmula Season+Year+Symbol (como Winter2021!, Spring2021?, Fall2021! y Autumn2021?). El segundo tipo incluye
contraseñas más avanzadas que se relacionan directamente con el objetivo, a menudo incluyendo una letra
mayúscula, un número, un detalle sobre la organización y un símbolo.

La verdadera clave de la pulverización de contraseñas es maximizar tu lista de usuarios. Cuantos más nombres de
usuario incluyas, mayores serán tus probabilidades de comprometer una cuenta de usuario con una contraseña
incorrecta. Construye una lista de usuarios durante tus esfuerzos de reconocimiento o descubriendo vulnerabilidades
de exposición de datos excesivas.

CRAPI: en la parte de comunidad de CRAPI (en POSTMAN) podemos encontrar excesiva exposición de datos de otros
usuarios, pudiendo redactar una lista de usuarios.

Guardamos la respuesta como: response.json

GREP
Usamos grep para conseguir expresiones regulares y obtener los e-mails, y los convertimos en un fichero nuevo:
grep -oe "[a-zA-Z0-9._]\+@[a-zA-Z]\+.[a-zA-Z]\+" response.json > crapiusers.

Entre comillas se sitúa el formato de correo electrónico: [letras+números] + @ + [dominio] + [letras]

El uso de este comando grep debería sacar todo lo que se parezca a un correo electrónico de un archivo. A
continuación, puede guardar los correos electrónicos capturados en un archivo y utilizar ese archivo como carga útil
en Burp Suite. A continuación, puede utilizar un comando como sort -u para deshacerse de los correos electrónicos
duplicados.

Lanzamos el ataque en el Intruder de BurpSuite con esa lista de e-mails, para hallar cuales son reales y cuales no.

CURL: confirmar que el status 200 sea correcto, es decir, que permita hacer el login.
curl -X POST -d '{
"email":"savanna48@ortiz.com",
"password":"zTyBwV/9"}' -H "Content-Type: application/json" http://127.0.0.1/vapi/api2/user/login.
{"success":"true","token":"Fp0r1mty_gxK9DRZ5IUw3sX2enQ6rau68M6YGyoqR3XoBG13wtSbvmdaK5CB"}.
NOTE ON BASE64 ENCODING
Algunas API codifican en base64 las cargas útiles de autenticación enviadas en una solicitud de API. Hay muchas
razones para hacer esto, pero es importante saber que la seguridad no es una de ellas. Puedes evitar fácilmente este
pequeño inconveniente. Si pruebas un intento de autenticación y notas que una API está codificando en base64, es
probable que esté haciendo una comparación con credenciales codificadas en base64 en el backend. Esto significa
que deberías ajustar tus ataques de fuzzing para incluir cargas base64 usando Burp Suite Intruder, que puede tanto
codificar como decodificar valores base64.

Puede decodificarlos resaltando la carga útil, haciendo clic con el botón derecho y seleccionando Base64-decode (o
el atajo de teclado CTRL-SHIFT-B). Esto revelará la carga útil para que puedas ver cómo está formateada. Para realizar,
por ejemplo, un ataque de pulverización de contraseñas utilizando la codificación base64, comience seleccionando
las posiciones de ataque. En este caso, seleccionaremos la contraseña codificada en base64 de la petición. A
continuación, añade el conjunto de carga útil; utilizaremos las contraseñas enumeradas en la sección anterior.
Ahora, para codificar cada contraseña antes de enviarla en una petición, debemos utilizar una regla de
procesamiento de carga útil. En la pestaña Payloads hay una opción para añadir una regla de este tipo. Seleccione
Add>Encoded>Base64-encode y haga clic en OK. La ventana de procesamiento de la carga útil debería tener este
aspecto.

Una vez que la regla de procesamiento de la carga útil está en su lugar, puede realizar un ataque con normalidad.
Cuando esté revisando resultados anómalos, puede utilizar simplemente CTRL+Mayús+B o utilizar la opción de
convertir selección resaltando y haciendo clic con el botón derecho en la carga útil.

FFUF: herramienta similar a WFUZZ (más completa). https://www.tsustyle.com/cheatsheets/ffuf-cheatsheet/

Ejemplo: ffuf -w /home/hapihacker/Escritorio/users:HFUZZ -w /home/hapihacker/Escritorio/pass:WFUZZ -X POST
-d '{"email":"HFUZZ", "password":"WFUZZ"}' -u http://vapi.apisec.ai/vapi/api2/user/login -fc 401 -mode pitchfork
-request-proto http -H "Accept: application/json".
 API TOKENS ATTACKS
TOKEN ANALYSIS
Cuando se implementan correctamente, los tokens pueden ser una herramienta excelente para autenticar y autorizar
usuarios. Sin embargo, si algo sale mal al generar, procesar o manejar los tokens, pueden convertirse en nuestras
llaves del reino.

En esta sección, echaremos un vistazo al proceso que se puede utilizar con Burp Suite para analizar tokens. Usar este
proceso puede ayudarle a identificar tokens predecibles y ayudar en ataques de falsificación de tokens.

Para analizar los tokens tomaremos nuestra solicitud de autenticación de la API crAPI y la enviaremos a Burp Suite.

A continuación, tendremos que hacer clic con el botón derecho del ratón sobre la petición y reenviarla a Sequencer.
En Sequencer, podremos hacer que Burp Suite envíe miles de solicitudes al proveedor y realice un análisis de los
tokens recibidos como respuesta. Este análisis podría demostrar que se está utilizando un proceso de creación de
tokens débil.

Navegue a la pestaña Secuenciador y seleccione la solicitud que reenvió. Aquí podemos usar la Captura en Vivo para
interactuar con el objetivo y obtener tokens en vivo de vuelta en una respuesta para ser analizada. Para que este
proceso funcione, necesitará definir la ubicación personalizada del token dentro de la respuesta. Seleccione el
botón Configurar situado a la derecha de Ubicación personalizada. Resalte el token que se encuentra entre
comillas y haga clic en Aceptar.

Una vez definido el token, puede iniciar la captura en directo. En este punto, puede esperar a que la captura procese
miles de solicitudes o utilizar el botón Analizar ahora para ver los resultados antes.
El uso de Sequencer contra crAPI muestra que los tokens generados parecen tener suficiente aleatoriedad y
complejidad como para no ser predecibles. Sólo porque tu objetivo te envíe un token aparentemente complejo, no
significa que esté a salvo de la falsificación de tokens. Sequencer es excelente para mostrar que algunos tokens
complejos son en realidad muy predecibles. Si un proveedor de API está generando tokens secuencialmente, incluso
si el token tuviera más de 20 caracteres, podría darse el caso de que muchos de los caracteres del token no
cambiaran realmente. Esto hace que sea fácil predecir y crear nuestros propios tokens válidos.

Para ver qué aspecto tiene un análisis de un proceso de generación de tokens deficiente, realiza un análisis de los
"bad tokens" que se encuentran en el repositorio de Github de Hacking APIs
(https://raw.githubusercontent.com/hAPI-hacker/Hacking-APIs/main/bad_tokens). En esta ocasión utilizaremos la
opción de carga Manual, para proporcionar nuestro propio conjunto de tokens malos.
Si utiliza el botón Analizar ahora y deja que Sequencer ejecute su análisis. Compruebe el análisis a nivel de
caracteres, que revela que el token alfanumérico 12 utiliza los mismos caracteres para las 8 primeras posiciones.
Los tres caracteres finales de estos tokens presentan alguna variación. Tomando nota de los tres caracteres finales de
estos tokens se puede observar que las posibilidades consisten en dos letras minúsculas seguidas de un número
(aa#). Con esta información, podrías forzar todas las posibilidades en menos de 7.000 peticiones. Luego puedes
tomar estos tokens y hacer peticiones a un endpoint como /identity/api/v2/user/dashboard. Basándote en los
resultados de tus peticiones, busca entre los nombres de usuario y correos electrónicos para encontrar usuarios a los
que te gustaría atacar.
JWT ATTACKS
Los tokens web JSON (JWT) son uno de los tipos de token de API más frecuentes porque funcionan en una amplia
variedad de lenguajes de programación, como Python, Java, Node.js y Ruby. Estos tokens son susceptibles a todo tipo
de errores de configuración que pueden dejarlos vulnerables a varios ataques adicionales. Estos ataques podrían
proporcionarle información sensible, concederle acceso básico no autorizado o incluso acceso administrativo a una
API.

Los JWT constan de tres partes, todas ellas codificadas en base64 y separadas por puntos: la cabecera, la carga útil y
la firma. JWT.io es un depurador JWT web gratuito que puedes utilizar para comprobar estos tokens. Puede
reconocer un JWT porque consta de tres puntos y empieza por "ey". Empiezan por "ey" porque eso es lo que ocurre
cuando codificas en base64 una llave seguida de una comilla, que es como empieza siempre un JWT descodificado.

Ejemplo:

Podemos tomar este JWT y decodificar las partes individuales. La cabecera es el primer segmento. Puedes
simplemente hacer eco de esa parte del token y decodificarla en base64 para ver qué contiene la cabecera:

- Comando: echo eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9|base64 -d.

o Respuesta: {"alg":"HS256","typ":"JWT"}.

El algoritmo (alg) utilizado para este token es HS256 y el tipo de token (typ) es JWT. A continuación, podemos hacer
lo mismo con el payload:

- Comando: echo eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6ImhhcGloYWNrZXIiLCJpYXQiOjE1MTYyMzkwMjJ9|

base64 -d.
o Respuesta: {"sub":"1234567890","name":"hapihacker","iat":1516239022}.

Ahora, este token sólo contiene el sujeto (sub), el nombre de usuario (name) y la hora a la que se emitió el token
(iat). Más información podría estar contenida en el cuerpo, de hecho, cualquier cosa que el proveedor quisiera
añadir aquí puede hacerlo. El cuerpo de un JWT puede ser una gran fuente de revelación de información. Considera
un JWT que contiene el nombre de usuario, email, contraseña y rol, todo escondido detrás de una decodificación
base64. Si ejecutamos el mismo comando para la firma JWT veremos lo siguiente:

- Comando: echo U1Agy_OvIULTQwBrYx0dlWVzcBqcI90no2pAcoy4-uo|base64 -d.

o Respuesta: SP base64: entrada no válida
Por último, la firma es la salida de HMAC utilizada para la validación de tokens y generada con el algoritmo
especificado en la cabecera. Para crear la firma, la API codifica en base64 la cabecera y la carga útil y, a
continuación, aplica el algoritmo hash y un secreto. El secreto puede ser una contraseña o una cadena secreta,
como una clave de 256 bits. Sin conocer el secreto, la carga útil del JWT permanecerá codificada.

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secreto)

Si quieres saber más sobre los JWT, consulta https://jwt.io/introduction.

Si has capturado el JWT de otro usuario o quizás has descubierto un token filtrado durante el reconocimiento,
puedes intentar enviarlo al proveedor y hacerlo pasar por el tuyo. Existe la posibilidad de que el token filtrado aún
no haya caducado y pueda hacerse pasar por el tuyo. Podrías utilizar este token en peticiones para obtener acceso a
la API como el usuario especificado en la carga útil. Sin embargo, lo más habitual es obtener un JWT autenticándose
en una API y que el proveedor responda con un JWT. Para obtener un JWT de crAPI, necesitaremos aprovechar
nuestra solicitud de autenticación.

En este ejemplo, podemos ver que el algoritmo está establecido en HS512, el email de nuestra cuenta, iat, exp, y la
firma actual no es válida. Si fuéramos capaces de comprometer el secreto de la firma entonces deberíamos ser
capaces de firmar nuestro propio JWT y potencialmente obtener acceso a la cuenta de cualquier usuario válido. A
continuación, aprenderemos a utilizar herramientas automatizadas para ayudarnos con varios ataques JWT.
JWT_TOOL
El JSON Web Token Toolkit o JWT_Tool es una gran herramienta de línea de comandos que podemos utilizar para
analizar y atacar JWTs. Con esto, seremos capaces de analizar JWTs, escanear en busca de debilidades, falsificar
tokens, y secretos de firma de fuerza bruta.

Para realizar un análisis de referencia de un JWT simplemente utilice jwt_tool junto con su JWT capturado para ver
información similar a la del depurador de JWT.

Como puedes ver, jwt_tool hace que los valores de la cabecera y la carga útil sean agradables y claros.
Adicionalmente, jwt_tool tiene un "Playbook Scan" que puede ser usado para apuntar a una aplicación web y
escanear vulnerabilidades JWT comunes. Puede ejecutar este escaneo utilizando lo siguiente:
- Comando: jwt_tool -t http://target-name.com/ -rh "Authorization: Bearer JWT_Token" -M pb.

Ejemplo. En el caso de crAPI ejecutaremos:

- Comando: jwt_tool -t http://127.0.0.1:8888/identity/api/v2/user/dashboard -rh "Authorization: Bearer
eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJ1c2VyYWFhQGVtYWlsLmNvbSIsImlhdCI6MTY1ODUwNjQ0NiwiZXhwIjoxNjU
4NTkyODQ2fQ.
BLMqSjLZQ9P2cxcUP5UCAmFKVMjxhlB4uVeIu2__6zoJCJoFnDqTqKxGfrMcq1lMW97HxBVDnYNC7eC-pl0XYQ" -
M pb.

Durante esta búsqueda de errores de configuración comunes, JWT_Tool comprobó las distintas afirmaciones
encontradas en el JWT (sub, iat, exp).

NONE ATTACK
Si alguna vez te encuentras con un JWT que utiliza "none" como algoritmo, has encontrado una victoria fácil.
Después de decodificar el token, deberías poder ver claramente la cabecera, la carga útil y la firma. A partir de
aquí, puedes alterar la información contenida en la carga útil para que sea lo que quieras. Por ejemplo, puedes
cambiar el nombre de usuario por algo que probablemente utilice la cuenta de administrador del proveedor (como
root, admin, administrator, test o adm), como se muestra aquí: { "nombre de usuario": "root", "iat": 1516239022 }
Una vez que haya editado el payload, utilice el Decodificador de Burp Suite para codificar el payload con base64;
luego insértelo en el JWT. Es importante destacar que, dado que el algoritmo está configurado como "none",
cualquier firma que estuviera presente puede ser eliminada. En otras palabras, se puede eliminar todo lo que sigue al
tercer punto en el JWT. Envía el JWT al proveedor en una solicitud y comprueba si has obtenido acceso no
autorizado a la API.
THE ALGORITHM SWITCH ATTACK
Existe la posibilidad de que el proveedor de la API no esté comprobando los JWT correctamente. Si este es el caso,
podemos ser capaces de engañar a un proveedor para que acepte un JWT con un algoritmo alterado. Una de las
primeras cosas que deberías intentar es enviar un JWT sin incluir la firma. Esto se puede hacer borrando la firma
por completo y dejando el último punto en su lugar, así:
eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJwYXVsMUBob3RtYWlsLmVzIiwiaWF0IjoxNjc0NjYwNDUyLCJleHAiOjE2NzQ3NDY
4NTJ9.QZb7l5A4KtmGZt9x2XjNxnEsAWBvAyRHrATol9t3vAnD3dwNhUfmMLUh8YL-
COoHGDecSmCkH7z2U5M3dpg02Q. Si no lo consigue, intente modificar el campo de cabecera del algoritmo a
"none". Decodifica el JWT, actualiza el valor "alg" a "none", codifica en base64 la cabecera y envíala al proveedor.
Para simplificar este proceso, también puede utilizar la herramienta jwt_tool para crear rápidamente un token con
el algoritmo cambiado a none.

- Comando: jwt_tool
eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJwYXVsMUBob3RtYWlsLmVzIiwiaWF0IjoxNjc0NjYwNDUyLCJleHAiOjE2NzQ3
NDY4NTJ9.QZb7l5A4KtmGZt9x2XjNxnEsAWBvAyRHrATol9t3vAnD3dwNhUfmMLUh8YL-
COoHGDecSmCkH7z2U5M3dpg02Q -X a.

Si tiene éxito, vuelve al NONE ATTACK. Sin embargo, si intentamos esto con crAPI, el ataque no tiene éxito. También
puedes usar JWT_Tool para crear un token none.

Un escenario más probable [CLAVE PÚBLICA NECESARIA] que el proveedor no acepte ningún algoritmo
es que acepte múltiples algoritmos. Por ejemplo, si el proveedor usa RS256 pero no limita los valores de algoritmo
aceptables, podríamos alterar el algoritmo a HS256. Esto es útil, ya que RS256 es un esquema de encriptación
asimétrico, lo que significa que necesitamos tanto la clave privada del proveedor como una clave pública para hacer
un hash preciso de la firma JWT. Mientras tanto, HS256 es un cifrado simétrico, por lo que sólo se utiliza una clave
tanto para la firma como para la verificación del token. Si puedes descubrir y obtener la clave pública RS256 del
proveedor y luego cambiar el algoritmo de RS256 a HS256, existe la posibilidad de que puedas aprovechar la clave
pública RS256 como clave HS256. Utiliza el formato jwt_tool TOKEN -X k -pk public-key.pem, como se muestra a
continuación. Necesitará guardar la clave pública capturada como un archivo en su máquina atacante (Puede
simular este ataque tomando cualquier clave pública y guardándola como public-key-pem).

- Comando: jwt_tool
eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiJwYXVsMUBob3RtYWlsLmVzIiwiaWF0IjoxNjc0NjYwNDUyLCJleHAiOjE2NzQ3
NDY4NTJ9.QZb7l5A4KtmGZt9x2XjNxnEsAWBvAyRHrATol9t3vAnD3dwNhUfmMLUh8YL-
COoHGDecSmCkH7z2U5M3dpg02Q -X k -pk public-key-pem.

Una vez que ejecutes el comando, JWT_Tool te proporcionará un nuevo token para utilizar contra el proveedor de
la API. Si el proveedor es vulnerable, podrás secuestrar otros tokens, ya que ahora tienes la clave necesaria para
firmar tokens. Intenta repetir el proceso, esta vez creando un nuevo token basado en otros usuarios de la API (otros
usuarios descubiertos o usuarios administradores genéricos).
JWT CRACK ATTACK
El ataque JWT Crack intenta descifrar el secreto utilizado para el hash de la firma JWT, dándonos el
control total sobre el proceso de creación de nuestros propios JWT válidos. Los ataques de descifrado de hash como
este tienen lugar fuera de línea y no interactúan con el proveedor. Por lo tanto, no tenemos que preocuparnos de
causar estragos enviando millones de peticiones a un proveedor de API. Puedes usar JWT_Tool o una herramienta
como Hashcat para crackear secretos JWT. Alimentarás a tu crackeador de hash con una lista de palabras. El
descifrador de hash hará un hash de esas palabras y comparará los valores con la firma hash original para determinar
si una de esas palabras se utilizó como secreto hash. Si vas a realizar un ataque de fuerza bruta a largo plazo de
todas las posibilidades de caracteres, es posible que desees utilizar las GPU dedicadas que alimentan Hashcat en
lugar de JWT_Tool. Dicho esto, JWT_Tool puede probar 12 millones de contraseñas en menos de un minuto.
Primero, usemos Crunch, una herramienta generadora de contraseñas, para crear una lista de todas las
combinaciones de caracteres posibles para usar contra crAPI.

- Comando: crunch 5 5 -o crAPIpw.txt.

Podemos utilizar este archivo de contraseñas que contiene todas las posibles combinaciones de caracteres creadas
para contraseñas de 5 caracteres contra nuestro token crAPI. Para realizar un ataque JWT Crack utilizando
JWT_Tool, utilice el siguiente comando: jwt_tool TOKEN -C -d /wordlist.txt. La opción -C indica que vas a realizar un
ataque de crackeo de hash, y la opción -d especifica el diccionario o lista de palabras que vas a utilizar contra el
hash. JWT_Tool devolverá "¡clave CORRECTA!" para cada valor del diccionario o indicará un intento fallido con "clave
no encontrada en el diccionario".
Ahora que tenemos la clave secreta correcta que se utiliza para firmar los tokens de crAPI, deberíamos ser capaces
de generar nuestros propios tokens de confianza. Para probar nuestras nuevas habilidades, puedes crear una
segunda cuenta de usuario en crAPI o utilizar un correo electrónico que ya hayas descubierto. Yo he creado una
cuenta llamada "superadmin".

Puede añadir su token de usuario al depurador JWT, añadir el secreto recién descubierto y actualizar la declaración
"sub" a cualquier correo electrónico que se haya registrado en crAPI.

Usa el token que generaste en el depurador y añádelo a tu Postman Collection. Haz una petición a un endpoint que
pruebe tu acceso como GET /identity/api/v2/user/dashboard.
 PRÁCTICA
FUERZA BRUTA AL LOGIN DEL USUARIO (http://vapi.apisec.ai/vapi/api2/user/login)
BURPSUITE (INTRUDER): a partir de wordlists de usuarios y contraseñas obtengo 3 correctas.

FFUF: también se podría hacer FUERZA BRUTA con esta herramienta.

ACCESO A DETALLES DEL USUARIO (http://vapi.apisec.ai/vapi/api2/user/details)
BURPSUITE (REPEATER). TOKEN {FLAG}: con el token obtenido valido la sesión para obtener la flag del reto.