Le 19 novembre 2020, notre équipe Threat Intelligence a divulgué de manière responsable deux vulnérabilités dans Orbit Fox par ThemeIsle, un plugin WordPress utilisé par plus de 400 000 sites. L’une de ces failles a permis aux attaquants disposant d’un accès de niveau contributeur ou supérieur d’élever leurs privilèges à ceux d’un administrateur et potentiellement de prendre le contrôle d’un site WordPress. L’autre faille a permis aux attaquants disposant d’un accès au niveau contributeur ou auteur d’injecter du JavaScript potentiellement malveillant dans les publications. Ces types de scripts malveillants peuvent être utilisés pour rediriger les visiteurs vers des sites de publicité malveillante ou créer de nouveaux utilisateurs administratifs, parmi de nombreuses autres actions.

Nous avons initialement contacté le développeur du plugin le 19 novembre 2020. Après avoir établi un canal de communication approprié, nous avons fourni tous les détails de divulgation le 24 novembre 2020. Après quelques suivis, le développeur du plugin a publié une version corrigée d’Orbit Fox par ThemeIsle en version 2.10.13, le 17 décembre 2020.

Ce sont des vulnérabilités critiques et de gravité moyenne. Par conséquent, nous vous recommandons vivement de passer immédiatement à la version corrigée, 2.10.13.

Les utilisateurs de Wordfence Premium ont reçu une règle de pare-feu pour se protéger contre tout exploit visant ces vulnérabilités le 19 novembre 2020. Les sites utilisant toujours la version gratuite de Wordfence ont reçu la même protection le 19 décembre 2020.

La description: Escalade des privilèges authentifiés
Plugin concerné: Orbit Fox par ThemeIsle
Plugin Slug: themeisle-compagnon
Versions concernées:
ID CVE: En attente.
Score CVSS: 9,9 (CRITIQUE)
Vecteur CVSS: CVSS: 3.1 / AV: N / AC: L / PR: L / UI: N / S: C / C: H / I: H / A: H
Version entièrement corrigée: 2.10.13

Orbit Fox de ThemeIsle est un plugin conçu pour améliorer les éditeurs Elementor, Beaver Builder et Gutenberg avec des fonctionnalités supplémentaires telles que les formulaires d’inscription ainsi que d’autres blocs et widgets qui peuvent être utilisés lors de l’édition de publications et de pages.

Dans le cadre du plugin, il existe un widget d’inscription qui peut être utilisé pour créer un formulaire d’inscription avec des champs personnalisables lors de l’utilisation des plugins de création de page Elementor et Beaver Builder. Lors de la création du formulaire d’inscription, le plugin offre la possibilité de définir un rôle par défaut à utiliser chaque fois qu’un utilisateur s’inscrit à l’aide du formulaire.

Widget d’inscription Orbit Fox.

Les utilisateurs de niveau inférieur tels que les contributeurs, les auteurs et les éditeurs n’ont pas eu la possibilité de définir le rôle d’utilisateur par défaut à partir de l’éditeur. Cependant, nous avons constaté qu’ils pouvaient toujours modifier le rôle d’utilisateur par défaut en créant une requête avec le paramètre approprié. Le plug-in offrait une protection côté client pour empêcher le sélecteur de rôle d’être affiché aux utilisateurs de niveau inférieur lors de l’ajout d’un formulaire d’inscription. Malheureusement, il n’y avait aucune protection ou validation côté serveur pour vérifier qu’un utilisateur autorisé définissait réellement le rôle d’utilisateur par défaut dans une demande.

{"save_builder":{"action":"save_builder","data":{"status":"publish","elements":[{"id":"be9a476","elType":"section","isInner":false,"settings":{},"elements":[{"id":"7ea305d","elType":"column","isInner":false,"settings":{"_column_size":100,"_inline_size":null},"elements":[{"id":"6edacb5","elType":"widget","isInner":false,"settings":{"form_fields[...],"submit_label":"Register","user_role":"administrator"},"elements":[],"widgetType":"content_form_registration"}]}]}],"settings":{"post_title":"BadPost","post_status":"pending"}}}}',

L’absence de validation côté serveur signifiait qu’un utilisateur de niveau inférieur ayant accès à l’éditeur de page / article, comme les contributeurs, les auteurs et les éditeurs, pouvait créer un formulaire d’inscription et définir le rôle d’utilisateur sur celui d’un administrateur après une inscription réussie. Une fois le formulaire d’inscription créé, l’utilisateur pouvait simplement enregistrer un nouvel utilisateur et cet utilisateur se verrait accorder des privilèges d’administrateur même s’il était encore authentifié sur l’instance WordPress.

Pour exploiter cette faille, l’enregistrement des utilisateurs devrait être activé et le site devrait exécuter les plugins Elementor ou Beaver Builder. Un site avec l’enregistrement de l’utilisateur désactivé ou aucun de ces plugins installé ne serait pas affecté par cette vulnérabilité.

La description: Scripting intersite stocké authentifié
Plugin concerné: Orbit Fox par ThemeIsle
Plugin Slug: themeisle-compagnon
Versions concernées:
ID CVE: En attente.
Score CVSS: 6,4 (MOYEN)
Vecteur CVSS: CVSS: 3.1 / AV: N / AC: L / PR: L / UI: N / S: C / C: L / I: L / A: N
Version entièrement corrigée: 2.10.13

En plus de la vulnérabilité d’escalade de privilèges que nous avons découverte, nous avons également constaté que les contributeurs et les auteurs pouvaient ajouter des scripts aux articles même s’ils n’avaient pas le unfiltered_html grâce à la fonctionnalité de script d’en-tête et de pied de page dans Orbit Fox.

Zone de script d’en-tête et de pied de page Orbit Fox.

Cette faille permettait aux utilisateurs de niveau inférieur d’ajouter du JavaScript malveillant aux publications qui s’exécuteraient dans le navigateur chaque fois qu’un utilisateur accédait à cette page.

Comme toujours avec les vulnérabilités XSS, cela permettrait aux attaquants de créer de nouveaux utilisateurs administratifs, d’injecter des redirections et des portes dérobées malveillantes, ou de modifier d’autres contenus de site via l’utilisation de JavaScript malveillant.

L’importance de la validation côté serveur par rapport à la validation côté client

Les développeurs peuvent valider les entrées de l’utilisateur dans WordPress de deux manières principales, soit du côté client dans un navigateur lors de la soumission des données, soit sur le serveur après que les données ont été soumises par l’utilisateur. S’assurer que les entrées utilisateur sont valides est une partie importante de l’intégrité et de la sécurité des données d’une application, il est donc important pour les développeurs de comprendre la différence entre la validation côté client et côté serveur.

La validation côté client se produit lorsque l’entrée est validée par des scripts dans le navigateur avant d’être envoyée au serveur. Par exemple, lors du remplissage d’un formulaire, l’entrée peut être vérifiée et supprimée pour les caractères Cross-Site Scripting tels que <> dans le navigateur lors de la soumission avant que les données ne soient envoyées via une demande au serveur. Cela se fera généralement à l’aide d’un langage de programmation côté client tel que JavaScript.

La validation côté serveur se produit une fois que les données atteignent le serveur et est effectuée dans un environnement contrôlé. Par exemple, lorsque vous remplissez un formulaire, l’entrée sera envoyée au serveur au fur et à mesure que l’utilisateur l’a saisie, sans aucune validation, édition ou modification. Une fois que le serveur reçoit la demande, il vérifie les problèmes de sécurité, s’assure que les données sont correctement formatées et prépare la soumission pour l’insertion ou la mise à jour vers une source de données. Cela se fait avec du code qui s’exécute côté serveur, et dans le cas de WordPress, ce serait PHP.

Ne vous fiez jamais uniquement à la validation côté client. La validation côté client n’est pas infaillible. Étant donné que la validation côté client est effectuée sur l’ordinateur d’un utilisateur dans son navigateur, les demandes peuvent être interceptées une fois qu’elles ont quitté le navigateur de l’utilisateur avant d’être traitées par le serveur. Un script basé sur un navigateur peut supprimer les balises de script intersite de la requête envoyée par le navigateur, cependant, un attaquant peut intercepter la requête et rajouter les balises de script. S’il n’y a pas de validation côté serveur, ces scripts les balises seront acceptées et utilisées malgré les protections côté client en place. Les attaquants familiers avec une application peuvent également générer par programme des demandes et des entrées de formulaire, contournant complètement les protections côté client afin d’interagir avec un site.

Pour cette raison, nous vous recommandons de toujours utiliser la validation côté serveur sur les demandes. La validation côté client doit être utilisée comme complément si nécessaire. Cela empêchera les demandes d’être modifiées en transit du navigateur vers le serveur et empêchera tout contournement des protections côté client qui sont en place.

Calendrier de divulgation

19 novembre 2020 – Conclusion de l’analyse du plugin qui a conduit à la découverte de deux vulnérabilités dans le plugin Orbit Fox by ThemeIsle.
19 novembre 2020 – Nous développons des règles de pare-feu pour protéger les clients Wordfence et les diffusons aux utilisateurs de Wordfence Premium. Nous prenons contact avec le développeur du plugin.
23 novembre 2020 – Le développeur du plugin confirme la boîte de réception pour gérer la discussion.
24 novembre 2020 – Nous soumettons une divulgation complète.
8 décembre 2020 – Nous assurons le suivi car nous n’avons pas encore reçu de réponse de notre divulgation.
15 décembre 2020 – Nous envoyons notre dernier suivi indiquant que nous devrons escalader le processus conformément à nos directives de divulgation si aucune réponse n’est reçue avant le 18 décembre.
17 décembre 2020 – Nous recevons une réponse et une version corrigée du plugin est publiée en version 2.10.13. Nous vérifions que les vulnérabilités ont été corrigées.
19 décembre 2020 – Les utilisateurs gratuits de Wordfence reçoivent une règle de pare-feu.

Conclusion

Dans l’article d’aujourd’hui, nous avons détaillé deux failles dans Orbit Fox par ThemeIsle qui permettaient aux attaquants d’élever les privilèges et d’injecter du JavaScript potentiellement malveillant dans les publications. Ces failles ont été entièrement corrigées dans la version 2.10.13. Nous recommandons aux utilisateurs de mettre immédiatement à jour vers la dernière version disponible, qui est la version 2.10.13 au moment de cette publication.

Wordfence Premium les utilisateurs ont reçu des règles de pare-feu protégeant contre ces vulnérabilités le 19 novembre 2020, tandis que ceux qui utilisent encore la version gratuite de Wordfence ont reçu la même protection le 19 décembre 2020.

Si vous connaissez un ami ou un collègue qui utilise ce plugin sur son site, nous vous recommandons vivement de lui transmettre cet avis pour aider à garder ses sites protégés car il s’agit de vulnérabilités critiques et de haute gravité qui peuvent conduire à une prise de contrôle complète du site.


Source link