# root-me.org JWT #1

### JSON Web Token (JWT) - Secret faible

###### Lien: https://www.root-me.org/fr/Challenges/Web-Serveur/JSON-Web-Token-JWT-Secret-faible

Quand on veut commencer le pentest, j'estime qu'il faut déjà avoir la culture de la recherche et surtout avec github. Sachez que tout ce qui a été déjà couvert (mais pas que) dispose de son propre Poc (Proof Of Concept) sur github. Et parfois il y a même des CLI tout prêts pour tester une multitude de vulnérabilités.

Dans notre cas, on va s'attaquer à une authentification par JWT (Json Web Token). Pour cela, j'ai trouvé le CLI python de ticarpi.

###### Lien: https://github.com/ticarpi/jwt_tool

Dans le challenge, il nous est fourni un JWT via le lien http://challenge01.root-me.org/web-serveur/ch59/token

et on va devoir s'identifier sur le dashboard à l'URL http://challenge01.root-me.org/web-serveur/ch59/admin en POST

Ici notre **JWT** est eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJyb2xlIjoiZ3Vlc3QifQ.4kBPNf7Y6BrtP-Y3A-vQXPY9jAh_d0E6L4IUjL65CvmEjgdTZyr2ag-TM-glH6EYKGgO3dBYbhblaPQsbeClcw

Le payload est donc:

  "role": "guest"
}

Récupérable avec plusieurs lib ou bien https://jwt.io/.

Dans notre cas on voit que la payload est très simple. Il nous suffirait de modifier la valeur du champ role et de POST sur le dashboard avec le nouveau token.

Mais pour **modifier le token** il va nous faloir récupérer la clef afin de signer le token et qu'il soit **validé par le serveur**.

Pour cela, comme nous le voyons avec le **CLI** récupéré sur github, il existe une multitude de possibilités. La plus évidente en regardant le nom du challenge "Secret faible" serait de **bruteforce la clef**.

*jwt_tool eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzUxMiJ9.eyJyb2xlIjoiZ3Vlc3QifQ.4kBPNf7Y6BrtP-Y3A-vQXPY9jAh_d0E6L4IUjL65CvmEjgdTZyr2ag-TM-glH6EYKGgO3dBYbhblaPQsbeClcw /wordlist.txt*

Et la, bingo ! Notre clef à été récupérée avec le bruteforce. Il faut dire qu'elle n'était pas compliquée. Pour éviter de me faire bannir de root-me en donnant le résultat, je vais simplement considérer que la clef était **ABC_KEY_EFG**.

Maintenant qu'on a la clef, on peut modifier le contenu de notre payload et la resigné avec une lib au choix, notre CLI ou même le site internet vu précédement.


Notre nouveau token **JWT modifié, signé et copié**. On peut l'envoyer en POST à l'aide de Postman et on aura le résultat de notre challenge (notre flag).


### Après la guerre ? La PAIX!

Maintenant que nous avons compris comment **bypass** une authentification JWT à l'aide du bruteforce que pouvons nous en conclure ?

Qu'il est intéressant d'utiliser ce moyen d'authentification car il est rapide a mettre en place et peu couteux niveau CPU au niveau du serveur. Mais qu'il n'en reste pas moins vulnérable aux attaques dites classiques.

Dans notre exemple le meilleur moyen de s'en protéger n'aurait pas été d'utiliser un algo de chiffrement différent ex RS256 ou RS512. Mais plutôt de choisir un secet/mot de passe de signature en concordance à la longueure de notre JWT. Un secret du style ***M6YDW5PR?91IRfW807ij6N?o8lqp!KipCK#nJvef*** aurait été bien plus puissant et long à craquer comme nous le montre cet exemple:

====ABC_KEY_EFG====: 

******
====Vrai mot de passe====