Logo Blog perso d'Ozwald

Coincidence

Par Oz le - Sécurité
CVE-2008-5353 GIFAR

Voici une bien jolie coïncidence je trouve, bien qu'avec un peu de travail et de jugeotte j'aurai peut être été capable de le faire exprès : on peut vaguement lier un récent buzz au sujet abordé dans l'un de mes tout derniers articles, article qui ne portait pas du tout sur une faille à la mode pourtant :) ! Du coup, faute de temps, vous n'aurez pas droit sur ce billet à un jeu de mot débile pour le titre et en prime il sera un peu moins fouillé que ce que j'aurai aimé faire. Mais bon, c'est le prix à payer pour publier pendant que c'est encore dans le vent :) (ne vous inquiétez pas : je ferai un article plus détaillé plus tard !)

Gros titres - Creative Common by "christopher.woo" on Flickr

Mais de quel buzz parle-t-il ?

Je parle du buzz portant sur le CVE-2008-5353. Oui : rien de bien nouveau (le numéro de CVE ne trompe pas), et pourtant ça ne buzz que maintenant (l'explication plus tard). Ce CVE parle d'une faille dans la JRE qui permet, via un petit tour de passe-passe, de contourner la sandbox dans laquelle les applet java sont cloisonnées lorsqu'elles sont exécutées dans le contexte d'un navigateur web. Pas mal du tout quand on sait qu'une fois sorti de la sandbox l'applet java peut exécuter n'importe quelle commande système avec les droits de l'utilisateur qui fait tourner le navigateur web. Par exemple en surfant simplement sur une page "lambda", si vous avez accepté les applet java (ce qui est par exemple le cas par défaut dans Safari sur MacOSX...) l'applet peut, à votre insu, télécharger un fichier, l'enregistrer dans un coin sur le disque dur, lui donner les droits d'exécution, et enfin s'arranger pour qu'il soit exécuté à chaque ouverture de session (si jamais ça vous rappelle quelque chose, c'est que vous n'êtes pas stupide ;) )

Backdoor - Creative Common by "Anders Ljungberg" on Flickr

Parlons technique !

Comment, techniquement, celà se fait-il ? Et bien c'est sur cette partie que j'aurai aimé pouvoir passer plus de temps parce que n'étant pas un expert de Java j'ai un peu de mal à saisir rapidement toutes les subtilités du chmilblick. Enfin je tente tout de même de vous relater ce que j'ai saisi, et je ferai un article plus détaillé quand j'aurai eu le temps de bien comprendre.

En substance Java permet la sérialisation d'objets et c'est là dedans qu'on va aller fouiller. En effet la dé-sérialisation de l'objet de type "sun.util.calendar.ZoneInfo" est, semble-t-il pour des raisons historiques, gérée dans un bloc à privilèges élevés (i.e. il s'affranchit des restrictions de type sandbox). Jetons un oeil au code de désérialisation des objets de type "sun.util.calendar" pour bien comprendre :

private void readObject(ObjectInputStream input) throws IOException, ClassNotFoundException 
{
   ...
   ZoneInfo zoneinfo = (ZoneInfo)AccessController.doPrivileged(new PrivilegedExceptionAction() {
           public Object run() throws Exception
           {
               return input.readObject();
           }
   });
   if (zi != null) {
          zone=zi;
   }
...
}

Donc, comment exploiter ça ? L'idée c'est de demander la désérialisation d'un objet qui soit reconnu comme de classe "sun.util.calendar", nous démmerder pour que la désérialisation de l'objet "sun.util.calendar.ZoneInfo" soit en réalité la désérialisation d'un tout autre type d'objet, et que la méthode "readObject" de ce prétendue "sun.util.calendar.ZoneInfo" permettent de faire des choses ''sympa'' que la sandbox nous interdirait :) !

Dans cet article très complet l'auteur explique qu'il remplace son objet de type zoneinfo par un objet de type ClassLoader, et qu'il en surcharge la méthode "readObject" pour attribuer "this" (i.e. son objet ClassLoader) à une variable statique afin qu'il ne soit pas garbage-collecté. En effet son objet ClassLoader devrait être garbage collecté à la fin de la tentative de désérialisation en ZoneInfo puisqu'on voit bien dans l'extrait de code que je vous ai mis que l'objet retourné n'est pas attribué à la variable "zone" si il n'est pas classe ZoneInfo valide (et du coup il ne se retrouve référencé par rien, d'où le coup de garbage collector)

Bon, ça c'est l'idée du principe de base, et nous allons devoir (hélas) nous en contenter pour l'instant parce que je n'ai pas eu le temps de creuser plus que ça :( Mais, tant pis si je me répètes : je pondrai un autre article plus détaillé dès que j'aurai eu le temps de jouer un petit peu avec tout ça (ça tombe bien, c'est un weekend de 3 jours qui s'annonce ;) ...)

Echaffaudage - Creative Common par "aleske" sur Flickr

Pourquoi ça ne buzz que maintenant ?

Easy as a pie : Comme je l'ai dit en tout début d'article ce bug est vieux1 néanmoins les applets java sont toujours autorisés par défaut sur le navigateur par défaut de MacOSX (safari) et.....et....et....et la dernière JRE Apple n'est toujours pas patché :) ! Du coup quelques chercheurs ont commencé à faire du boucan et ça suffit à faire monter un petit buzz (on le comprend aisément n'empèche...si on résume : les utilisateurs de MacOSX sont par défaut vulnérables à de l'exécution de code à distance plus de 6 mois après que la faille ait pourtant été patché sur les JRE SUN :( )

C'est quoi le rapport avec l'un de mes articles précédents ?

J'avoue que c'est un peu capilotracté mais moi en tout cas j'y ai pensé tout de suite : Vous pondez une applet qui exploite cette faille, vous en faite un GIFAR, vous uploadez ce GIFAR n'importe où sur internet (simplissime vu le nombre de forum au monde qui permettent de s'inscrire en deux secondes et d'uploader un avatar), ensuite il ne vous reste qu'à trouver un XSS sur un site quelconque pour y insérer votre applet et vous ownez tout les MacOSX qui passent :) Flipant hein ? Boah...au moins ça me permet de taquiner mes amis qui sont sous Mac et qui croient encore que OSX est "imprenable" :D !

  1. Il a même été utilisé dans le dernier Pwn2own...on fait mieux dans le genre "underground discret"

Jafar, j'suis coincé !

Par Oz le - Sécurité
GIFAR Pentest

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 !

Jafar and Iago - From "Aladdin" by Disney in 1992

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 également1.

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.

Signature - Photo Creative Common by "Luca Zappa" on Flickr

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