Bonjour à tous. Ce n'est un secret pour personne qu'OTUS lance chaque mois plusieurs cours entièrement nouveaux et uniques, ce mois-ci le
Pentest. Pratique des tests de pénétration .
" Selon une tradition bien établie, à la veille du début du cours, nous partageons avec vous la traduction de matériel utile dans ce sens.
Lors du dernier pentest, je suis tombé sur un schéma d'autorisation basé sur
JSON Web Token (ou simplement JWT). JWT se compose de trois parties: en-tête, charge utile, informations de vérification. La première partie de l'en-tête contient le nom de l'algorithme, qui sera utilisé ultérieurement pour la partie vérification du JWT. Ceci est dangereux car un attaquant peut modifier ces informations et ainsi (éventuellement) contrôler le schéma que le serveur utilisera pour la vérification.
Deux circuits sont couramment utilisés: RS256 (
algorithme de signature numérique ) et HS256 (
algorithme basé sur MAC ). Une option complètement dangereuse serait un schéma NULL: n'incluez pas du tout les informations de vérification - malheureusement, le schéma NULL n'a pas été accepté par le serveur Web cible.
Une petite variation sur l'attaque de
type confusion JWT, qui pourrait fonctionner si l'implémentation du serveur utilise une bibliothèque de validation qui appelle simplement du code comme verify (token, key) et suppose que seuls les jetons signés numériquement seront utilisés. Dans ce cas, le deuxième paramètre «clé» sera toujours public et sera présenté pour vérification (les signatures numériques utilisent la clé privée pour créer la signature et la clé publique correspondante pour vérifier la signature créée).
Désormais, l'attaquant peut obtenir la clé publique, créer un nouveau jeton basé sur MAC et l'utiliser pour créer une partie de la vérification de ce jeton. Dans un schéma basé sur MAC, seule une clé secrète est nécessaire pour créer des informations de vérification, et donc l'attaquant utilise une clé publique (signature numérique) comme clé secrète pour le MAC. Si ce jeton est maintenant transmis au serveur pour vérification, la bibliothèque identifie le schéma qui sera utilisé pour le jeton (qui a été défini par l'attaquant comme HS256, pointant vers le schéma MAC). La bibliothèque utilisera le deuxième paramètre comme entrée pour créer le MAC. Comme il s'agit d'une clé publique, le nouveau MAC correspond au MAC qui a été transmis aux attaquants, et comme ils correspondent, le serveur acceptera un faux jeton. Que doit donc faire le développeur de l'application? Si le jeton est accepté par le serveur, le serveur doit toujours vérifier si l'algorithme utilisé correspond à celui qui était initialement prévu par le développeur.
Théoriquement, cela devrait être facile à vérifier, mais je n'ai pas trouvé d'outil de travail. Par conséquent, j'ai moi-même écrit un script python. Pour l'utiliser, dans le code source, vous devez utiliser les configurations suivantes:
jwks_url : où puis-je obtenir des informations sur la clé publique. JWKS est utilisé par de nombreux services pour distribuer ouvertement des informations clés.operation_url : demande HTTP GET qui utilise un jeton JWT pour l'autorisation.token : un JWT valide pour une opération configurée.audience : audience pour laquelle le jeton a été configuré.
Le script fait ce qui suit:
- Téléchargez le fichier de configuration JWKS et récupérez les paramètres de clé publique. À partir de cela, une représentation pem est créée.
- Garantit que le jeton configuré peut être vérifié à l'aide de la clé publique extraite;
- Effectue une opération configurée avec un jeton valide et affiche le code d'état HTTP reçu et le document résultant (il est supposé que ce sera JSON).
- Crée un nouveau jeton basé sur le configuré. Dans le nouveau jeton, le type sera changé en HS256; Un MAC (basé sur une clé ouverte) sera calculé et utilisé comme information de vérification pour le jeton.
- Exécutez à nouveau l'opération configurée avec le jeton modifié et affichez le code d'état HTTP, ainsi que le document retourné.
Comme le code d'état de retour (avec un jeton modifié) était 401 (l'autorisation est interdite), les vérifications d'autorisation du côté du serveur cible ont fonctionné et, par conséquent, il n'a pas été compromis par l'attaque signature-vs-mac. Si cela fonctionnait, des codes d'état identiques et des documents résultants similaires seraient créés avec les deux appels HTTP (avec l'original ainsi qu'avec le jeton modifié).
J'espère que cet article vous aidera dans votre pratique pentest, utilisez le script python avec plaisir:
import jwt import requests from jwcrypto import jwk from cryptography.x509 import load_pem_x509_certificate from cryptography.hazmat.backends import default_backend
C’est tout. Nous attendons tous ceux qui ont lu jusqu'à la fin lors d'un webinaire gratuit sur le sujet:
"Comment commencer à trier
les bogues sur le Web .
"