lancement du système de gestion de contenu web . La sortie se distingue par la finalisation pour la mise en œuvre de la vérification des mises à jour et des ajouts par signature numérique.
Jusqu'à présent, lors de l'installation des mises à jour dans WordPress, le facteur principal de sécurité était la confiance envers l'infrastructure et les serveurs de WordPress (après le téléchargement, une vérification de hachage était effectuée sans vérification de la source). En cas de compromission des serveurs du projet, les attaquants pouvaient remplacer la mise à jour et propager du code malveillant parmi les sites utilisant WordPress avec le système d'installation automatique des mises à jour. En accord avec le modèle de livraison de confiance auparavant appliqué, un tel remplacement serait resté inaperçu du côté des utilisateurs.
Étant donné que selon le projet w3techs, la plateforme WordPress est utilisée sur 33,8 % des sites sur le réseau, l'incident aurait pris des proportions catastrophiques. De plus, le danger de compromission de l'infrastructure n'était pas hypothétique, mais bien réel. Par exemple, il y a quelques années, l'un des chercheurs en sécurité a découvert une vulnérabilité permettant à un attaquant d'exécuter son code sur le serveur api.wordpress.org.
Dans le cas de l'utilisation de signatures numériques, prendre le contrôle du serveur de distribution des mises à jour ne compromettrait pas les systèmes des utilisateurs, car pour réaliser l'attaque, il faudrait également obtenir la clé secrète stockée séparément, qui est utilisée pour signer les mises à jour.
L'implémentation de la vérification de la source des mises à jour par signature numérique a été entravée par le fait que le support des algorithmes cryptographiques nécessaires a récemment été intégré dans l'offre standard de PHP. Les algorithmes cryptographiques nécessaires sont apparus grâce à l'intégration de la bibliothèque dans la base . Mais comme version minimale prise en charge dans WordPress, la version La solution a été
et l'intégration dans WordPress 5.2 d'une version compacte de Libsodium — Sodium Compat , dans lequel un ensemble minimal d'algorithmes a été implémenté en PHP pour vérifier les signatures numériques. La réalisation pourrait être améliorée en termes de performance, mais elle résout entièrement le problème de compatibilité et permet aux développeurs de plugins de commencer à intégrer des algorithmes cryptographiques modernes.
L'algorithme utilisé pour générer des signatures numériques est , développé avec la participation de Daniel Bernstein (Daniel J. Bernstein). La signature numérique est formée à partir de la valeur de hachage SHA384, calculée à partir du contenu de l'archive de mise à jour. Ed25519 offre un niveau de sécurité supérieur à ECDSA et DSA, et présente une très grande rapidité de vérification et de création de signatures. La résistance à l'intrusion d'Ed25519 est d'environ 2^128 (en moyenne, une attaque contre Ed25519 nécessiterait de réaliser 2^140 opérations binaires), ce qui correspond à la résistance de tels algorithmes que NIST P-256 et RSA avec une taille de clé de 3000 bits ou un chiffrement par blocs de 128 bits. Ed25519 n'est également pas sujet à des problèmes de collisions dans les hachages et est insensible aux attaques par analyse de l'horodatage dans le cache (cache-timing) et aux attaques par canaux latéraux.
Dans la version WordPress 5.2, la vérification de la signature numérique ne couvre pour l'instant que les mises à jour principales de la plateforme et ne bloque pas par défaut la mise à jour, mais informe simplement l'utilisateur d'un problème survenu. Il a été décidé de ne pas inclure le blocage par défaut immédiatement en raison de la nécessité d'une vérification complète et d'un contournement . À l'avenir, il est également prévu d'ajouter la vérification par signature numérique pour la vérification de la source d'installation des thèmes et des plugins (les producteurs pourront signer leurs versions avec leur clé).
En plus de la prise en charge des signatures numériques, la version WordPress 5.2 comprend les changements suivants :
- Deux nouvelles pages ont été ajoutées à la section « Santé du site » pour déboguer des problèmes de configuration courants, et un formulaire a été fourni par lequel les développeurs peuvent laisser des informations de débogage aux administrateurs du site;
- Une implémentation de l'« écran blanc de la mort » a été ajoutée, laquelle est affichée en cas de problèmes fatals et aide l'administrateur à corriger soi-même les problèmes liés aux plugins ou aux thèmes, en accédant à un mode spécial de récupération après plantage;
- Un système de vérification de la compatibilité avec les plugins a été mis en place, vérifiant automatiquement la possibilité d'utilisation d'un plugin dans la configuration actuelle en tenant compte de la version PHP utilisée. Si une version PHP plus récente est nécessaire au fonctionnement du plugin, le système bloquera automatiquement l'activation de ce plugin.
- Ajout de la prise en charge de l'activation de modules avec du code JavaScript en utilisant et ;
- Ajout d'un nouveau modèle privacy-policy.php, permettant de configurer le contenu de la page sur les conditions de respect de la vie privée.
- Pour les thèmes, un gestionnaire wp_body_open hook a été ajouté, permettant d'insérer du code immédiatement après la balise body.
- Les exigences concernant la version minimale de PHP ont été élevées à 5.6.20, permettant l'utilisation de namespaces et de fonctions anonymes dans les plugins et thèmes.
- 13 nouvelles icônes ont été ajoutées.
En outre, on peut mentionner vulnérabilité critique dans le plugin WordPress (CVE-2019-11185). La vulnérabilité permet d'exécuter du code PHP arbitraire sur le serveur. Le plugin est utilisé sur plus de 27 000 sites pour organiser un chat interactif avec les visiteurs, y compris sur les sites de sociétés telles qu'IKEA, Adobe, Huawei, PayPal, Tele2 et McDonald's (Live Chat est souvent utilisé pour mettre en œuvre des chats contextuels intrusifs sur les sites d'entreprises avec une offre de communication avec un employé).
Le problème se manifeste dans le code de téléchargement de fichiers sur le serveur et permet de contourner la vérification des types de fichiers autorisés et de télécharger un script PHP sur le serveur, qui peut ensuite être exécuté par un accès direct via le web. Fait intéressant, l'année dernière, une vulnérabilité similaire a déjà été détectée dans Live Chat (CVE-2018-12426), permettant de télécharger du code PHP sous la forme d'une image, en spécifiant un autre type de contenu dans le champ Content-type. Dans le cadre de la correction du problème, des vérifications supplémentaires ont été ajoutées via des listes blanches et le type MIME du contenu. Il s'est avéré que ces vérifications étaient mal mises en œuvre et que l'on pouvait facilement les contourner.
En particulier, le téléchargement direct de fichiers avec l'extension «.php» est interdit, mais l'extension «.phtml», souvent liée à l'interpréteur PHP sur de nombreux serveurs, n'a pas été ajoutée à la liste noire. La liste blanche n'autorise que le téléchargement d'images, mais il est possible de la contourner en spécifiant une double extension, par exemple, «.gif.phtml». Pour contourner la vérification du type MIME au début du fichier, avant l'ouverture de la balise avec le code PHP, il suffisait d'indiquer la chaîne «GIF89a».
Source : opennet.ru
