version du système de gestion de contenu Web . Le numéro est remarquable par son achèvement pour la mise en œuvre vérification des mises à jour et des ajouts à l'aide de la signature numérique.
Jusqu'à présent, lors de l'installation des mises à jour dans WordPress Le principal facteur garantissant la sécurité était la confiance dans l'infrastructure et les serveurs. WordPress (Après le téléchargement, le hachage était vérifié sans que la source soit contrôlée). Si les serveurs du projet étaient compromis, les attaquants pouvaient remplacer la mise à jour et diffuser du code malveillant sur des sites web. WordPress, grâce au système d'installation automatique des mises à jour. Avec le modèle de distribution de confiance précédemment utilisé, un tel changement serait passé inaperçu pour les utilisateurs.
Considérant que selon projet de plateforme w3techs WordPress Utilisé par 33.8 % des sites web sur Internet, un incident aurait été catastrophique. De plus, le risque de compromission de l'infrastructure n'était pas hypothétique, mais bien réel. Par exemple, il y a plusieurs années, un chercheur en sécurité… vulnérabilité qui a permis à un attaquant d'exécuter son code côté serveur api.wordpress.org.
Si des signatures numériques sont utilisées, la prise de contrôle du serveur de distribution des mises à jour n'entraînera pas la compromission des systèmes des utilisateurs, car pour mener une attaque, il sera en outre nécessaire d'obtenir une clé privée stockée séparément, à l'aide de laquelle les mises à jour sont signées.
La mise en œuvre de la vérification de la source des mises à jour par signature numérique a été entravée par l'apparition relativement récente de la prise en charge des algorithmes cryptographiques nécessaires dans la distribution standard de PHP. Ces algorithmes sont apparus grâce à l'intégration de la bibliothèque. à l'équipe principale Mais au minimum, ce qui est pris en charge par WordPress versions PHP Version 5.2.4 (à partir du WordPress 5.2 - 5.6.20). L'activation de la prise en charge des signatures numériques aurait considérablement augmenté les exigences relatives à la version minimale de PHP prise en charge ou aurait ajouté une dépendance externe, ce que les développeurs ne pouvaient pas faire étant donné la prévalence des versions de PHP sur les systèmes d'hébergement.
La solution était et l'inclusion dans la composition WordPress 5.2 variante compacte de Libsodium - , qui implémente un ensemble minimal d'algorithmes pour la vérification des signatures numériques en PHP. Cette implémentation laisse beaucoup à désirer en termes de performances, mais résout complètement le problème de compatibilité et permet 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. La signature numérique est formée à partir de la valeur de hachage SHA384 calculée à partir du contenu de l'archive mise à jour. Ed25519 présente un niveau de sécurité supérieur à celui d'ECDSA et de DSA, et affiche une vitesse de vérification et de création de signature très élevée. La résistance au craquage d'Ed25519 est d'environ 2^128 (en moyenne, une attaque sur Ed25519 nécessiterait 2^140 opérations sur les bits), ce qui correspond à la résistance d'algorithmes tels que NIST P-256 et RSA avec une taille de clé de 3000 128 bits ou un chiffrement par bloc de 25519 bits. EdXNUMX est également insensible aux problèmes de collision de hachage, aux attaques par synchronisation du cache et aux attaques par canal auxiliaire.
En cause WordPress 5.2 La vérification de la signature numérique ne concerne actuellement que les mises à jour majeures de la plateforme et n'empêche pas leur installation par défaut ; elle se contente d'informer l'utilisateur du problème. Il a été décidé de ne pas activer le blocage par défaut afin de permettre une vérification complète et la possibilité de contourner le blocage. À 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 de conception et des plugins (les fabricants pourront signer les versions avec leur propre clé).
En plus de prendre en charge les signatures numériques, WordPress En 5.2, les changements suivants peuvent être notés :
- La section Santé du site a été mise à jour pour inclure deux nouvelles pages pour le débogage des problèmes de configuration courants, et un formulaire a été fourni aux développeurs pour soumettre des informations de débogage aux administrateurs du site ;
- Ajout de l'implémentation de « l'écran blanc de la mort » qui s'affiche en cas de problèmes fatals et aide l'administrateur à résoudre de manière indépendante les problèmes liés aux plugins ou aux thèmes en passant à un mode de récupération spécial après une panne ;
- Un système de vérification de compatibilité des plugins a été implémenté. Il vérifie automatiquement la compatibilité d'un plugin avec la configuration actuelle, en tenant compte de la version PHP utilisée. Si un plugin nécessite une version PHP plus récente pour fonctionner, le système bloquera automatiquement son inclusion ;
- 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 de conception, le gestionnaire de hook wp_body_open a été ajouté, vous permettant d'insérer du code immédiatement après la balise body ;
- La version minimale requise de PHP a été augmentée à 5.6.20, et les plugins et les thèmes prennent désormais en charge les espaces de noms et les fonctions anonymes ;
- Ajout de 13 nouvelles icônes.
De plus, vous pouvez mentionner vulnérabilité critique dans WordPress-plugin (CVE-2019-11185). Cette vulnérabilité permet l'exécution de code PHP arbitraire sur le serveur. Le plugin est utilisé sur plus de 27 2 sites web pour organiser une conversation interactive avec un visiteur, notamment sur les sites web d'entreprises comme IKEA, Adobe, Huawei, PayPal, TeleXNUMX et McDonald's (le chat en direct est souvent utilisé pour créer des fenêtres contextuelles de discussion intempestives sur les sites web des entreprises proposant de discuter avec un employé).
Le problème se manifeste dans le code de téléchargement des fichiers sur le serveur et permet de contourner la vérification des types de fichiers acceptables et de télécharger un script PHP sur le serveur, puis de l'exécuter en y accédant directement via le Web. Il est intéressant de noter que l'année dernière, une vulnérabilité similaire (CVE-2018-12426) avait déjà été identifiée dans Live Chat. Elle permettait de télécharger du code PHP sous la forme d'une image, en spécifiant un type de contenu différent dans le champ « Contenu ». Dans le cadre de la correction, des vérifications supplémentaires ont été ajoutées pour les listes blanches et les types de contenu MIME. Il s'est avéré que ces vérifications étaient mal implémentées et peuvent être facilement contournées.
En particulier, le téléchargement direct de fichiers portant l'extension « .php » est interdit, mais l'extension « .phtml » n'a pas été ajoutée à la liste noire, car elle est associée à l'interpréteur PHP sur de nombreux serveurs. La liste blanche autorise uniquement le téléchargement d'images, mais elle peut être contournée en spécifiant une double extension, par exemple « .gif.phtml ». Pour contourner la vérification du type MIME au début du fichier, il suffisait de spécifier la chaîne « GIF89a » avant d'ouvrir la balise contenant le code PHP.
Source: opennet.ru
