<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Expert en équipe rouge AWS de HackTricks)</strong></a><strong>!</strong></summary>
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF**, consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Rejoignez le** 💬 [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
Si vous êtes intéressé par une **carrière en piratage** et pirater l'impossible - **nous recrutons !** (_maîtrise du polonais écrit et parlé requise_).
**Une partie de ce post est basée sur l'excellent post :** [**https://github.com/ticarpi/jwt\_tool/wiki/Attack-Methodology**](https://github.com/ticarpi/jwt\_tool/wiki/Attack-Methodology)\
Vous pouvez simplement manipuler les données en laissant la signature telle quelle et vérifier si le serveur vérifie la signature. Essayez par exemple de changer votre nom d'utilisateur en "admin".
Utilisez l'extension Burp appelée "JSON Web Token" pour tester cette vulnérabilité et modifier différentes valeurs à l'intérieur du JWT (envoyez la requête à Repeater et dans l'onglet "JSON Web Token" vous pouvez modifier les valeurs du jeton. Vous pouvez également choisir de mettre la valeur du champ "Alg" à "None").
Si vous changez l'algorithme de RS256 à HS256, le code côté serveur utilise la clé publique comme clé secrète, puis utilise l'algorithme HS256 pour vérifier la signature.
Ensuite, en utilisant la clé publique et en changeant RS256 en HS256, nous pourrions créer une signature valide. Vous pouvez récupérer le certificat du serveur web exécutant ceci :
openssl s_client -connect example.com:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > certificatechain.pem #For this attack you can use the JOSEPH Burp extension. In the Repeater, select the JWS tab and select the Key confusion attack. Load the PEM, Update the request and send it. (This extension allows you to send the "non" algorithm attack also). It is also recommended to use the tool jwt_tool with the option 2 as the previous Burp Extension does not always works well.
Les instructions détaillent une méthode pour évaluer la sécurité des jetons JWT, en particulier ceux utilisant une revendication d'en-tête "jku". Cette revendication devrait être liée à un fichier JWKS (JSON Web Key Set) contenant la clé publique nécessaire à la vérification du jeton.
* Lors de l'utilisation de `jwt_tool` pour ce processus, il est crucial de mettre à jour le fichier `jwtconf.ini` avec l'emplacement de votre JWKS personnel pour faciliter les tests.
* **Commande pour `jwt_tool`**:
* Exécutez la commande suivante pour simuler le scénario avec `jwt_tool`:
Une revendication d'en-tête facultative appelée `kid` est utilisée pour identifier une clé spécifique, ce qui devient particulièrement vital dans les environnements où plusieurs clés existent pour la vérification de la signature du jeton. Cette revendication aide à sélectionner la clé appropriée pour vérifier la signature d'un jeton.
Lorsque la revendication `kid` est présente dans l'en-tête, il est conseillé de rechercher le répertoire web pour le fichier correspondant ou ses variations. Par exemple, si `"kid":"key/12345"` est spécifié, les fichiers _/key/12345_ et _/key/12345.pem_ devraient être recherchés dans la racine du site web.
La revendication `kid` peut également être exploitée pour naviguer à travers le système de fichiers, permettant potentiellement la sélection d'un fichier arbitraire. Il est possible de tester la connectivité ou d'exécuter des attaques de falsification de requête côté serveur (SSRF) en modifiant la valeur `kid` pour cibler des fichiers ou des services spécifiques. La manipulation du JWT pour changer la valeur `kid` tout en conservant la signature d'origine peut être réalisée en utilisant le drapeau `-T` dans jwt\_tool, comme démontré ci-dessous:
En ciblant des fichiers avec un contenu prévisible, il est possible de falsifier un JWT valide. Par exemple, le fichier `/proc/sys/kernel/randomize_va_space` dans les systèmes Linux, connu pour contenir la valeur **2**, peut être utilisé dans le paramètre `kid` avec **2** comme mot de passe symétrique pour la génération de JWT.
Si le contenu de la revendication `kid` est utilisé pour récupérer un mot de passe depuis une base de données, une injection SQL pourrait être facilitée en modifiant la charge utile de `kid`. Un exemple de charge utile qui utilise une injection SQL pour modifier le processus de signature JWT est :
Un scénario où le paramètre `kid` spécifie un chemin de fichier utilisé dans un contexte d'exécution de commande pourrait entraîner des vulnérabilités d'exécution de code à distance (RCE). En injectant des commandes dans le paramètre `kid`, il est possible d'exposer des clés privées. Un exemple de charge utile pour atteindre une RCE et l'exposition de clés est :
Si le jeton utilise une revendication d'en-tête "**jku**", **vérifiez l'URL fournie**. Cela devrait pointer vers une URL contenant le fichier JWKS qui détient la clé publique pour vérifier le jeton. Manipulez le jeton pour pointer la valeur jku vers un service Web dont vous pouvez surveiller le trafic.
Ensuite, vous pouvez utiliser par exemple [**jwt.io**](https://jwt.io) pour créer le nouveau JWT avec les **clés publiques et privées créées et en pointant le paramètre jku vers le certificat créé.** Pour créer un certificat jku valide, vous pouvez télécharger l'original et modifier les paramètres nécessaires.
X.509 URL. Un URI pointant vers un ensemble de certificats publics X.509 (un standard de format de certificat) encodés sous forme PEM. Le premier certificat de l'ensemble doit être celui utilisé pour signer ce JWT. Les certificats suivants signent chacun le précédent, complétant ainsi la chaîne de certificats. X.509 est défini dans la RFC 52807. Une sécurité de transport est requise pour transférer les certificats.
Essayez de **modifier cet en-tête pour qu'il pointe vers une URL sous votre contrôle** et vérifiez si une requête est reçue. Dans ce cas, vous **pourriez altérer le JWT**.
Ensuite, vous pouvez utiliser par exemple [**jwt.io**](https://jwt.io) pour créer le nouveau JWT avec les **clés publiques et privées créées et en pointant le paramètre x5u vers le certificat .crt créé**.
Si l'attaquant **génère un certificat auto-signé** et crée un jeton falsifié en utilisant la clé privée correspondante et remplace la valeur du paramètre "x5c" par le certificat nouvellement généré et modifie les autres paramètres, à savoir n, e et x5t, alors essentiellement le jeton falsifié serait accepté par le serveur.
n ="ANQ3hoFoDxGQMhYOAc6CHmzz6_Z20hiP1Nvl1IN6phLwBj5gLei3e4e-DDmdwQ1zOueacCun0DkX1gMtTTX36jR8CnoBRBUTmNsQ7zaL3jIU4iXeYGuy7WPZ_TQEuAO1ogVQudn2zTXEiQeh-58tuPeTVpKmqZdS3Mpum3l72GHBbqggo_1h3cyvW4j3QM49YbV35aHV3WbwZJXPzWcDoEnCM4EwnqJiKeSpxvaClxQ5nQo3h2WdnV03C5WuLWaBNhDfC_HItdcaZ3pjImAjo4jkkej6mW3eXqtmDX39uZUyvwBzreMWh6uOu9W0DMdGBbfNNWcaR5tSZEGGj2divE8";
e = "AQAB";
const key = new NodeRSA();
var importedKey = key.importKey({n: Buffer.from(n, 'base64'),e: Buffer.from(e, 'base64'),}, 'components-public');
Il est possible de générer une nouvelle clé privée/publique, d'incorporer la nouvelle clé publique à l'intérieur du jeton et l'utiliser pour générer une nouvelle signature :
Enfin, en utilisant la clé publique et privée et les nouvelles valeurs "n" et "e", vous pouvez utiliser [jwt.io](https://jwt.io) pour forger un nouveau JWT valide avec n'importe quelle information.
Cependant, imaginez une situation où la longueur maximale de l'ID est de 4 (0001-9999). Les requêtes 0001 et 10001 vont utiliser le même ID. Donc, si le backend incrémente l'ID à chaque requête, vous pourriez abuser de cela pour **rejouer une requête** (nécessitant d'envoyer 10000 requêtes entre chaque rejou réussi).
Il a été observé que certaines applications web s'appuient sur un service JWT de confiance pour la génération et la gestion de leurs jetons. Des cas ont été enregistrés où un jeton, généré pour un client par le service JWT, a été accepté par un autre client du même service JWT. Si l'émission ou le renouvellement d'un JWT via un service tiers est observé, la possibilité de s'inscrire à un compte sur un autre client de ce service en utilisant le même nom d'utilisateur/email devrait être investiguée. Une tentative devrait ensuite être faite pour rejouer le jeton obtenu dans une requête vers la cible pour voir s'il est accepté.
* Un problème critique peut être indiqué par l'acceptation de votre jeton, permettant potentiellement le spoofing du compte de n'importe quel utilisateur. Cependant, il convient de noter qu'une autorisation pour des tests plus larges pourrait être requise si l'inscription sur une application tierce est nécessaire, car cela pourrait entrer dans une zone grise légale.
L'expiration du jeton est vérifiée en utilisant la revendication Payload "exp". Étant donné que les JWT sont souvent utilisés sans information de session, une manipulation prudente est requise. Dans de nombreux cas, capturer et rejouer le JWT d'un autre utilisateur pourrait permettre l'usurpation de cet utilisateur. La RFC JWT recommande de mitiger les attaques de rejouement JWT en utilisant la revendication "exp" pour définir un temps d'expiration pour le jeton. De plus, la mise en œuvre de vérifications pertinentes par l'application pour garantir le traitement de cette valeur et le rejet des jetons expirés est crucial. Si le jeton inclut une revendication "exp" et que les limites de temps de test le permettent, il est conseillé de stocker le jeton et de le rejouer après que le temps d'expiration soit passé. Le contenu du jeton, y compris l'analyse de l'horodatage et la vérification de l'expiration (horodatage en UTC), peut être lu en utilisant le drapeau -R de l'outil jwt\_tool.
* Un risque de sécurité peut être présent si l'application valide toujours le jeton, car cela pourrait impliquer que le jeton ne pourrait jamais expirer.
Si vous êtes intéressé par une **carrière en piratage** et pirater l'impossible - **nous recrutons !** (_maîtrise du polonais écrit et parlé requise_).
<summary><strong>Apprenez le piratage AWS de zéro à héros avec</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si vous souhaitez voir votre **entreprise annoncée dans HackTricks** ou **télécharger HackTricks en PDF** Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
* Découvrez [**La Famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Rejoignez** 💬 le groupe Discord](https://discord.gg/hRep4RUj7f) ou le [groupe telegram](https://t.me/peass) ou **suivez-nous** sur **Twitter** 🐦 [@carlospolopm](https://twitter.com/hacktricks_live)**.**
* **Partagez vos astuces de piratage en soumettant des PR aux** [**HackTricks**](https://github.com/carlospolop/hacktricks) et [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.