Le 17 janvier, notre équipe Threat Intelligence a découvert plusieurs vulnérabilités dans Tableau des prix par Supsystic, un plugin WordPress installé sur plus de 40 000 sites. Ces failles ont permis à un utilisateur non authentifié d’exécuter plusieurs actions AJAX en raison d’une faiblesse des autorisations non sécurisées. Les attaquants ont également pu injecter du Javascript malveillant en raison d’une vulnérabilité XSS (Cross-Site Scripting), accéder aux données de la table de tarification et falsifier des demandes au nom d’un administrateur de site en raison d’une vulnérabilité CSRF (Cross-Site Request Forgery).

Ces vulnérabilités pourraient permettre aux attaquants d’exécuter du Javascript malveillant sur le navigateur d’un visiteur qui pourrait rediriger les visiteurs du site vers des sites Web malveillants, ou même voler des cookies utilisateur pour s’authentifier en tant qu’administrateur. Nous avons divulgué ces problèmes en privé à l’auteur du plugin, qui a publié les correctifs un mois plus tard.

Nous vous recommandons vivement de mettre à jour la version 1.8.2 immédiatement, car ces problèmes de sécurité sont entièrement corrigés dans cette version.

Les utilisateurs premium de Wordfence ont reçu une nouvelle règle de pare-feu le 18 janvier pour se protéger contre les exploits ciblant ces vulnérabilités. Les utilisateurs de Wordfence gratuit ont reçu cette règle le 17 février.


Le tableau des prix de Supsystic offre aux utilisateurs la possibilité d’ajouter facilement des tableaux de prix personnalisables à leur site. Ceux-ci peuvent être utilisés pour afficher les prix des produits ou des services et comparer les différences entre chaque offre. Le plugin permet de créer facilement de nouvelles tables, d’importer ou de modifier des tables et d’exporter des paramètres de table de tarification, tous alimentés par des actions AJAX. Lors de l’analyse du plugin, nous avons découvert que les actions AJAX étaient enregistrées avec un wp_ajax_nopriv_ hook, permettant à tout utilisateur non authentifié d’envoyer avec succès une demande AJAX complétant une action enregistrée avec ce hook.

 add_action('wp_ajax_nopriv_'. $this->_action, array($mod->getController(), $this->_action)); 

Après une analyse plus approfondie, nous avons constaté que, malgré les actions enregistrées auprès d’un wp_ajax_nopriv_ crochet, il y avait un contrôle d’autorisation de sécurité distinct sur presque toutes les actions AJAX. Cependant, nous avons constaté que la vérification des autorisations manquait pour quelques actions de sélection. Les actions manquant une vérification d’autorisation étaient: createFromTpl, une fonction qui crée de nouvelles tables de tarification, getJSONExportTable, une fonction utilisée pour exporter des tables existantes, et importJSONTable, une fonction utilisée pour importer une nouvelle table de tarification ou mettre à jour une ancienne.

        public function getPermissions() {
	                return array(
                        PTS_USERLEVELS => array(
	                                PTS_ADMIN => array('getListForTbl', 'remove', 'removeGroup', 'clear',
                                        'save', 'exportForDb', 'updateLabel', 'changeTpl', 'saveAsCopy', 'getJSONExportTable', 'createFromTpl')

** Vous pouvez voir dans cet extrait de code que getJSONExportTable, importJSONTable, et createFromTpl sont absents du contrôle getPermissions au bas de la controller.php fichier. Ceux-ci ont été ajoutés dans la dernière version du plugin.

Cela signifiait que tout utilisateur non authentifié pouvait exécuter ces 3 fonctions et obtenir des informations sensibles concernant une table de tarification donnée lors de la création et de l’importation de nouvelles tables de tarification ou de la modification de celles déjà existantes.

Informations extraites de getJSONExportTable.


Dans le prolongement de la vulnérabilité précédente, nous avons découvert qu’une vulnérabilité XSS stockée pouvait être exploitée à partir du importJSONTable point final. Cette fonction est utilisée pour importer un corps JSON contenant tous les paramètres nécessaires pour créer une nouvelle table de tarification ou en modifier une déjà existante.

Plusieurs des paramètres sont traités sans aucun filtrage d’entrée, permettant Javascript comme entrée. Seul, cela ne serait pas considéré comme un problème de sécurité, car les entrées utilisateur fournies via le tableau de bord administratif ne sont pas filtrées car les administrateurs ont la possibilité d’ajouter unfiltered_html. Cependant, lorsqu’elle est combinée à une situation où des actions AJAX peuvent être envoyées sans authentification, une vulnérabilité XSS est créée.

Afin d’exploiter cette vulnérabilité, un attaquant devrait envoyer une requête contenant les détails de la table qu’il souhaite modifier, ainsi que sa charge utile Javascript malveillante. Cette charge utile pourrait être un script qui vole les cookies des utilisateurs et les envoie à un attaquant pour que l’attaquant obtienne un accès administratif à votre site. Alternativement, cette charge utile pourrait également être un script qui redirige les utilisateurs vers un site malveillant où leur ordinateur sera infecté. Le javascript malveillant serait alors exécuté à chaque fois qu’un utilisateur accède à la page avec le script stocké.

Un attaquant pourrait modifier une table de tarification afin que la charge utile malveillante ne s’exécute que lorsqu’un administrateur accède à la liste de la table de tarification à partir du tableau de bord administratif, ou elle peut être exécutée lorsqu’un utilisateur accède à une page qui affiche une table de tarification. Cela dépendait simplement du paramètre dans lequel le Javascript malveillant était injecté.

Voici à quoi cela ressemblerait si seulement le paramètre name était injecté dans le paramètre label de données et exécuté dans le tableau de bord administratif.

Voici à quoi cela ressemblerait si le paramètre html personnalisé était injecté, s’exécutant sur le front-end d’un site.


Pour intensifier davantage, nous avons constaté qu’aucun des points de terminaison du plugin n’était protégé par des nonces WordPress pour la protection CSRF. La source des demandes n’a pas été vérifiée et un attaquant pourrait forger une demande spécialement conçue au nom d’un administrateur de site et injecter du Javascript malveillant ou simplement modifier les paramètres d’une table de prix donnée.

Procédure pas à pas PoC: Exploiter XSS

Calendrier de divulgation

17 janvier 2020 – Vulnérabilité initialement découverte et analysée. Nous commençons à travailler sur les règles de pare-feu.
18 janvier 2020 – Règle de pare-feu publiée pour les utilisateurs premium de Wordfence. Ouverture initiale à l’équipe du plugin.
21 janvier 2020 – Le développeur confirme la boîte de réception appropriée pour gérer la discussion. Une divulgation complète des vulnérabilités est envoyée.
30 janvier 2020 – Suivi avec le développeur comme aucune réponse de divulgation.
10 février 2020 – Suivi supplémentaire car aucune réponse de divulgation n’est encore.
11 février 2020 – Le développeur reconnaît le rapport. Nous informe que le patch sortira la semaine suivante.
17 février 2020 – Les utilisateurs gratuits de Wordfence reçoivent une règle de pare-feu.
21 février 2020 – Patch publié. Vérification des autorisations manquante sur une action, développeur notifié.
24 février 2020 – Patch suffisant publié.

Conclusion

Dans la publication d’aujourd’hui, nous avons détaillé plusieurs vulnérabilités, notamment les autorisations XSS, CSRF et non sécurisées stockées dans le module de tarification du plugin Supsystic. Ces failles ont été corrigées dans la version 1.8.2 et nous recommandons aux utilisateurs de mettre à jour vers la dernière version disponible immédiatement. Sites en cours d’exécution Wordfence Premium sont protégés des attaques contre cette vulnérabilité depuis le 18 janvier. Les sites exécutant la version gratuite de Wordfence ont reçu la même mise à jour des règles de pare-feu le 17 février 2020.


Source link