version du système de gestion de contenu Web . La version se distingue par son achèvement sur la mise en œuvre vérifier les mises à jour et les ajouts à l'aide d'une signature numérique.
Jusqu'à présent, lors de l'installation des mises à jour dans WordPress, le principal facteur de sécurité était la confiance dans l'infrastructure et les serveurs WordPress (après le téléchargement, le hachage était vérifié sans vérifier la source). Si les serveurs du projet étaient compromis, les attaquants pourraient usurper une mise à jour et distribuer du code malveillant entre les sites WordPress qui utilisent un système d'installation automatique des mises à jour. Conformément au modèle de confiance utilisé précédemment, une telle substitution serait passée inaperçue du côté des utilisateurs.
Tenant compte du fait que du projet w3techs, la plateforme WordPress est utilisée sur 33.8% des sites du réseau, l'incident aurait pris l'ampleur d'une catastrophe. Dans le même temps, le danger d’une compromission des infrastructures n’était pas hypothétique, mais bien réel. Par exemple, il y a plusieurs années, l'un des chercheurs en sécurité une vulnérabilité qui permettait à un attaquant d'exécuter son code côté serveur d'api.wordpress.org.
Dans le cas des signatures numériques, prendre le contrôle du serveur de distribution des mises à jour n'entraînera pas de compromission des systèmes des utilisateurs, car pour mener une attaque, vous devrez en outre obtenir une clé privée stockée séparément, avec laquelle les mises à jour sont signées.
La mise en œuvre de la vérification de la source des mises à jour à l'aide d'une signature numérique a été entravée par le fait que la prise en charge des algorithmes cryptographiques nécessaires est apparue relativement récemment dans le package PHP standard. Les algorithmes cryptographiques nécessaires sont apparus grâce à l'intégration de la bibliothèque à l'équipe principale . Mais comme version minimale prise en charge de PHP dans WordPress version 5.2.4 (de WordPress 5.2 à 5.6.20). L'activation de la prise en charge des signatures numériques entraînerait une augmentation significative des exigences relatives à la version minimale prise en charge de PHP ou l'ajout d'une dépendance externe, ce que les développeurs ne pourraient pas faire étant donné la prévalence des versions de PHP dans les systèmes d'hébergement.
La solution était et l'inclusion d'une version compacte de Libsodium dans WordPress 5.2 - , dans lequel un ensemble minimum d'algorithmes de vérification des signatures numériques est implémenté en PHP. L'implémentation laisse beaucoup à désirer en termes de performances, mais résout complètement le problème de compatibilité et permet également aux développeurs de plugins de commencer à implémenter des algorithmes cryptographiques modernes.
Un algorithme est utilisé pour générer des signatures numériques , développé avec la participation de Daniel J. Bernstein. Une signature numérique est générée pour la valeur de hachage SHA384 calculée à partir du contenu de l'archive de mise à jour. Ed25519 a un niveau de sécurité plus élevé que ECDSA et DSA et démontre une très grande vitesse de vérification et de création de signature. La résistance au piratage pour Ed25519 est d'environ 2^128 (en moyenne, une attaque sur Ed25519 nécessitera des opérations de 2^140 bits), ce qui correspond à la résistance d'algorithmes tels que NIST P-256 et RSA avec une taille de clé de 3000 bits. ou chiffrement par bloc de 128 bits. Ed25519 n'est pas non plus sensible aux problèmes de collisions de hachage, ni aux attaques de synchronisation du cache ou aux attaques par canal secondaire.
Dans la version WordPress 5.2, la vérification de la signature numérique ne couvre actuellement que les mises à jour majeures de la plateforme et ne bloque pas la mise à jour par défaut, mais informe uniquement l'utilisateur du problème. Il a été décidé de ne pas activer immédiatement le blocage par défaut en raison de la nécessité d'une vérification et d'un contournement complets. . A l'avenir, il est également prévu d'ajouter une vérification de signature numérique pour vérifier la source d'installation des thèmes et plugins (les fabricants pourront signer les releases avec leur clé).
En plus de la prise en charge des signatures numériques dans WordPress 5.2, les changements suivants peuvent être notés :
- Deux nouvelles pages ont été ajoutées à la section « Santé du site » pour le débogage des problèmes de configuration courants, et un formulaire a également été fourni grâce auquel les développeurs peuvent laisser des informations de débogage aux administrateurs du site ;
- Ajout de l'implémentation de « l'écran blanc de la mort », affiché en cas de problèmes fatals et aidant l'administrateur à résoudre indépendamment les problèmes liés aux plugins ou aux thèmes en passant à un mode spécial de récupération après crash ;
- Un système de vérification de compatibilité avec les plugins a été mis en place, qui vérifie automatiquement la possibilité d'utiliser le plugin dans la configuration actuelle, en tenant compte de la version de PHP utilisée. Si un plugin nécessite une version plus récente de PHP pour fonctionner, le système bloquera automatiquement l'inclusion de ce plugin ;
- Ajout de la prise en charge de l'activation des modules avec du code JavaScript à l'aide de и ;
- Ajout d'un nouveau modèle Privacy-policy.php qui vous permet de personnaliser le contenu de la page de politique de confidentialité ;
- Pour les thèmes, un gestionnaire de hook wp_body_open a été ajouté, vous permettant d'insérer du code immédiatement après la balise body ;
- Les exigences pour la version minimale de PHP ont été augmentées à 5.6.20 ; les plugins et les thèmes ont désormais la possibilité d'utiliser des espaces de noms et des fonctions anonymes ;
- Ajout de 13 nouvelles icônes.
De plus, vous pouvez 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 2 sites pour organiser un chat interactif avec un visiteur, y compris sur les sites d'entreprises telles que IKEA, Adobe, Huawei, PayPal, TeleXNUMX et McDonald's (le chat en direct est souvent utilisé pour implémenter des pop-up ennuyeux chats sur les sites de l'entreprise avec des offres de chat avec le salarié).
Le problème se manifeste dans le code de téléchargement de fichiers sur le serveur et vous permet de contourner la vérification des types de fichiers valides et de télécharger un script PHP sur le serveur, puis de l'exécuter directement via le Web. Fait intéressant, l'année dernière, une vulnérabilité similaire avait déjà été identifiée dans Live Chat (CVE-2018-12426), qui permettait de charger du code PHP sous le couvert d'une image, en spécifiant un type de contenu différent dans le champ Type de contenu. Dans le cadre du correctif, des vérifications supplémentaires ont été ajoutées pour les listes blanches et le type de contenu MIME. Il s’avère que ces contrôles sont mal mis en œuvre et peuvent facilement être contournés.
En particulier, le téléchargement direct de fichiers avec l'extension « .php » est interdit, mais l'extension « .phtml », associée à l'interpréteur PHP sur de nombreux serveurs, n'a pas été ajoutée à la liste noire. La liste blanche autorise uniquement le téléchargement d'images, mais vous pouvez 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 d'ouvrir la balise avec le code PHP, il suffisait de préciser la ligne « GIF89a ».
Source: opennet.ru