Le jeudi 29 octobre, l’équipe principale de WordPress a publié la version 5.5.2 de WordPress. Il s’agissait d’une version mineure contenant des corrections de bogues et des améliorations de la sécurité du système de gestion de contenu WordPress de base alimentant plus d’un tiers d’Internet. Il y a eu une version 5.5.3 ultérieure un jour plus tard; vous pouvez lire sur le version d’urgence WP 5.5.3 ici.

Comme pour chaque version, l’équipe de Wordfence a analysé cette version pour déterminer la gravité de toutes les vulnérabilités pouvant avoir été corrigées afin de garantir que les utilisateurs de Wordfence sont correctement protégés par le flux Wordfence Threat Defense.

Dans la version WordPress 5.5.2, l’équipe principale a corrigé 8 vulnérabilités différentes. Nous avons constaté que la plupart de ces vulnérabilités nécessitaient des conditions spécifiques, ce qui signifie qu’elles ne seraient pas facilement exploitées en masse.

Un regard plus attentif sur les changements

Bibliothèques externes: désactiver la désérialisation dans Requests_Utility_FilteredIterator
C’était une solution au Requests_Utility_FilteredIterator classe.

Comme cette classe a implémenté l’interface Serializable mais n’a pas utilisé de méthode magique spécifique pour __unserialize, tout objet PHP injecté via une vulnérabilité d’injection d’objets distincte pourrait l’utiliser dans le cadre d’une chaîne POP pour exécuter du code à distance via le __construct méthode.

Le correctif impliquait l’ajout d’un __unserialize méthode magique pour gérer les objets injectés via la désérialisation en ne faisant rien, plutôt qu’en utilisant le __construct méthode qui a permis l’exécution de code.

La bonne nouvelle est qu’une vulnérabilité d’injection d’objets distincte devrait être présente pour que cela soit exploité. De plus, la charge utile de preuve de concept échouerait is_serialized vérifier que WordPress utilise pour déterminer si les données sont au format sérialisé, donc tous les plugins qui ont utilisé cette vérification ou le maybe_unserialize ne serait pas vulnérable à cette charge utile.

Voir les changements ici.

Alex Concha de l’équipe de sécurité de WordPress a contribué à son travail sur ce correctif.

Intégrations: désactivez les intégrations sur les sites multisites désactivés.
Ce correctif semble avoir été introduit pour empêcher le contenu d’être intégré dans des sites faisant partie d’une installation multisite qui ont été archivés, supprimés ou considérés comme du spam. Il s’agissait d’une mesure visant à empêcher la création de spam en utilisant l’intégration sur des installations multisites qui ont été supprimées ou archivées. Il n’y a pas beaucoup de risques pour les propriétaires de sites en raison de cette vulnérabilité. Si un site était compromis, cela pourrait éventuellement être utilisé pour infecter davantage un site archivé ou supprimé sur une installation multisite.

Voir les changements ici.

Merci à David Binovec pour son travail sur ce sujet.

Normes de codage: modifiez les fonctions d’échappement pour éviter les faux positifs potentiels.
Il s’agissait d’un correctif pour échapper à la sortie des données qui sont renvoyées à certaines zones du tableau de bord d’administration de WordPress. L’équipe principale a ajouté la fonction de esc_js pour échapper à tout JavaScript qui pourrait se frayer un chemin dans ces champs. Dans ce cas, cela était dû au fait que l’entrée utilisateur pouvait être injectée dans le $pagenow variable globale, de sorte que ces modifications empêchent l’exécution de tout JavaScript injecté.

De plus, une fonction supplémentaire de absint a été ajouté pour garantir que les champs de données qui ne doivent contenir que des données numériques contiennent uniquement des données numériques. Cet échappement aiderait à empêcher tout éventuel Cross-Site Scripting (XSS) qui pourrait être introduit dans des variables globales ainsi que des slugs de publication WordPress.

Voir les changements ici.

Props à Marc Montpas et Karim El Ouerghemmi pour avoir divulgué ces problèmes XSS à l’équipe WordPress.

Mettre à niveau / installer: améliorez la vérification de la logique lors de la détermination de l’état de l’installation.
Ce correctif cherche à corriger une attaque potentielle par déni de service contre la base de données MySQL. La page d’installation de WordPress effectue un certain nombre de vérifications pour déterminer si WordPress a déjà été installé. Celles-ci sont effectuées en interrogeant la base de données et en examinant les données qui y sont stockées. Il vérifie d’abord si le siteurl option a été définie en regardant dans le wp_options table. Si ce n’est pas le cas, il descend dans la liste des tables WordPress pour voir si elles existent dans la base de données. S’il ne parvient pas à en trouver, il détermine que WordPress n’a pas encore été installé.

Pour qu’un attaquant puisse exploiter cela, il devrait autoriser WordPress à se connecter à la base de données, mais empêcher la base de données de renvoyer les données des vérifications effectuées ci-dessus. Il y a probablement un élément temporel à cette attaque par déni de service, ainsi qu’un moyen d’accéder à la base de données. Dans de nombreux cas, les bases de données MySQL ne sont pas accessibles au public. Cela semble être exploitable par un utilisateur non authentifié à condition que les autres conditions soient remplies.

Voir les changements ici.

Merci à Omar Ganiev d’avoir découvert et signalé cette vulnérabilité.

XML-RPC: renvoie un message d’erreur si l’ID de la pièce jointe est incorrect.
Il s’agit d’une correction implémentée pour vérifier qu’un élément multimédia récupéré à l’aide d’une requête XMLRPC à wp.getMediaItem est en fait une «pièce jointe» en vérifiant que le post_type est celle d’un attachement.

Cela a corrigé une vulnérabilité qui permettait aux utilisateurs avec le upload_files capacité, comme les auteurs, d’afficher les articles qui peuvent avoir été masqués ou à l’étape de brouillon. Essentiellement, un attaquant aurait pu lire n’importe quel message quel que soit le type contenu dans le wp_posts table en raison de l’absence de vérification pour vérifier que la pièce jointe récupérée par XMLRPC était en fait une pièce jointe multimédia.

Voir les changements ici.

Merci à Justin Tran d’avoir découvert et signalé cette vulnérabilité.

XML-RPC: améliore les messages d’erreur pour les utilisateurs non privilégiés.
Il s’agissait d’un correctif simple pour modifier les capacités requises pour commenter les publications à l’aide de XMLRPC. Il semble que les versions précédentes de WordPress n’effectuaient pas de vérification sur la publication pour déterminer dans quel état la publication se trouvait. Cela signifiait qu’il était possible pour les utilisateurs de commenter les publications privées ou masquées ainsi que les brouillons avec des privilèges limités, en utilisant XMLRPC.

La bonne nouvelle est que, à moins que votre site n’ait activé les commentaires XMLRPC anonymes, un utilisateur devra être enregistré pour commenter en utilisant cette méthode.

Voir les changements ici.

Félicitations à nouveau à Justin Tran pour avoir découvert et signalé cette vulnérabilité.

Meta: nettoyez la clé méta avant de vérifier l’état de la protection.
Dans cette version, l’équipe WordPress Core a ajouté la désinfection au meta_key valeur avant de vérifier son état de protection dans le is_protected_meta fonction. Ce correctif a été implémenté pour résoudre un contournement dans la fonction qui permettrait de passer des clés méta protégées. Cela aurait pu conduire à la suppression arbitraire de fichiers.

le is_protected_meta La fonction est utilisée pour déterminer si les métadonnées sont considérées comme protégées. Pour ce faire, la fonction a vérifié un simple `_` au début de la meta_key pour déterminer s’il doit être protégé et non modifié. Cette méthode de protection pourrait facilement être contournée en fournissant un octet nul devant le `_` trouvé au début de la clé de métadonnées protégées qui permettrait aux métadonnées «protégées» d’être transmises et utilisées dans d’autres fonctions.

Cette vulnérabilité exigerait des capacités de plus haut niveau à exploiter.

Voir les changements ici.

Des accessoires à Slavco pour avoir découvert et analysé cela et à Karim El Ouerghemmi pour avoir confirmé.

Thèmes: assurez-vous que seuls les utilisateurs privilégiés peuvent définir une image d’arrière-plan lorsqu’un thème utilise la page d’arrière-plan personnalisée obsolète.
Ce correctif semble résoudre une vulnérabilité Cross-Site Request Forgery qui pourrait permettre à un attaquant de modifier l’image d’arrière-plan d’un thème dans les cas où un thème utilise la page d’arrière-plan personnalisée obsolète.

La fonction utilisée pour changer les images d’arrière-plan avait déjà un contrôle de capacité pour edit_theme_options. Ce correctif semble ajouter un nonce à cette fonction pour vérifier l’intégrité de la source d’une demande de mise à jour d’une image d’arrière-plan.

Les vulnérabilités de falsification de requêtes intersites nécessitent qu’un administrateur victime soit amené à effectuer une action afin d’exploiter la vulnérabilité.

Voir les changements ici.

Props à Erwan LR pour avoir divulgué cette vulnérabilité de manière responsable.

Protéger les utilisateurs de Wordfence

Nous avons ajouté des protections dans le flux Wordfence Threat Defense pour protéger Wordfence Premium clients contre l’exploitation d’un certain nombre de ces vulnérabilités. Les sites utilisant toujours la version gratuite de Wordfence recevront ces règles de pare-feu le 30 novembre 2020.

Néanmoins, il est toujours prudent de s’assurer que votre site a été mis à jour vers la dernière version, maintenant la version 5.5.3, de WordPress pour s’assurer que les correctifs de base ont été appliqués à votre site.

Que devrais-je faire?

Bien que la plupart de ces vulnérabilités ne semblent pas être facilement exploitables, les chercheurs qui ont signalé ces problèmes de codage peuvent publier du code de preuve de concept qui pourrait conduire à des exploits contre des sites vulnérables. Les attaquants peuvent trouver à l’avenir des moyens d’utiliser du code non corrigé d’une manière que nous pourrions ne pas trouver significative maintenant. Comme toujours, nous vous recommandons de mettre à jour dès que possible.

Il s’agit d’une version mineure de WordPress, ce qui signifie que la plupart des sites seront automatiquement mis à jour. Avec l’urgence ultérieure sortie de WordPress 5.5.3, vous devez vous assurer que vous avez mis à jour vers la dernière version. Vous souhaiterez peut-être effectuer des tests dans un environnement intermédiaire avant de mettre à jour la version de production de votre site.

Conclusion

Merci à l’équipe principale de WordPress et aux chercheurs qui rendent WordPress plus sûr pour tout le monde.

Vous pouvez trouver l’annonce officielle du Version WP 5.5.2 ici. Si vous avez des questions ou des commentaires, veuillez les poster ci-dessous et nous ferons de notre mieux pour y répondre dans les meilleurs délais. Si vous faites partie des chercheurs dont les travaux sont inclus ci-dessus et que vous souhaitez apporter des précisions ou des corrections supplémentaires, nous apprécions vos commentaires.

Un merci spécial à Matt Barry, développeur principal de Wordfence, Matt Rusnak, responsable du contrôle qualité de Wordfence, et Ram Gall, ingénieur QA et analyste des menaces pour leur analyse de cette version principale de WordPress.


Source link