Plusieurs vulnérabilités critiques détectées dans les bibliothèques JWT

Plusieurs vulnérabilités critiques qui permettraient à un individu malintentionné de déjouer l’analyse ont été identifiées dans les bibliothèques de jetons Web JSON pour JavaScript et PHP.

Tim McLean, chercheur canadien spécialiste de la sécurité, du chiffrement et de l’identification des problèmes en la matière, a indiqué que les individus malintentionnés pouvaient exploiter une de ces vulnérabilités pour abuser de l’algorithme de chiffrement asymétrique dans certaines des bibliothèques JWT.

Introduit il y a de cela quelques années, JWT est un format de jeton d’authentification. Par exemple, le serveur peut émettre un jeton d’administration, le transmettre comme un jeton JSON et le signer à l’aide de la clé du serveur. Les clients peuvent utiliser ce jeton afin de vérifier si l’utilisateur est administrateur.

Le problème est lié à une confusion au niveau de la clé publique entre les systèmes signés par la fonction de hachage HMAC et ceux signés par RSA.

"Si le serveur attend un jeton signé par RSA et qu’il reçoit un jeton signé par HMAC, il considèrera la clé publique comme une clé HMAC" a expliqué Tim McLean dans son blog. Où est le problème ? Les clés privées HMAC doivent rester confidentielles et les clés publiques doivent être publiques.

Dans ce cas, si l’individu malintentionné obtient un accès à la clé publique, il peut l’utiliser en tant que jeton via l’API dans certaines bibliothèques JWT et le serveur l’accepte.

Dans un courrier électronique, Tim McLean nous a expliqué qu’il avait détecté cette vulnérabilité au mois de janvier lorsqu’il avait souhaité utiliser JWT dans un projet. Après l’analyse de la bibliothèque, réalisée pendant son temps libre, ce qui explique pourquoi l’opération aura autant duré, Tim McLean s’est rendu compte que le chiffrement n’avait pas été correctement mis en œuvre.

Afin de résoudre ce problème, il conseille à tous les utilisateurs de JWT de configurer la recherche d’éventuelles signatures différentes pour les jetons et de rejeter de tels jetons via un système de listes blanche et noire.

"Le serveur doit connaître au préalable l’algorithme utilisé pour signer les jetons et cette information ne peut pas tomber entre les mains des individus malintentionnés.

Un autre problème, résolu dans de nombreuses bibliothèques JWT, permettait aux individus malintentionnés de sélectionner le mode de vérification du jeton, ce qui "entraînait des conséquences catastrophiques dans certaines mises en œuvre" d’après Tim McLean.

Tim McLean a commencé à évoquer ce problème en février et il a poursuivi son analyse du bogue cette semaine. Auth0, le développeur d’une des normes d’autorisation les plus utilisées, a considéré que ce travail d’analyse était suffisamment important pour le publier dans son propre blog.

Le problème se situe au niveau de la manière dont les bibliothèques traitent l’algorithme connu sous le nom de "none". Les jetons signés par "none" peuvent être reconnus comme des jetons valides dotés de signatures valides d’après Tim McLean. Des individus malintentionnés pourraient modifier des jetons et les signer avec "none" au lieu de HMAC-SH256 ou HS256. Et les jetons seraient considérés comme valides. Les individus malintentionnés pourraient ensuite associer leur propre charge utile afin d’obtenir l’accès à un compte aléatoire dans certains systèmes.

D’après Tim McLean, la majorité des bibliothèques ont éliminé le problème "none" en veillant à ce que les jetons qui utilisent l’algorithme "none" soient rejetés lors de la vérification et c’est via ce problème qu’il a découvert la vulnérabilité des clés asymétriques.

"Au départ, j’étais satisfait de la manière dont le problème "none" avait été résolu, mais de nombreux développeurs se sont contentés de désactiver l’algorithme "none" au lieu de corriger la cause (algorithme contrôlé par un attaquant), ce qui fait que j’ai tout simplement chercher une fois de plus la manière dont je pouvais exploiter la situation" a déclaré Tim McLean.

Il a tenté de résoudre le problème en collaboration avec Auth0 qui lui a permis de contacter les auteurs de plusieurs bibliothèques vulnérables afin de confirmer que les jetons avec différentes signatures étaient bien rejetés. Dans la mesure où JWT fonctionne dans plusieurs langages (.NET, Node.js, Python, PHP, Java, Ruby, etc.), il existe plusieurs bibliothèques qui contiennent la vulnérabilité.

Auth0 a éliminé le problème dans sa bibliothèque Node.js jeudi dernier et invite les utilisateurs à passer à la dernière version en date, à savoir 4.2.2.

Jose Padilla, qui maintient la version Python de la bibliothèque, a éliminé la vulnérabilité de la vérification de la signature dans la version 1.0.0 publiée le mois dernier en ajoutant la prise en charge des listes blanches d’algorithmes. La version 1.0.1, qui est la dernière version en date, contient également la correction.

D’après jwt.io, un service d’Auth0, les versions des bibliothèques pour PHP et JavaScript sont toujours vulnérables. Auth0 encourage les utilisateurs de ces versions de JWT à trouver d’autres bibliothèques non vulnérables tant que le problème n’a pas été résolu.

Tim McLean a envoyé un e-mail relatif à la vulnérabilité aux auteurs de 20 bibliothèques le 9 mars et il n’a pas encore reçu les réponses de tout le monde. Il signale que la bibliothèque pour Ruby est toujours vulnérable, même si Auth0 ne l’a pas citée.

"Le volume de bibliothèques JWT est tellement élevé que je n’ai tout simplement pas le temps de les étudier toutes" explique Tim McLean.

Il espère que son message dans le blog permettra aux futurs développeurs de comprendre les mesures de précaution à adopter avant la mise en œuvre et estime qu’une modification des spécifications qui éliminerait le champ alg de l’en-tête serait utile à la communauté. Tim McLean a envoyé son message au groupe de travail JOSE (Javascript Object Signing and Encryption) et il espère que celui-ci en tiendra compte.

Source :        https://threatpost.com/critical-vulnerabilities-affect-json-web-token-libraries/111943

Posts similaires

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *