Le mois dernier a débarqué un thread sur bugtraq que j'ai trouvé assez intéressant et qui, chose rare pour cette ML, s'est étalé sur plus d'une semaine sans perdre en qualité dans les interventions. Je vous propose donc de résumer ici ce qui s'y est dit, vous allez voir c'est astucieux :)

Généralement sur un unixoïde, si vous avez des fichiers confidentiels à stocker, vous allez créer un répertoire, vous donner des droits dessus, retirer tous les droits pour le reste du monde, et enfin copier vos fichiers confidentiels dans ce répertoire. Les droits de votre dossier "secret" ressemblent donc à ça :

rwx------  2 toto toto 4.0K Nov  8 18:30 secret

Une fois le dossier "secret" sécurisé de la sorte les fichiers confidentiels créés dedans le sont généralement sans prendre garde aux droits qu'on leur attribue parce que, de toute façon, personne d'autre que vous ne peut lire le contenu du dossier "secret", et ne peut donc avoir accès à vos fichiers (car personne n'a pu avoir connaissance des inodes de vos fichiers). En effet quand bien même quelqu'un d'autre que vous connaitrai le chemin complet vers l'un de vos fichiers confidentiel toute tentative d'accès à ce fichier (et donc à l'inode correspondant) échouera lamentablement car la chaine de références à suivre pour obtenir le numéro de l'inode de votre fichier s'arrêtera, pour lui, au niveau du répertoire secret :)

C'est une méthode de contournement de ce type de cloisonnement qui a été abordé dans le thread de bugtraq dont je parlais en introduction et que nous allons voir ici. En effet dans certaines circonstances (assez particulières il faut bien l'avouer) Pavel Machek a trouvé une astuce permettant d'accéder à des fichiers sur lesquels on possède des droits, bien que l'on ne possède plus aucun droit sur une partie de l'arborescence menant à ce fichier. Alléchant non ?

D'abord voyons une méthode simple et connue comme le loup blanc pour parvenir à ce résultat : le hard link. Si jamais un hardlink existe entre /secret/himitsu.txt et /tmp/foo.txt n'importe qui avec les droits d'accès sur /tmp et sur /tmp/foo.txt aura accès à /secret/himitsu.txt. En effet un hardlink référence directement l'inode du fichier. En passant par le chemin /tmp/foo.txt vous avez donc directement accès au fichier sans aucun problème :) Par contre ça ne marche pas avec le symlink ! Les liens symboliques (ln -s) fonctionnent plutôt comme des raccourcis dans le monde de windows, c'est à dire que si /tmp/foo.txt est cette fois un lien symbolique vers /secret/himitsu.txt ce qui sera pointé par /tmp/foo.txt sera le chemin /secret/himitsu.txt et non pas le fichier en lui même, il faudra donc de toute façon résoudre le chemin /secret/himitsu.txt pour obtenir accès à l'inode du fichier, ce qui n'est pas possible si vous êtes bloqué au niveau du répertoire /secret

Si vous créez vos fichiers après avoir sécurisé le dossier /secret/ vous n'avez aucun souci à vous faire : personne n'a pu accéder un jour aux fichiers contenus dans le répertoire, et donc personne n'a pu créer de hard link vers ces fichiers (car personne n'a pu avoir connaissance de leur numéro d'inodes). En revanche le problème se pose si vous sécurisez l'accès au répertoire /secret/ après avoir créé les fichiers ! Par exemple si vous créez un répertoire /journal_intime et un fichier novembre2010 dedans, que vous fixez les permissions sur /journal_intime afin que personne d'autre que vous ne puisse accéder à ce répertoire, puis que vous vous mettez enfin à rédiger votre novembre2010 en toute quiétude=. Qu'est ce qui vous dit que quelqu'un n'a pas créé un hardlink vers /journal_intime/novembre2010 avant que vous ne coupiez les droits sur /journal_intime ? Et bien à priori rien ne vous le garantie et donc il est possible que vous rédigiez tranquillement novembre2010 alors que quelqu'un d'autre que vous y accède via un hardlink qu'il aura créé rapidement ! Pour parer ce cas de figure il y a une méthode simple : ls -l, le premier chiffre apparaissant après les permission représente le nombre de hardlink existant pour chaque fichier (attention : il est impossible de créer des hardlink sur des répertoires¹, ne tenez donc pas compte de ce chiffre sur les lignes correspondant à des répertoires). Par exemple ci-dessous on voit que novembre2010 a été compromis car quelqu'un a eu le temps de créer un hardlink vers lui, et que decembre2010 n'est, lui, bien référencé que par un hardlink (certainement parce qu'il a été créé en decembre, et que l'on a sécurisé le répertoire en novembre, donc avant sa création :) )

-rw-r--r--  2 toto toto 40.0K Nov  8 18:30 novembre2010
-rw-r--r--  1 toto toto 40.0K Nov  8 18:30 decembre2010

Grace à cette méthode toute simple de vérification du nombre de hardlink on aurait donc pu se croire à l'abri, mais ça aurait été sans compter sur le thread de bugtraq dont je parlais en introduction et qui apporte un raffinement amusant à la méthode de contournement de la protection par répertoire via hardlink.

Toute la méthode de Pavel se base en fait sur la présence du pseudo filesystem /proc (et ne fonctionne donc que sous linux). Quand Pavel a décrit son astuce sur Bugtraq il l'a présenté comme une faille de sécurité causée par /proc lui même sans beaucoup plus d'explication, et de là le débat est parti pour tenter d'expliquer plus précisément le phénomène observé. Je vais donc vous présenter directement les conclusions plutôt que tout le débat².

Quand /proc est monté et qu'un process ouvre un fichier une entrée est automatiquement créée dans /proc/PID/fd/ et c'est là qu'un comportement contre-intuitif a lieu : bien que le répertoire se nomme "filedescriptor" l'entrée stockée n'est pas un filedescriptor mais un objet particulier au pseudofilesystem /proc. Là où ça devient amusant c'est que cet objet particulier se comporte comme un hardlink mais n'en est pas un ! Vous pouvez donc exploiter cette "astuce" dans un scénario complexe du type suivant :

• Alice crée un répertoire /secret avec des permissions qui autorisent Eve à y accéder
• Alice crée un fichier supersecret.txt dans le répertoire /secret avec des permissions quelconque qui autorisent Eve à y accéder en lecture seule
• Alice change les permissions de /secret pour que personne ne puisse y accéder à par elle
• Alice vérifie le nombre de Hardlink pointant sur le fichier supersecret.txt et constate qu'il n'y en a qu'un et que personne ne peux donc plus contourner la protection apportée par /secret.
• Alice change, pour d'obscure raisons, les permissions de supersecret.txt pour que tout le monde puisse y accéder en lecture/écriture

Normalement Alice est tranquille : son fichier est innaccessible, et en tout cas impossible à modifier. Mais voilà : si Eve a ouvert le fichier avant qu'Alice coupe les permissions sur /secret Eve peut toujours lire le contenu de supersecret.txt mais il y a pire encore (c'est le comportement qui avait fait tiquer Pavel) : Eve peut modifier le contenu du fichier en ouvrant simplement l'entrée stockée sous /proc/PID/fd/³ puisque cette entrée se comporte en fait exactement comme un hard link !

Amusant n'est-ce-pas ? Bon comme je vous avais prévenu c'est "exploitable" uniquement dans des contextes très très très particuliers, mais moi j'ai trouvé ça distrayant :-)

1. Sauf sour MacOS10.5 me souffle-t-on à l'oreille... ↩
2. pour les détails menant à cette conclusion référez vous au thread original (vous trouverez un lien en début d'article) ↩
3. Pavel pensait qu'il s'agissait en fait d'un vrai "filedescriptor" et que /proc permettait de le ré-ouvrir, ce qui n'est en fait pas le cas ↩

Hop étant très occupé ces temps-ci je vais me contenter de billets nettement plus court qu'à l'accoutumée, mais au moins ça vous laisse tout le loisir de creuser par vous même si le sujet abordé par l'un d'eux vous interpelle.

Pour ce premier "mini-billet-parce-que-je-suis-occupé" je vais simplement parler un petit peu d’un site web que j’ai découvert récemment (je ne sais même plus où) et qui porte l’alléchant nom de "La grotte du barbu". Pour résumer c’est un geek (barbu) qui fait des vidéos sur ses bricolages et je trouve que ses vidéos font merveilleusement écho à la définition du hack que je donnais il y a quelques semaines ! Typiquement regardez la vidéo "hacker sa cuisine", c’est dans la pure lignée de l’état d’esprit de mon billet précédant.

Le site souffre néanmoins de quelques travers comme typiquement le ratio "technicité sur durée de la vidéo" que je trouve bien trop faible. Par exemple la vidéo expliquant comment monter un mini robot dure presque 25mn alors qu’il s’agit juste de coller deux piles à deux moteurs via deux boutons inverseurs…

Bref c’est un site distrayant avec un état d’esprit que j’aime bien mais qui requiert hélas beaucoup de temps pour être apprécié et dont le niveau de technicité est très faible. C’est donc plus à voir comme une petite série donnant des idées de bricolage que comme de véritables tutoriels vidéo mais moi j'aime bien. Maintenant que vous êtes prévenus entrez donc à vos risques et périls dans la grotte du barbu !

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