Ca va bientôt faire deux mois que la BH 2009 est fini, mais ça n'est que maintenant que j'arrive à pondre un petit billet qui lui est vaguement relié...décidément j'ai encore du chemin à parcourir pour atteindre la réactivité de certains !

En survolant les présentations faites à la dernière black hat il y en a une qui m'a tout particulièrment interpellée, c'est la présentation faite par Egypt (projet metasploit) sur le tout nouveau module browser_autopwn. En résumé ce module ouvre un serveur HTTP en écoute, quand un navigateur s'y connecte il note tout un tas d'informations pour essayer de l'identifier (principalement le user-agent en fait), puis il répond avec un javascript obfusqué dont le seul but et d'aider à l'identification précise du navigateur et de l'OS qui le fait tourner. Les informations receuillies par le javascript sont retournées au module qui lance alors tous les exploits dont il dispose et qui correspondent au navigateur et à l'OS identifié :) Bref c'est le même état d'esprit que l'excellent db_autopwn, mais coté exploitation client plutôt qu'exploitation serveur.

Quand j'ai lu cette présentation je me suis dit qu'il fallait absolument que j'essaie ça, mais je n'ai finalement eu le temps que très récemment et comme j'aime bien partager (et que j'ai monté mon blog pour ça lol) je vais vous relater les tests que j'ai fait :

D'abord j'ai re-téléchargé metasploit puisque ça faisait plusieurs mois que je n'y avais pas touché puis je me suis rendu compte que j'avais oublié comment on faisait pour faire une mise à jour (histoire d'être certains d'avoir tous les derniers exploits)...Ca m'a bien pris une heure avant de me le rappeller et même si ça me fait passer pour un con (parce que, franchement, faut être con pour avoir mis 1h à se souvenir de ça lol) je vous donne la méthode ici, ça vous évitera de longues minutes de googlages inutiles : svn update¹ ...Ah bah ouais, j'vous avais prévenu que c'était con ;)

Une fois dans metasploit je recherche le petit nom exact du module > search browser_autopwn et le framework me répond gentiment server/browser_autopwn Je charge donc le module > use server/browser_autopwn , je regarde les options > show options et je renseigne les essentielles, en particulier l'adresse sur laquelle mettre le serveur http en écoute > set SRVHOST 192.168.69.1 et l'URI que le navigateur devra demander pour tomber sur le piège automatique >set URIPATH boum. Je suis donc fin prêt, il n'y a plus qu'à lancer le jouet > exploit. Tout impatient j'attend que metasploit ai fini de charger tous ses exploits puis je lance ensuite mon navigateur préféré sur le même pc que tourne metasploit et j'accède à l'URL http://localhost:8080/boum et là : rien. Mon firefox 3.5.2 tournant sous linux est certainement trop solide parce que metasploit a beau avoir tenté un ou deux exploits je ne retrouve aucun reverse shell établi avec succès ( > sessions -l ).

Qu'à celà ne tienne, j'ai plus d'un tour dans mon sac :) ! Il y a quelques années quand j'avais acheté mon ordi portable j'avais du m'acquiter de la taxe microsoft, mais comme j'utilise très très très peu cet OS il y avait de vives chances que je ne sois pas à jour en termes de patchs de sécurité. Je boot donc mon pc portable sous windows, et c'est avec délectation que je lance un gentil Firefox 2.0 depuis mon brave XP SP2....résultat : néant :( Firefox rame un peu, mais toujours aucun reverse shell n'apparait dans metasploit en réponse à mes > sessions -l. Petite déception, mais je ne me laisse pas démonter et je lance mon arme ultime : le vieil IE6.0 qui traine. Hop je le lance et j'accède à http://192.168.69.1:8080/boum. Metasploit envoie son armée d'exploits et là....rien :( Toujours aucunes sessions ouvertes.

J'ai ensuite lu un petit peu les paramètres des exploits que browser_autopwn automatise et il me semble que le IE6.0 aurait du tomber (pas les autres, faute d'exploits adéquats)...N'ayant pas assez de temps pour regarder plus en détails je vais donc pour l'instant conclure de ces petits tests que browser_autopwn est certes redoutable mais qu'il ne remplace pas encore un peu d'huile de coude, de milw0rm, et de social engineering :)

1. à lancer dans le répertoire de metasploit bien entendu... ↩

Allez, encore un titre de billet à la c*n basé sur un jeu de mot douteux. Donc, vous avez une petite idée de ce dont ce billet va parler ?...Nan ?..Toujours pas ?...Bon et bien je vous donne la réponse alors : les Gifar (jeu de mot avec "Jafar") Les gifars ne sont pas bien nouveaux (ça a au moins un an si je ne m'abuse), mais j'ai un petit peu l'impression que le concept a fait un "flop" assez vite après avoir été dévoilé, d'où la suite du titre : "j'suis coincé" (la citation entière "Jafar j'suis coincé" étant un moment drolissime du film "Aladdin" de Disney, 1992, ça ne nous rajeunit pas tout ça). Bon, maintenant que vous savez de quoi nous allons parler, passons aux choses sérieuses !

GIFAR, c'est quoi ?

Un GIFAR c'est un fichier GIF combiné à un fichier JAR. Pour être plus précis je pourrai d'ailleurs dire "concaténé" plutôt que "combiné". Et voilà. C'est juste ça.

L'intérêt des GIFAR c'est qu'un fichier GIF se lit à partir du début (c'est assez instinctif) avec un header suivit du contenu à proprement parler, en revanche les fichier JAR (qui ne sont en fait que des fichiers ZIP) se lisent en partant de la fin ! Ainsi si on concatène un fichier GIF avec un fichier JAR on peut lire le fichier résultant dans les deux sens (i.e. à partir du début ou à partir de la fin) et trouver ainsi, selon le sens choisi, un fichier GIF ou un fichier JAR tout à fait correct.

Ce type de fichier est donc assez amusant puisqu'on y voit ce que l'on vient y chercher : si vous cherchez un GIF vous trouverez bien un GIF, si vous chercher un JAR vous trouverez bien un JAR. Là où ça devient utile c'est que beaucoup de sites web permettent aux utilisateurs d'uploader des images et vérifient, au moment de l'upload, qu'il s'agit bien d'une image et non d'un quelconque code malveillant...ça tombe bien un GIFAR c'est une image au format GIF tout à fait correct :) ...mais un GIFAR c'est aussi un joli fichier JAR tout à fait correct également¹.

Et comment ça s'exploite ?

Bon, maintenant que l'on sait ce qu'est un GIFAR : à quoi celà peut il bien servir ? Dans le paragraphe précédent on a déjà apporté une réponse triviale : ça sert à travestir un fichier JAR sous les traits d'un fichier GIF, et donc ça peut servir à uploader des fichiers JAR sur des serveurs qui n'acceptent que les fichiers images. Mais ensuite ? Mon petit avis à deux sesterces sur la question c'est que les GIFAR n'ont pas fait tant de bruits que ça parce que, justement, ils sont assez délicats à exploiter.

La première attaque qui vient à l'esprit consiste en effet à uploader notre GIFAR puis à "se demmerder" pour faire exécuter le JAR dans le navigateur des visiteurs. Petit souci : pour que ça soit faisable il faut un XSS dans le site en question afin d'ajouter les balises HTML qui vont bien pour introduire notre GIFAR en tant que JAR dans les pages du site (et non en tant que GIF, ce qui manquerait d'intéret). On voit donc bien qu'une telle attaque nécessite à la fois une vérification laxiste du type d'image uploadé et un XSS, ce qui commence à faire beaucoup. De plus si on met en perspective l'intéret d'une telle exploitation on se rend compte que c'est beaucoup d'efforts pour pas grand chose : par défaut une applet java ne peut quasiment rien faire (pas d'accès au disque local du client, et pas de communication réseau sauf vers le site d'où provient l'applet). Néanmoins il y a moyen de contourner ces limitations :

• Navigateur web mal configuré qui autorise les applet à foutre le chantier sur le disque local (rarissime...j'espère);
• utilisation de requête réseau vers le site où est hébergé le GIFAR afin d'essayer de laisser des traces quelque part de données clients que l'on voudrait récupérer (ex: si on est sur un forum on fait une requête qui va nous envoyer un message privé contenant le contenu des cookies qui nous intéresse...pour peu qu'ils ne soit pas en http-only bien entendu);
• et enfin : la signature des applets.

La signature des applets ? Oui oui, la signature des applets. Une applet, ça peut se signer :) Une applet signée s'affranchit d'ailleurs de quasiment toutes les limitations (i.e. : on obtient l'accès au disque dur, on peut ouvrir des socket vers n'importe où, etc.) ce qui en fait d'excellents candidats à une attaque par GIFAR+XSS. Comment fait on pour signer une applet alors me direz vous ? Celà doit être extrèmement compliqué. Et bien non, ça se fait en deux lignes avec les outils du JDK :

$ keytool -genkey -alias votreAlias
$ jarsigner -verbose monapplet.jar votreAlias

Easy as a Pie :) ...MAIS ça n'est pas gagné pour autant. En effet une applet signée s'affranchit de toutes les limitations, mais pour qu'elle ai le droit de s'exécuter l'utilisateur doit l'y autoriser explicitement, donc vous allez avoir un gros vilain popup tout moche qui demandera à l'utilisateur si il souhaite exécuter cette applet. Bon, ça n'est pas la fin du monde, mais ça commence à devenir lourdingue puisqu'il nous faut, pour une exploitation réussi : pouvoir uploader un GIF, trouver un XSS, que la victime de notre XSS accepte explicitement de lancer notre applet.

Conclusion

Après ce petit article introductif tout mignon sur les GIFAR vous réalisez bien que ça n'est pas la panacée, mais je pense que c'est tout de même un excellent petit "trick" à avoir dans sa besace en cas d'attaques combinées ou d'exploitation délicate, et c'est pour ça que j'ai réalisé cet article :) Par exemple il pourrait vous être bien utile si vous vous retrouvez coincé en pentest sur une machine avec juste une ligne de commande limitée en taille et pas d'accès aux logiciels de téléchargement usuels (wget, tftp, etc.) mais que vous pouvez uploader des GIF...

1. pour les rares qui auraient lu l'article jusqu'ici sans savoir ce qu'est un fichier JAR : c'est une archive de code java exécutable ↩