Le support de CSPRNG bientôt disponible sur WordPress, Laravel et Symfony
Le support de CSPRNG bientôt disponible sur WordPress, Laravel et Symfony
pour une amélioration de la sécurité
En février dernier, Scott Arciszewski, un développeur web basé à Orlando en Floride qui est actuellement Chief Development Officer au sein de Paragon Initiative Enterprises, a proposé aux développeurs de WordPress d’intégrer un mécanisme de type CSPRNG, un générateur de nombres pseudoaléatoires, afin de limiter considérablement le risque que quelqu’un puisse prédire les Tokens pour réinitialiser les mots de passe. Il a prévenu qu’un pirate qui pourrait exploiter cette faille pourrait prendre le contrôle total d’un site WordPress. Il a même donné des instructions détaillées pour implémenter un mécanisme de ce type en modifiant les fichiers de WordPress.
Les développeurs ont estimé qu’il était difficile de conceptualiser une attaque sur WordPress, encore moins d’en réaliser une. Néanmoins, certains d’entre eux ont reconnu que ce serait une bonne idée de se servir de CSPRNG, mais il y avait un problème : WordPress supportait toujours PHP 5.2.4 et il se trouvait être très difficile d’avoir un chiffrement aléatoire sécurisé sur la branche PHP 5.2.
CSPRNG est un algorithme de génération de nombres aléatoires conçu pour un usage spécifique en cryptographie. Les experts en sécurité recommandent algorithmes CSPRNG pour générer des hashs de sel, les clés et les nonces étant donné que CSPRNG génère des nombres aléatoires avec une haute entropie (aléatoire), ce qui signifie qu'ils sont plus difficiles à deviner en se servant des attaques par force brute.
Dans un billet, il explique qu’avant de se tourner vers WordPress, il s’était d’abord intéressé au code source du SDK de Facebook disponible sur Github. « J’ai découvert qu’au lieu d’utiliser un générateur de nombres aléatoires sécurisé, ils faisaient ceci :
Code:
$this->state = md5(uniqid(mt_rand(), true));
Dans un monde parfait, ceci donne, au plus, 61 octets d’entropie (32 en provenance de mt_rand() et seulement 29 en provenance de uniqid(). Étant donné qu’un attaquant peut exécuter une force brute exhaustive de 56 octets en 24 heures, et tous les octets multipliant le temps requis par deux, cela signifie qu’un attaquant n’aura besoin que de 32 jours pour calculer toutes les sorties possibles de cette fonction, qu’il pourrait sauvegarder et utiliser à sa convenance. Une telle base de données demanderait un espace de stockage de plusieurs pétaoctets, mais permettrait à un attaquant aguerri de reconstituer la seed mt_rand et de prédire la prochaine sortie RNG ». Pour rappel, mt_srand() initialise le générateur de valeurs aléatoires avec seed ou avec une valeur aléatoire si aucun paramètre seed n'est fourni, seed étant un paramètre représentant une valeur d'initialisation aléatoire.
Aussi, les efforts de la communauté open source en collaboration avec Paragon Initiative Enterprises se sont matérialisés par une amélioration de la sécurité dans des applications PHP, changements qui vont s’appliquer dans des projets PHP de grande envergure comme le CMS WordPress ou les frameworks Laravel et Symfony ; ils intégreront un support pour CSPRNG à compter de la version 4.4 de WordPress, la version 5.2 de Laravel et la version 2.8 de Symfony.
L’attention du chercheur s’est également posée sur le CMS Joomla pour lequel il a fait un rapport sur certaines pratiques dans le chiffrement qui ne sont pas poussées. « JCrypt est la bibliothèque de chiffrement de Joomla et elle gère beaucoup de choses, du chiffrement symétrique à l’authentification des mots de passe. L’héritage de son authentification de mots de passe (pre-bcrypt) est vulnérable à ce qui a été appelé la vulnérabilité « magic hash » par diverses campagnes effectuées par de nombreuses entreprises de sécurité et qui se résume à ceci : si vous avez deux hashs qui commencent par « 0e » et ne sont suivis que par des chiffres numériques, indépendamment de ce que sont ces chiffres numériques, PHP va penser qu’ils sont égaux les uns aux autres, explique-t-il.
« De plus, leur bcrypt ne suit pas les meilleures pratiques de cryptographie ; il compare les hashs avec === au lieu de se servir d’une fonction de comparaison de chaîne », note-t-il.
« Leur chiffrement d’héritage, JCryptCipherSimple, est extrêmement mauvais. Si vous passez le message ‘AAAA…’ (la lettre ‘A’ répétée au moins 256 fois), alors prenez votre texte chiffré et ‘soustrayez’ (XOR) la chaîne de caractères en texte clair (‘AAAA…’) du texte chiffré ; vous aurez juste récupéré la clé de chiffrement ».
Il a parlé encore d’autres problèmes rencontrés dans les pratiques cryptographiques de Joomla avant de conclure en disant que « toutes ces pratiques me font penser qu’aucun cryptographe ne s’est intéressé à leur code avant et c’est assez effrayant étant donné la popularité de Joomla ».
Après la publication de son article, Joomla a ajouté random_compat a Joomla 3.5.0 dans sa pull request. Les autres problèmes rapportés par Arciszewski n’ont pas encore été résolus.
Source : blog Paragonie, OpenWall, Github
