XSS2Shell : une chaîne pré-authentification peut transformer WordPress en porte d’entrée vers le serveur

Découvrez XSS2Shell, une attaque pré-authentification exploitant WordPress via DOM clobbering et REST API pour compromettre le serveur et exécuter du code.

XSS2Shell : une chaîne pré-authentification peut transformer WordPress en porte d’entrée vers le serveur
Vulnérabilités

Image d’illustration générée par IA

De la page de connexion au DOM clobbering

Les chercheurs de Pwn ont récemment décrit XSS2Shell, une chaîne d’attaque critique qui part de la page de connexion de WordPress et ne nécessite aucune authentification préalable.

L’attaque utilise un nom d’utilisateur inexistant, répercuté dans le message d’erreur. Le premier filtre appliqué par PHP via strip_tags() ne reconnaît pas comme balises valides les éléments écrits avec un espace entre le caractère < et le nom :

< area id=ajaxurl>

Le wp_kses_post() exécuté ensuite interprète toutefois la chaîne comme un élément HTML valide et la transforme en contenu actif dans le DOM.

L’attribut id="ajaxurl" permet alors un DOM clobbering : le navigateur expose l’élément comme propriété window.ajaxurl, modifiant le comportement attendu des scripts de la page.

L’abus de user-profile.js et de la REST API

La page de connexion charge également user-profile.js, utilisé pour gérer les réinitialisations de mots de passe. Le script peut détecter et activer automatiquement un bouton de réinitialisation manipulé, sans clic explicite de l’administrateur.

La chaîne exploite ensuite une réponse JSONP de la REST API. Le paramètre callback accepte les points, ce qui permet de parcourir des chaînes de propriétés entre fenêtres du navigateur. Les chercheurs ont réutilisé une technique rendue publique pour la première fois en 2022 afin d’obtenir un clic cross-window dans la session active d’un administrateur authentifié.

Le navigateur est dirigé vers un écran WordPress destiné à approuver les Application Passwords. Les cookies et le nonce de la session d’administration permettent d’activer automatiquement le bouton d’approbation.

Le résultat est l’obtention d’une Application Password valide pour le compte administrateur.

De la compromission des identifiants à l’exécution potentielle de code

WordPress accepte l’Application Password via l’authentification HTTP Basic sur la REST API. La configuration CORS reflète l’origine de la requête et autorise les en-têtes Authorization et Content-Type, permettant ainsi des appels API authentifiés cross-origin.

Sur les installations single-site, les administrateurs disposent généralement de la capability unfiltered_html. Du JavaScript arbitraire peut donc rester dans les contenus publiés.

L’attaquant peut publier une page contenant du code JavaScript, l’utiliser pour charger un plugin et parvenir à l’exécution de code PHP arbitraire. Dans la preuve de concept, une réponse JSON a confirmé l’exécution avec l’identité de l’utilisateur du serveur web.

L’impact potentiel comprend :

  • la compromission de la session d’administration ;
  • l’émission frauduleuse d’Application Passwords ;
  • la publication de contenu JavaScript ;
  • l’installation de plugins malveillants ;
  • l’exécution de code à distance (Remote Code Execution) ;
  • une possible prise de contrôle complète du serveur.

La preuve de concept n’a laissé aucune persistance : les chercheurs ont révoqué l’identifiant, supprimé la page et effacé le répertoire du plugin.

Ce que les administrateurs doivent vérifier

Aucun identifiant CVE ni numéro de version vulnérable ou corrigée n’a été communiqué pour WordPress, PHP, les navigateurs ou les composants concernés.

Les administrateurs devraient :

  1. mettre à jour WordPress vers les versions corrigées publiées par l’éditeur ;
  2. appliquer les mises à jour de sécurité de WordPress, de PHP et des composants installés ;
  3. révoquer les Application Passwords suspectes ou inutiles ;
  4. vérifier les pages publiées, les plugins, les répertoires de plugins et les journaux de la REST API ;
  5. rechercher des requêtes anormales vers les points de terminaison d’approbation des Application Passwords ;
  6. surveiller le trafic JSONP et les appels cross-origin contenant l’en-tête Authorization ;
  7. réduire les privilèges d’administration et limiter, lorsque cela est possible, l’utilisation de unfiltered_html.

Les versions concernées ne sont pas connues. Par conséquent, l’absence de comportement anormal observable ne suffit pas à écarter l’hypothèse d’une compromission.

Dossiers sécurité

À lire aussi

Sources

Cet article est une réécriture originale fondée sur les sources ci-dessous.

Retour à l'accueil

Dernières actualités cybersécurité

Toutes les actualités cybersécurité →