Si un jour vous vous ennuyez je vous conseille de partir à la découverte d'un monde merveilleux : ls /bin/¹ Vous regardez le listing et ouvrez le man des commandes que vous ne connaissez pas, ça passe le temps et perso ça m'a pas mal distrait quand j'était à l'école. En plus les connaissances ainsi acquises se sont toujours montré payante pour moi à plus ou moins long terme....Toutes, même celle de la commande "yes" ;)

Pour ceux qui ignorent ce que fait la commande "yes" je vous offre gracieusement la description issue du man : "yes - output a string repeatedly until killed". Voilà :) ....Vous tapez "yes" et hop, le programme va cracher "y"² indéfiniment sur la sortie standard. Super hein :) ? C'est typiquement le genre de commande que l'on peut découvrir en listant les répertoires de son PATH et qui me laissent perplexes. Je veux dire : je comprend bien l'utilité de la chose (certainement pour répondre "oui" en boucle lors de procédures un peu chiante ou de rm -i incontrolable) mais de là à en faire un outil standard ³...

Toujours est il que quand je suis tombé sur cette commande je me souviens m'être dit "bon, il FAUT que je lui trouve une utilité", et j'y suis parvenu. Je vous l'accorde elle est un peu capilotractée et on pourrait remplacer "yes" par beaucoup d'autres choses mais je la trouve tout de même pratique dans certaines situations et puis ça m'a permis de tirer profit de commandes (ou options) que j'avais découvert par des ls /bin. Voici donc la commande, je vous laisse la lire et essayer de deviner ce qu'elle fait, je donnerai l'explication après :

yes | cat -n | head -n 6 | shuf | cut -f 1 | head -n 1 | tr -d "\\t "

Pour réaliser cette ligne j'ai du découvrir l'option "-n" de la commande cat (que j'utilise pourtant plusieurs dizaines de fois par jour), la commande shuf, et la commande tr :) Pour information toutes sont dans "/bin" (sauf shuf) et ont donc de très vives chances d'être présentes sur presque tous les unixoïdes du monde, vous pouvez donc tester la ligne chez vous si vous n'avez pas déjà compris à quoi elle sert ;) ...Attention c'est votre dernière chance avant que je donne la solution....Plus qu'une demi ligne...Voilà : elle sert à simuler le lancer d'un dés à six faces, pratique quand on est rôliste ;) !⁴

1. Les gourous peuvent passer à la force 2 avec ls /usr/bin/ ↩
2. "y" suivi d'un retour charriot pour être précis. On peut remplacer "y" par la chaine de son choix. ↩
3. en tout cas il était présent sur toutes les distribs où j'ai regardé ↩
4. Et pour les plus taquins d'entre vous il est également possible de faire des yes "bonjour :p" | wall, ou encore des yes "salut" >> /dev/ttyX quand on est root sur une machine avec des amis dessus ↩

De toutes les origines du mot "hacker" que l'on peut trouver sur internet celle que j'accepte personnellement est celle provenant d'étudiants du MIT et qui date des années 50 (je la retranscrit de mémoire, donc sans prétention d'exactitude) : bidouilleur dont le but est d'utiliser quelque chose d'une certaine façon qui n'a pas été pensée par le reste du monde (ce qui, dans le cadre informatique qu'on connait bien, peut devenir : utiliser un logiciel pour faire des choses que ses concepteurs n'ont pas prévus...comme accéder à une zone "admin" sans avoir les droits adéquats par exemple, ça, ça n'a normalement pas été prévu comme fonctionnalité ;) ). Ce que j'aime bien dans cette définition c'est d'une part qu'elle n'implique pas de mauvaises intentions (alors qu'on en prête trop souvent aux "hackers"), et d'autre part qu'elle ne se limite pas à l'informatique. Une fois cette définition posée je vais m'amuser dans ce post à lister très brièvement plusieurs types de "hackers" certains très connus, d'autre pas du tout, et ce faisant je vais peut-être ouvrir des nouveaux horizons de bidouillages pour certains d'entre vous ;)

Informatique

Débarassons nous tout de suite du plus médiatisé des domaines de hacking : l'informatique. Ca va du gentil hack sans intention de nuire (mais tout de même borderline au niveau des licenses diverses et variées), au bon gros exploit pour prendre la main d'une machine à distance. Les sous-domaines sont nombreux : injection de code, exploitation de buffer overflow (que ça soit en heap ou en stack), d'integer overflow, de format string, de XSS (et sa variante le CSRF), de mauvais design (mots de passes transitant en clair par exemple), etc. C'est le domaine dont je parle le plus dans ce blog, du coup j'arrête là (sinon je n'aurai plus rien à dire dans les autres posts de ce blog ;) )

Social Engineering

Assez souvent associé au hacking informatique on trouve le social engineering. Il a été rendu populaire par l'usage intensif qu'en faisait l'un des plus célèbre hacker qui soit : Kevin Mitnick. En gros ça consiste à exploiter les êtres humains plutôt que les systèmes informatiques. En effet il est bien souvent infiniment plus simple de dire "bonjour, je suis l'administrateur informatique de votre entreprise, j'ai besoin de votre mot de passe pour une opération de maintenance", plutôt que d'essayer de récupérer informatiquement le hash du mot de passe en question et d'essayer ensuite de le brute forcer ^_^

La manipulation humaine est d'ailleurs bien plus ancienne que l'informatique et on la retrouve évoqué un peu partout dans la littérature, même la plus ancienne. Pour ma part je recommande le "petit traité de manipulation à l'usage des honnêtes gens" qui est, parait-il, une référence et que j'ai en tout cas dévoré :) Ou encore la lecture de blog de personnes douées dans ce domaine.

Electronique

Encore une association classique avec le hack informatique : le hack électronique. On le retrouve d'ailleurs souvent en bonne place dans les conférences sur la sécurité informatique, même dans les plus prestigieuses.

D'ailleurs je regrette d'être particulièrement mauvais dans ce domaine :( ...Quand j'aurai le temps et la motivation il faudra que je m'y penche sérieusement :)

DIYbio

Ah ah :) ! Avouez que là vous ne savez pas ce que c'est ?! Et bien moi en tout cas je ne savais pas jusqu'à il y a peu. Et le plus étonnant c'est que même en lisant les présentations de la black hat, de la defcon, du sstic, de frhack, en lisant les mailing list bugtrack et full disclosure, en feuilletant misc et parfois hakin9...c'est sur le flux RSS du journal "Le Monde" que j'ai découvert l'existence du DIYbio ! En gros, de ce que j'ai compris (mais je découvre tout juste), le DIYbio c'est un site web, mais c'est avant tout un état d'esprit proche de celui des hackers informatico/electronico/social engineerico/de tout poils, mais appliqué à la biologie. D'ailleurs "DIYbio" signifie "Do It Yourself biology". Bref dans cette mouvance on trouve des allumés qui bidouillent de la biologie dans leur garage au lieu de bidouiller des pc.

Ce qui est impressionant (et amusant à la fois) c'est que dans cette mouvance on trouve du très très très couillon, comme d'autres choses un peu plus cabalistiques pour les personnes qui, comme moi, ont arrêté la bio il y a pas loin de 10 ans ^^ (et qui ne se sont jamais attardé à apprendre le vocabulaire de la biologie ADN et du matos associé en anglais ;) ). Donc c'est rafraichissant à lire, et ça change de l'habituel ^^...Et puis moi ça m'a donné envie de m'acheter une ou deux plante pour faire des tests de pousse entre hydroponique, aéroponique, et culture traditionnelle en pot (j'avoue que j'ai bien envie de m'en acheter des comme ça depuis un moment...mais chassez le naturel et il revient au galop : rien qu'en écrivant cette parenthèse je me suis dit "tiens, et si j'interfaçai un thermomètre à mon serveur via port série afin de tracer des jolies courbes de la température de la plante et de m'envoyer des mails si elle sort de la fourchette idéale pour cette plante, en fait je n'aurai même qu'à écrire un plugin pour rrdtools . . . Incorrigible.)

Est-ce-que l'on devient parano à force d'en apprendre de plus en plus sur l'(in)sécurité informatique, ou bien est ce que l'on cherche toujours à en apprendre plus sur l'(in)sécurité informatique parce que l'on est parano ? En tout cas aujourd'hui il m'en est arrivé une belle...

Aujourd'hui donc, je profite d'avoir un peu de temps devant moi pour regarder les mises à jour disponibles pour mon pc et je trouve :

• des mises à jour de librairies obscures, elles seront mises à jour en tant que dépendances de plus gros logiciels, je n'y fais donc pas attention
• des mises à jour de logiciels que j'utilise tout les 36 du mois, je les mettraient à jour "quand j'aurai le temps"
• des mises à jour de logiciels que je considère comme "critiques" parce que je les utilise souvent et qu'ils sont assez connus pour attirer les exploits dès qu'une faille est publiée (citons par exemple firefox, thunderbird, mplayer, etc.)
• et en cadeau bonus aujourd'hui : une mise à jour du noyau est disponible (en fait elle devait l'être depuis un moment, ça faisait bien un mois que je n'avais pas fait de mise à jour sérieuse...oui je sais c'est mal)

Bon, je lance quelques mises à jours de logiciels importants, puis la mise à jour des sources de mon noyau, un petit tour dans le menuconfig, je le recompile, hop modules_update, je copie mon tout nouveau noyau tout beau tout rutilant, et je reboot enfin. Et là, au reboot, le gentil petit "tux" qui est normalement en boot logo lors de la séquence de démarrage en haut à gauche de l'écran a disparu, à sa place une espèce de taupe masquée O_O !

Du coup je cogite rapidement : je me souviens des serveurs de package de debian qui s'étaient fait rooter il y a quelques années, je remet en doute mon jugement de "gros canulard" concernant anti-sec et leur fameux "openPOWN" qui permettrait d'exploiter un 0day dans openSSH, bref je commence à jouer le parano. Du coup j'éteint mon PC, je débranche son cable réseau, et je le boot sur une backtrack live...après analyse rapide : rien de particulièrement bizarre à part ce logo...et de toute façon serais-je capable de trouver quoi que ce soit d'étrange si je m'était réellement fait rooter ? Pas sur. Du coup je boot un autre pc (sur une live clef usb...on ne sait jamais) et je commence à farfouiller sur le net à la recherche d'information sur cette "taupe masquée", après tout c'est peut être la signature d'un groupe de hack connu...Ca m'a bien pris 20mn pour trouver qu'en fait ce n'était pas une taupe mais un diable de tazmanie, et que je ne m'étais pas fait rooter du tout : c'est un logo mis en place exceptionnellement dans la version 2.6.29 du kernel linux afin de sensibiliser à la survie des diables de tazmanie...grand moment de solitude.

Hop, j'inaugure un nouveau type de post dans lequel je présente l'un des outils qu'il m'arrive d'utiliser en sécurité informatique et/ou que j'aurai aimé connaitre à un certain moment de ma vie. Pour ce premier article du genre je vais vous présenter "foremost", un outil de forensic (d'où l'image d'illustration que j'ai choisi).

foremost

Laissez moi vous raconter une petite histoire : il y a bien longtemp il est arrivé à ma copine de l'époque de graver toutes ses photos de vacances sur un DVD, puis de les effacer de son disque dur et de vider la corbeille afin de gagner de la place sur le disque. Seulement voilà : une fois les photos définitivement supprimées du disque dur impossible de lire le DVD ! Il refusait d'être reconnu sur son ordinateur, sur le mien, et sur le lecteur de salon...Je ne vous raconte pas le désespoir dans ses petits yeux à ce moment là :(

Etant du genre persévérant (et sous linux) j'ai tenté un petit "dd"¹ du DVD incriminé dans un fichier sur mon disque dur, puis j'y ai jeté un oeil "à l'arrache" (i.e. : string|less²) et j'y ai vu des séquences qui ressemblaient furieusement à ce qu'on trouve dans des en-têtes de fichiers JPG...Ni une ni deux je dégaine mes outils préférés de l'époque (à savoir VIM et GCC) et je pond un petit parser en C qui tente de repérer les en-têtes des images et des vidéos puis d'extraire les octets qui suivent pour recréer les fichiers illisibles du DVD. C'est ainsi que pendant les 2h qui ont suivi la constatation de la perte des fichiers sur le DVD je me suis retrouvé à faire des "trucs cabalistiques" ³. Et finalement, au bout de tout ce travail, petit moment de gloire quand j'ai finalement lancé un "startx" afin d'exhiber toutes les photos et vidéos que l'on croyait perdues mais que j'avais quand même réussi à récupérer "par magie" :) !

Et bien j'ai découvert, des années après, que des petits malins avaient codé sensiblement le même outil, mais sérieusement et proprement :) ! Le nom de ce petit outil c'est "foremost", il fait la même chose que ma bidouille en C (à savoir chercher des en-têtes connues dans de la donnée brute puis reconstruire le fichier) mais lui il gère un nombre impressionant de format de fichier différents (contre juste "JPEG" et "MOV" pour mon vieil outil) et il est truffé de petites options qui le rendent terriblement efficace et tout terrain. Bref : un véritable régal pour récupérer des fichiers effacés (par erreur ou pas ;) ).

Cerise sur le gateau : il est sous license GNU, vous pourrez donc en profiter avec un simple aptitude install foremost, et il est également par défaut sur backtrack 3. Mauvaise nouvelle par contre : sur ma gentoo le package est vieux et cassé, donc si vous ne voulez pas utiliser de ~x86 sur ce paquet oubliez tout de suite le emerge foremost qui vous est venu à l'esprit et allez plutôt récupérer les sources pour le compiler vous même.

Petite ouverture en guise de conclusion : foremost cherche les header mais également les footer, et en fait cette stratégie de récupération de fichier s'appelle le "File Carving". Cette stratégie est d'ailleurs assez répandue et il existe pas mal de soft de ce type, la star de la famille étant en ce moment "photorec". En deux mots photorec gère plus de type de fichiers que foremost (pour n'en citer qu'un : bz2), en revanche il n'est pas inclu dans backtrack3 par défaut (ou alors j'ai mal cherché) et il se trouve dans un paquet avec un nom à la c*n sur gentoo : testdisk.

1. Comande de copie bas niveau, un must à connaitre absolument ↩
2. Ouais, à l'époque je m'y connaissais encore moins que maintenant en forensic lol. ↩
3. il faut bien avouer que du point de vue d'une windowsienne qui n'a jamais programmé : coder du C sous VIM sans interface graphique, ça fait étrange ↩

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

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

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 ;) ...)

Pourquoi ça ne buzz que maintenant ?

Easy as a pie : Comme je l'ai dit en tout début d'article ce bug est vieux¹ 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" ↩