Breaking Token JWT or JWT Exposed !

Breaking Token JWT or JWT Exposed !



�Qu� es un TOKEN JWT?

Antes de nada vamos a explicar de que est� compuesto un Token JWT a trav�s de una revisi�n de las diferentes fuentes web graf�cas. 
Os dejo los diferentes enlaces a lo largo del texto, para que pod�is consultarlos. 

El funcionamiento de un Token JWT es el siguiente:  
"El usuario se autentica en nuestra aplicaci�n, bien con un par usuario/contrase�a, o a trav�s de un proveedor como puede ser Twitter, Facebook o Google por ejemplo. 
A partir de entonces, cada petici�n HTTP que haga el usuario va acompa�ada de un Token en la cabecera (Authentication: ). 
Este Token no es m�s que una firma cifrada que permite a nuestro API identificar al usuario. Pero este Token no se almacena en el servidor, si no en el lado del cliente (por ejemplo en localStorage o sessionStorage) y el API es el que se encarga de descrifrar ese Token y redirigir el flujo de la aplicaci�n en un sentido u otro. 
Como los tokens son almacenados en el lado del cliente, no hay informaci�n de estado y la aplicaci�n se vuelve totalmente escalable. 
Podemos usar el mismo API para diferentes apliaciones (Web, Mobile, Android, iOS, ...) solo debemos preocuparnos de enviar los datos en formato JSON y generar y descrifrar tokens en la autenticaci�n y posteriores peticiones HTTP a trav�s de un middleware
Tambi�n nos a�ade m�s seguridad. 
Al no utilizar cookies para almacenar la informaci�n del usuario, podemos evitar ataques CSRF (Cross-Site Request Forgery) que manipulen la sesi�n que se env�a al backend. Por supuesto podemos hacer que el token expire despu�s de un tiempo lo que le a�ade una capa extra de seguridad".

Bueno hasta este momento, la vida es maravillosa y todo es de color de rosa, pero vamos a profundizar un poco m�s.
El JWT consta de 3 partes separadas por puntos y codificadas en base64 (codificaci�n != encriptaci�n ) el Header, el Payload y la Signature, veamos que significa cada uno:

String completo:

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpZCI6MTAsInJvbCI6ImFkbWluIn0.Qrif0tQhNCnlL6iP3xoPz4vzpTtuQsfjkRjpe86gLZU

El Header  es la cabecera del token, que a su vez tiene otras dos partes, el tipo, en este caso un JWT y la codificaci�n utilizada.

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

El Payload est� compuesto por los llamados JWT Claims donde ir�n colocados la atributos que definen nuestro token.

  1. sub: Identifica el sujeto del token, por ejemplo un identificador de usuario.
  2. iat: Identifica la fecha de creaci�n del token, v�lido para si queremos ponerle una fecha de caducidad. En formato de tiempo UNIX
  3. exp: Identifica a la fecha de expiraci�n del token. Podemos calcularla a partir del iat. Tambi�n en formato de tiempo UNIX.

Estos atributos pueden variar, pod�is usarlos o no, la recomendaci�n es usarlos, pero como todo en la vida, es mi recomendaci�n.

�Qu� contiene el nuestro?

eyJpZCI6MTAsInJvbCI6ImFkbWluIn0 = {"id":10,"rol":"admin"} 

La firma, Signature, es la tercera y �ltima parte del JSON Web Token. Est� formada por los anteriores componentes, Header y Payload, codificados en Base64 y encriptada con una clave secreta que debe estar almacenada en nuestro backend. As� sirve de Hash para comprobar que todo est� bien.
En nuestro ejemplo ser�a:

Qrif0tQhNCnlL6iP3xoPz4vzpTtuQsfjkRjpe86

Si lo descodific�is sale algo ilegible as� que no los ahorramos.

*Antes de continuar, decir que la parte te�rica anterior es de https://carlosazaustre.es/blog/que-es-la-autenticacion-con-token/ que no quiero pisar el trabajo de nadie, ya que �l lo explica bastante bien.

�Y ahora qu�?

Aqu� es donde empieza el salseo.
Hace un tiempo salieron varias vulnerabilidades en JWT y entre otras la rotura de hmacsha256. �Entonces? Si podemos tener la clave secreta podremos crear token v�lidos para la aplicaci�n y as� poder validarnos con cualquier usuario.
�Sin user ni pass? El user normalmente lo tienes dentro del Payload (aunque no lo necesitas) y la pass no la necesitas teniendo un token v�lido.
�C�mo se hace esto? Vamos a verlo. Para ello he hecho este peque�o POC que va a simular lo explicado.

Lo primero es montar un framework el que quer�is, en mi caso codeignither, e integrar JWT (pod�is ver: https://github.com/ParitoshVaidya/CodeIgniter-JWT-Sample ), haciendo una API REST sencilla que genere un Token JWT y si le pasas un token te dice si es valido o no.

Lo primero generamos un token v�lido haciendo una petici�n GET a la API:


Bien, teniendo el token podemos descodificar la parte del Header y del Payload. 

Vamos ahora a modificarlo con https://jwt.io/ y ha intentar validarlo:


Como vemos, ya nos sale en rojo sanguinolento "Invalid Signature". Por tanto debemos conseguir la clave secreta, pero antes comprobemos nuestra API a ver si modificando y validando nos tirara una petici�n leg�tima. Por tanto cambiamos el rol por Pepe:


Se hace directamente en la web, y metemos el token en nuestra API mediante una petici�n POST y el Token en la cabecera AUTHORIZATION:


Como era de esperar nos peta, ya que no ha sido creado con la clave secreta de nuestro servidor, por lo tanto no va a ser v�lida. Para que sea v�lida debemos de obtener la clave, para ello vamos a obtenerla por fuerza bruta sin diccionario.

Vamos a usar una herramienta llamada jwt-cracker descargada de (https://www.npmjs.com/package/jwt-cracker), metemos el string completo de la siguiente manera: 

* En nuestro caso sabemos que la longitud es de 4 caracteres en min�sculas, sino se conociera por defecto usa 12, pero nos llevar�a m�s tiempo.


Le damos al enter. En este caso en pocos segundos lo saca:


Se ve claramente la contrase�a secreta obtenida y entonces ahora mediante la web https://jwt.io/ podemos crear el token v�lido.

Ahora, lo hacemos como antes pero metiendo la clave correcta y ponemos de nuevo Pepe:


Validamos en nuestra API el token 


Ahora si vemos como el token fue validado y obtenemos el rol de Pepe, y as� de f�cil es, tambi�n tenemos esta herramienta para ataques por diccionario, por si por fuerza bruta se os eternizara: https://github.com/Sjord/jwtcrack .

Soluci�n para que no pase esto, utilizar algoritmos RS256 (RSA Signature with SHA-256) o superior para generar el token JWT , ya que ha d�a de hoy todav�a es seguro, y JWT tiene soporte para ello. 
M�s info sobre esto: https://connect2id.com/products/nimbus-jose-jwt/examples/jwt-with-rsa-signature

Bueno espero que este POC os haya gustado y sirva para vuestras pruebas/auditorias, siempre dentro de un entorno controlado y de pruebas xDDD

Un saludo. 


download file now