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.

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…)