WordPress Core 6.3.2 est sorti aujourd’hui, le 12 octobre 2023. Il comprend un certain nombre de correctifs de sécurité et un renforcement supplémentaire contre les vulnérabilités couramment exploitées. Bien que toutes les vulnérabilités soient de gravité moyenne, plusieurs d’entre elles ont suffisamment d’impact pour permettre potentiellement le contrôle du site, et la mise à jour 6.3.2 contient donc les correctifs de sécurité les plus importants que nous ayons vus depuis un certain temps.

Beaucoup de ces correctifs ont été rétroportés sur chaque version de WordPress depuis la version 4.1, quelques-uns seulement ayant été rétroportés vers la version majeure dans laquelle la fonctionnalité a été publiée. WordPress prend en charge les mises à jour automatiques de base pour les versions de sécurité depuis WordPress 3.7, et la grande majorité des sites WordPress devraient recevoir automatiquement un correctif pour leur version majeure de WordPress au cours des prochaines 24 heures. Nous vous recommandons de vérifier que votre site a été automatiquement mis à jour vers l’une des versions corrigées. Des versions corrigées sont disponibles pour chaque version majeure de WordPress depuis la 4.1, vous pouvez donc mettre à jour sans risquer de problèmes de compatibilité.

L’équipe Wordfence Threat Intelligence a publié aujourd’hui deux nouvelles règles de pare-feu pour protéger Wordfence Premium, Entretien de la clôture des motset Réponse de Wordfence clients contre les vulnérabilités les plus impactantes corrigées, et ces règles seront disponibles gratuitement pour les utilisateurs de Wordfence dans 30 jours, le 11 novembre 2023.

Si votre site n’a pas été mis à jour automatiquement, nous vous recommandons fortement de le mettre à jour manuellement dès que possible, car l’une des vulnérabilités corrigées dans cette version peut être utilisée par un attaquant disposant d’un compte de niveau contributeur peu privilégié pour prendre le contrôle d’un site.

Analyse technique et aperçu

Comme pour chaque version principale de WordPress contenant des correctifs de sécurité, l’équipe Wordfence Threat Intelligence a analysé les modifications du code en détail pour évaluer l’impact de ces vulnérabilités sur nos clients et pour garantir que nos clients restent protégés.

Fini les abus de shortcode

WordPress Core est vulnérable à l’exécution arbitraire de shortcode dans les versions jusqu’à 6.3.1 incluses en raison d’un manque de validation d’entrée sur le paramètre ‘shortcode’ dans la fonction AJAX parse_media_shortcode. Cela permet à des attaquants authentifiés, disposant de privilèges au niveau de l’abonné et supérieurs, d’exécuter des codes courts arbitraires.

Bien que ce correctif ne corrige pas une vulnérabilité spécifique, il bloque un vecteur courant qui permet aux attaquants d’exploiter les vulnérabilités utilisant des codes courts. Avant WordPress 6.3.2, n’importe lequel Un utilisateur authentifié, y compris les abonnés, peut exécuter n’importe quel shortcode en appelant le gestionnaire AJAX intégré « parse-media-shortcode ».

Le ensemble de modifications dans WordPress 6.3.2 restreint ce gestionnaire AJAX aux shortcodes multimédias et nécessite que le shortcode « embed » soit associé à un identifiant de publication actif auquel l’utilisateur peut accéder.

Cela signifie qu’un large éventail de vulnérabilités d’injection SQL, de divulgation d’informations sensibles et d’exécution de code à distance qui nécessitaient uniquement une connexion utilisateur active ne peuvent désormais être exploitées que par des utilisateurs de niveau Contributeur ou supérieur.

Vous pouvez trouver plusieurs des vulnérabilités basées sur des codes courts que nous référençons par recherche dans la base de données de vulnérabilités Wordfence Intelligence.

Auparavant, notre équipe ne pouvait pas ajouter de règle de pare-feu pour empêcher l’exécution de codes courts arbitraires en raison des différents cas d’utilisation. Heureusement, avec ce correctif et ce changement, le comportement attendu de l’action parse-media-shortcode a été restreint par WordPress Core, nous avons donc pu créer une règle de pare-feu générique qui empêchera l’exécution arbitraire de codes courts qui ne figurent pas dans la liste autorisée de la fonction. Wordfence Premium, Se soucieret Réponse les clients ont reçu cette règle aujourd’hui, tandis que ceux qui utilisent encore la version gratuite de Wordfence recevront cette règle après un délai de 30 jours le 11 novembre 2023.

Scripts intersites réfléchis via les mots de passe d’application

WordPress Core est vulnérable au Reflected Cross-Site Scripting via les paramètres « success_url » et « reject_url » lors de la demande de mots de passe d’application dans les versions comprises entre 5.6 et 6.3.1 en raison d’une vérification insuffisante des entrées et de l’échappement des sorties des URI de pseudo-protocole. Cela permet à des attaquants non authentifiés d’injecter des scripts Web arbitraires dans des pages qui s’exécutent s’ils parviennent à inciter un utilisateur à effectuer une action telle que cliquer sur un lien et accepter ou rejeter le mot de passe de l’application.

WordPress permet aux applications de demander que des mots de passe d’application soient générés pour elles. WordPress avant 6.3.2 ne parvient pas à valider les URI de redirection utilisés lorsqu’un mot de passe est autorisé ou rejeté, ce qui signifie qu’un attaquant pourrait générer une URL pour une demande de mot de passe d’application contenant des redirections de protocole data: et javascript: pseduo. Si la victime visite cette URL sur son site et approuve ou rejette la demande de mot de passe de l’application, elle pourrait être redirigée vers une URI qui exécute JavaScript sur son navigateur. WordPress 6.3.2 contient un patch pour ce problème.

Comme pour toutes les vulnérabilités de Cross-Site Scripting, celle-ci peut être utilisée pour prendre le contrôle d’un site en créant des administrateurs et des portes dérobées malveillants.

Tous les utilisateurs de Wordfence, y compris Wordfence gratuit, Wordfence Premium, Entretien de la clôture des motset Réponse de Wordfence les utilisateurs sont protégés contre cette vulnérabilité par la protection intégrée Cross-Site Scripting du pare-feu Wordfence. De plus, Wordfence désactive les mots de passe des applications par défaut.

Visibilité des commentaires

WordPress Core est vulnérable à l’exposition d’informations sensibles dans les versions jusqu’à la version 6.3.1 incluse via la liste des commentaires. Cela permet aux utilisateurs authentifiés, disposant de privilèges de niveau contributeur ou supérieurs, d’afficher les commentaires sur les publications protégées.

Avant WordPress 6.3.2, il était possible pour les utilisateurs d’afficher les commentaires sur les publications même s’ils n’avaient pas accès à ces publications. Bien qu’il s’agisse dans la plupart des cas d’un problème à impact relativement faible, WordPress 6.3.2 contient un patch protéger la confidentialité des commentaires sur les publications privées ou protégées.

Suppression des chaînes POP

Bien que WordPress Core n’ait pas de vulnérabilité d’injection d’objet connue depuis un certain temps, les vulnérabilités d’injection d’objet dans divers plugins et thèmes sont régulièrement découvertes par les chercheurs, y compris la propre équipe interne de Threat Intelligence de Wordfence.

Toutes les vulnérabilités d’injection d’objet nécessitent des chaînes POP pour réussir. Avant WordPress 6.3.2, les chaînes POP potentielles étaient présentes dans les classes WP_Theme, WP_Block_Type_Registry, WP_Block_Patterns_Registry, Requests/Session, Request/Iri et Requests/Hooks. Bien que nous n’ayons pas pu développer un exploit fonctionnel pour ces derniers dans le temps disponible, les correctifs impliqués indiquent qu’ils sont conçus pour empêcher la désérialisation inattendue d’objets qui pourrait conduire à l’exécution de code à distance. Crédit à Marc Montpas d’Automattic pour découvrir les chaînes POP vulnérables.

L’équipe Wordfence Threat Intelligence poursuivra l’ingénierie inverse de ce correctif pour déterminer si une règle de pare-feu sera nécessaire, mais pour le moment, elle n’a pas reçu d’entrée de vulnérabilité officielle car il ne s’agit pas techniquement d’une vulnérabilité en soi.

Plus besoin de chercher par e-mail

WordPress Core est vulnérable à l’exposition d’informations sensibles dans les versions comprises entre 4.7.0 et 6.3.1 via le point de terminaison User REST. Bien que les résultats de la recherche n’affichent pas les adresses e-mail des utilisateurs, sauf si l’utilisateur demandeur dispose de la capacité « list_users », la recherche est appliquée à la colonne user_email. Cela peut permettre à des attaquants non authentifiés de forcer brutalement ou de vérifier les adresses e-mail des utilisateurs ayant publié des publications ou des pages sur le site.

Bien que WordPress avant la version 6.3.2 n’affichait pas directement les adresses e-mail des utilisateurs sans la fonctionnalité « list_users », il recherchait toujours la colonne e-mail de l’utilisateur dans wp_users. Cela signifiait qu’il était possible d’effectuer une recherche par force brute ou de vérifier l’adresse e-mail de tout utilisateur ayant une publication ou une page publiée en incluant l’adresse e-mail partielle dans le paramètre de recherche, ce qui pouvait avoir un impact sur la confidentialité des utilisateurs. Le patch pour ça limite les colonnes de recherche pour les utilisateurs sans la capacité « list_users » aux seules colonnes affichées.

Déni de service par empoisonnement du cache

WordPress Core est vulnérable au déni de service via l’empoisonnement du cache dans les versions comprises entre 4.7.0 et 6.3.1. Dans les cas où l’en-tête X-HTTP-Method-Override était envoyé dans une requête à un point de terminaison REST et que le point de terminaison renvoyait une erreur 4xx, l’erreur pouvait être mise en cache, entraînant un déni de service.

Les réponses aux requêtes de l’API REST ne sont pas mises en cache pour les utilisateurs connectés, mais WordPress Core avant 6.3.2 présentait un cas limite où, dans des configurations fortement mises en cache, un attaquant non authentifié pouvait envoyer une requête à l’API REST à l’aide de la méthode X-HTTP. -Remplacez l’en-tête par un point de terminaison public et recevez une erreur 4xx, soit parce que le point de terminaison restreint l’accès à ces méthodes, soit ne les prend pas en charge du tout. Dans les cas où l’erreur est mise en cache, tout autre visiteur non authentifié tentant de récupérer des données à partir de ce point de terminaison verra l’erreur 4xx mise en cache.

Scripts intersites stockés dans Contributor+ dans les notes de bas de page

WordPress Core est vulnérable aux scripts intersites stockés via le bloc de notes de bas de page dans les versions comprises entre 6.3 et 6.3.1 en raison d’une vérification insuffisante des entrées et d’un échappement de sortie sur le bloc de notes de bas de page. Cela permet aux attaquants authentifiés disposant d’autorisations de niveau contributeur et supérieures d’injecter des scripts Web arbitraires dans des pages qui s’exécuteront chaque fois qu’un utilisateur accède à une page injectée.

WordPress antérieur à la version 6.3.2 ne nettoyait pas correctement le contenu des blocs de notes de bas de page, permettant aux utilisateurs authentifiés, dotés de privilèges de niveau Contributeur ou supérieurs, d’insérer du JavaScript qui s’exécuterait lorsqu’une page contenant les notes de bas de page était visitée. Bien que l’entrée soit partiellement échappée côté client, il est possible d’intercepter une requête et d’ajouter des balises de script non échappées aux métadonnées de note de bas de page. WordPress a publié un patch pour cette vulnérabilité dans 6.3.2.

Comme pour toutes les vulnérabilités de Cross-Site Scripting, celle-ci peut être utilisée pour prendre le contrôle d’un site en créant des administrateurs et des portes dérobées malveillants.

Nous avons publié une règle de pare-feu pour protéger Wordfence Premium, Entretien de la clôture des motset Réponse de Wordfence les utilisateurs contre cette vulnérabilité, et les utilisateurs gratuits de Wordfence bénéficieront de la même protection dans 30 jours, le 11 novembre 2023.

Scripts intersites stockés par Contributor+ dans les liens de navigation

WordPress Core est vulnérable aux scripts intersites stockés via les attributs du bloc de navigation en flèche dans les versions comprises entre 5.9 et 6.3.1 en raison d’une vérification insuffisante des entrées et de l’échappement des sorties. Cela permet aux attaquants authentifiés disposant de privilèges de niveau contributeur et supérieurs d’injecter des scripts Web arbitraires dans des pages qui s’exécuteront chaque fois qu’un utilisateur accède à une page injectée.

L’éditeur de blocs de WordPress Core comprend un bloc de navigation qui comprend des flèches ou des chevrons pour afficher les publications précédentes et suivantes. WordPress avant 6.3.2 n’a pas réussi à vérifier ou à nettoyer correctement l’attribut définissant s’il faut utiliser une flèche ou un chevron. En conséquence, tout utilisateur ayant accès à l’éditeur de publication pourrait insérer du JavaScript malveillant dans l’élément de navigation fléché, qui serait exécuté chaque fois qu’un visiteur accède à cette page. Comme pour toutes les vulnérabilités de Cross-Site Scripting, celle-ci peut être utilisée pour prendre le contrôle d’un site en créant des administrateurs et des portes dérobées malveillants. Nous n’avons pas réussi à exploiter cette vulnérabilité au moment de la publication, mais nous mettrons à jour cet article si nous parvenons à réaliser une preuve de concept, ainsi qu’une règle de pare-feu si nécessaire pour protéger nos utilisateurs.

Conclusion

WordPress 6.3.2 inclut des correctifs pour 5 vulnérabilités de gravité moyenne ainsi qu’un renforcement contre les vulnérabilités d’injection d’objet distinctes trouvées dans les plugins et thèmes tiers. Plusieurs de ces vulnérabilités sont triviales à exploiter et nous vous recommandons de mettre à jour immédiatement si votre site ne l’a pas encore fait automatiquement.

Nous avons publié des règles de pare-feu pour protéger Wordfence Premium, Entretien de la clôture des motset Réponse de Wordfence clients contre les vulnérabilités les plus impactantes et ces règles seront disponibles gratuitement pour les utilisateurs de Wordfence dans 30 jours, le 11 novembre 2023.

Si vous connaissez quelqu’un qui utilise WordPress et ne le maintient pas automatiquement à jour, nous vous recommandons de partager cet avis avec lui pour garantir la sécurité de son site, car plusieurs de ces vulnérabilités présentent un risque important.

Pour les chercheurs en sécurité cherchant à divulguer les vulnérabilités de manière responsable et à obtenir un identifiant CVE, vous pouvez soumettre vos résultats à Wordfence Intelligence et potentiellement gagner une place dans notre classement.

Un merci spécial aux chercheurs en sécurité qui ont divulgué ces vulnérabilités de manière responsable, ainsi qu’à Chloe Chamberland, responsable des renseignements sur les menaces, pour son aide dans cet article et pour avoir rédigé les règles de pare-feu pour protéger les clients de Wordfence.


Source link