Page suivante Page précédente Table des matières

11. Trouver les traces de votre cracker

Par Chris Kuethe , janvier 1999

11.1 À la loupe : trouver les traces de votre cracker

Vous vous êtes inscrits aux listes Bugtraq et The happy Hacker, vous avez acheté une version de The Happy Hacker et lu The Cuckoo's Egg de nombreuses fois. Vous avez passé un bon Noël avec l'arrivée dans votre foyer d'un modem câble et d'un petit peu d'argent. Vous vous êtes rués hors de chez vous pour faire des achats et vous avez démarré votre propre laboratoire de hacking. Une semaine après, vous remarquez que l'une de vos machines est devenue particulièrement lente et que vous n'avez plus d'espace disque. Devinez quoi : votre machine a été craquée et il est maintenant temps de réparer les dégâts. La seule manière d'être sûr de votre système est de repartir d'une sauvegarde sûre - généralement le média d'installation d'une source connue - mais penchons nous tout d'abord sur ce que le h4x0r nous a laissé à étudier.

A la fin d'octobre cette année, nous avons subi une série d'attaques sur certaines stations de travail au Département de Sciences Mathématiques de l'Université d'Alberta. Bon nombre de nos machines tournent sous une RedHat 5.1 (c'est une bonne plate-forme pour apprendre comment sécuriser un système...) car elle est bon marché et facile à installer. Les stations de travail possèdent souvent un double boot avec Windows 95 mais cela va changer car nous allons installer WinFrame de Citrix. Cet article est une étude de l'attaque d'une machine d'un enseignant.

Un jour, j'ai été prévenu que nous avions subi une nouvelle intrusion et l'heure était venue pour moi d'impressionner mes employeurs. Mais à l'instar d'un tricheur qui est obligé d'utiliser un jeu de cartes non marqué, l'avantage que j'avais à être derrière la console s'est un peu terni. Notre pirate avait utilisé un kit d'accès (rootkit en anglais) efficace et avait presque entièrement camouflé ses traces.

En général, un kit d'accès est un ensemble d'utilitaires qu'un pirate va installer afin de conserver un accès en root. Des choses telles que des versions de ps, ls, passwd, sh et d'autres utilitaires essentiels seront remplacés par des versions comportant des portes de service (backdoor en anglais). De cette manière, le pirate peut garder un contrôle sur les traces qu'il laisse. ls est remplacé par une version qui ne montre pas les fichiers du pirate et ps est modifié afin que ses processus soient également cachés. La plupart des fois, le pirate va laisser un renifleur et une porte de service cachée quelque part sur votre machine. Les renifleurs de paquets, des programmes qui enregistrent le trafic réseau et peuvent filtrer les login et les mots de passe, ne font pas partie intégrante du kit d'accès mais ils sont presque autant aimés des pirates que les versions contrefaites de ls. Pourquoi après tout ne pas essayer d'intercepter des mots de passe d'autres utilisateurs légitimes?

Dans la plupart des cas, vous pouvez considérer que la copie de ls présente sur le système ment comme elle respire. N'espérez pas trouver des fichiers suspects avec celle-ci et ne vous fiez pas aux tailles de fichier ou aux dates qu'elle mentionne : il y a une raison qui explique pourquoi les binaires d'un kit d'accès sont plus gros que d'ordinaire mais nous y reviendrons plus tard. Si vous voulez utiliser quelque chose d'intéressant, vous devrez utiliser find. find est une version intelligente de ls -RalF <w> | grep <x> | grep <y> | ... | grep <z>. Cette commande dispose d'uns syntaxe de filtrage très puissante pour permettre de spécifier avec précision où et quoi chercher. Je ne savais pas quoi chercher : tout fichier dont le nom commence par un point est un bon point de départ. La commande find / -name ".*" -ls.

Perdu au milieu d'une tonne de fichiers temporaires sans intérêt et des fichiers .choserc (fichiers de configuration à l'instar des fichiers .ini de MS-DOS), nous avons trouvé /etc/rc.d/init.d/.... Oui, avec trois points! Un point ou deux n'est pas suspect. Jouez un peu avec le DOS et vous verrez en 2 secondes que . signifie le répertoire courant et que .. désigne le répertoire parent. Ils existent dans tous les répertoires et sont nécessaires au bon fonctionnement du système de fichiers. Mais qu'en est-il de ...? Il n'a aucune raison d'exister.

Il se faisait tard, j'étais fourbu après une journée de cours et mes lentilles de contact se desséchaient, j'ai donc listé /etc/rc.d/init.d/ pour y trouver ce fichier. Je ne le voyais pas. Juste les fichiers de démarrage SysV usuels de la RH 5.1. Pour en avoir le coeur net, je suis allé dans le répertoire /tmp/foo, j'ai envoyé la date courante dans une fichier appelé ... puis j'ai essayé ls sur celui-ci. En vain. J'avais trouvé le premier binaire du kit d'accès : une copie de ls modifiée pour ne pas afficher le nom .... Je dois admettre que find serait également une cible de choix pour un remplacement mais dans le cas qui nous occupe, il était intègre et m'a fourni des informations très utiles.

Maintenant que nous savions que ... ne faisait pas partie de la distribution standard, j'y suis rentré. Il n'y avait que deux fichiers : linsniffer et tcp.log. J'ai regardé tcp.log avec more et j'ai établi une liste des personnes qui allaient recevoir la mauvaise nouvelle. ps ne faisait pas apparaître le renifleur en cours d'exécution mais ps ne pouvait pas être cru de toute manière : je devais donc m'en assurer d'une autre manière.

Nous tournions sous tcsh, une version améliorée du shell à syntaxe C, qui permet l'exécution de jobs asynchrones (en tâche de fond). J'ai tapé ./linsniffer & pour dire à tcsh de lancer le programme linsniffer dans ce répertoire. tcsh lui a donné le numéro de job #1 avec le PID 2640. Après un ps, toujours pas de linsniffer. On s'y attendait. Soit ps était compromis, soit linsniffer avait changé son nom en quelque chose d'autre. La commande ps 2640 ne mentionnait aucun processus. Cela suffisait : ps était corrompu. Et un deuxième binaire du kit d'accès de trouvé. J'ai alors tué le renifleur en cours d'exécution.

Regardons maintenant le plus évident : /etc/passwd. Il ne comportait pas d'entrée étrange et tous les logins marchaient. Ainsi, les mots de passe étaient inchangés. La seule chose étrange était que le fichier avait été modifié auparavant dans la journée. Utiliser last nous a montré que bomb s'était loggué pendant un court instant aux alentours de 2h35 du matin. Ceci était important. Personne ne s'appelle bomb chez nous!

Je suis parti chercher ma disquette de détection d'intrusion, une disquette protégée avec des binaires dont je suis sûr puis j'ai monté le CD RedHat. J'ai utilisé mon propre ls : le vrai ls fait 28k alors que celui du kit d'accès en fait 130k! Quelqu'un pourrait-il m'expliquer d'où peuvent provenir tous ces octets supplémentaires? Le programme file nous donne la réponse : exécutable 32-bit ELF petit-boutiste, Intel 80386, version 1, lié dynamiquement, non strippé. Aha! Lors de sa compilation, notre pirate a oublié de stripper le fichier. Cela veut dire que gcc a laissé toutes ses informations de déboguage dans le fichier. En fait, stripper le programme ramène sa taille à 36k, ce qui est raisonnable au vu des fonctionnalités supplémentaires (cacher certains fichiers) qui ont été rajoutées.

Vous vous rappelez que j'avais écrit que l'augmentation de la taille du fichier était importante? C'est ici que nous comprenons pourquoi. Premièrement, de nouvelles fonctions ont été ajoutées. Deuxièmement, les binaires disposent de tables de symbole pour aider au déboguage sans avoir à en inclure tout le code. Troisièmement, de nombreux fous des scripts aiment à compiler les programmes avec les options de déboguage en pensant que cela va leur donner plus de portes de service en mode debug. Ils sont certainement assez naïfs pour le penser. La copie corrompue de ls avait une table de symbole complète et le source avait été compilé à partir de /home/users/c/chlorine/fileutils-3.13/ls.c, information utile au demeurant. Nous pouvons comparer les distributions standards et les comparer à ce qui est installé de manière à obtenir des pistes supplémentaires quant à ce qui est corrompu sur le système.

J'ai ensuite pensé à aller voir les fichiers de log qui étaient, bien entendu, aussi propres que de la neige. En fait, la seule preuve d'intrusion était un trou de 4 jours. Cela dit, j'ai quand même trouvé quelque chose d'intéressant : cette machine avait les TCP wrappers d'installés. Bien sûr, ceux-ci avaient sûrement été pris en défaut compte tenu du fait que le pirate avait réussi à s'introduire sur le système. Sur une RH5.1, les TCP wrappers sont dans /usr/sbin/in.* : qu'est-ce que in.sockd fait dans /sbin? Étrange, non? J'ai étudié in.sockd avec strings et j'ai trouvé de très intéressantes chaînes de caractères telles que You are being logged (Vous êtes connecté), FUCK OFF, /bin/sh , Password: ou backon. Je doute que ceci fasse partie d'une distribution RedHat officielle.

J'ai rapidement examiné les autres TCP wrappers et j'ai trouvé que le in.rshd de RedHat fait 11k alors que celui présent sur le disque dur faisait 200k. Cela nous fait deux wrappers corrompus. Il semblerait, au vu des dates des fichiers que ce wrapper craqué est apparu le lendemain de la sortie de la RH51. Ça fait froid dans le dos, non?

J'ai également remarqué que ces binaires, bien que dynamiquement liés, utilisaient la libc5 et non la libc6 dont nous disposons. Bien sûr la libc5 existe mais rien, et j'insiste sur le rien, ne l'utilise. Son existence n'est due qu'au besoin de compatibilité descendante. Après avoir examiné en détail les autres binaires, j'ai remarqué qu'ils utilisaient aussi la libc5. C'est ici que strings et grep (ou un pager) prennent tout leur sens.

Maintenant, je suis fatigué de chercher à la main, on va donc quelque peu élargir notre champ de recherche en utilisant find. Essayons tout ce qui a comme date Octobre de cette année... Je doute que notre pirate soit de la race des gens patients, à ce qu'en laisse voir ses erreurs pour le moment, son intrusion ne doit donc pas dater d'avant le début du mois. Je en prétends pas être un maître de la syntaxe de find, j'ai donc fait ce qui suit : 

find / -xdev -ls | grep "Oct" | grep -v "19[89][0-7]" > octfiles.txt

En français : à partir de la racine et sans regarder sur les autres disques, afficher tous les noms de fichier. Passer cela à grep pour qu'il filtre tout mis à part Oct, puis à un autre grep qui va filtrer les années auxquelles nous ne nous intéressons pas. Pour sûr, les années 80 nous ont donné de la bonne musique (Depeche Mode) et de bons morceaux de code (UN*X/ BSD) mais ce n'est pas le moment d'étudier l'histoire.

Un des fichiers trouvés par le find était /sbin/in.sockd. Il est intéressant de noter que ps rapportait qu'il y avait un processus sans nom avec un PID assez faible (76) de propriétaire d'uid=0 et de gid=26904. Ce groupe n'existe pas ici : qui cela peut-il être? Et comment ce fichier a-t-il pu être lancé aussi tôt pour avoir un PID aussi faible? In.sockd a ce couple uid/gid... Il doit être lancé par l'un des scripts de démarrage puisque ce processus est présent au démarrage comme l'indique ce PID faible. En passant le fichier rc.sysinit à travers grep pour chercher in.sockd, les deux dernières lignes de ce fichier sont les suivantes : 

#Start Socket Deamon
exec in.sockd

Bien sûr... cela ne fait pas partie de l'installation normale. Et Deamon est mal épelé. Devrait-on pour autant utiliser un correcteur orthographique comme détecteur d'intrusion? En effet, RedHat n'est pas connue pour des docs peu claires et des tonnes de fautes d'orthographe mais il est possible d'ajouter des mots à un dictionnaire. Ainsi, notre pirate a essayé d'installer une porte de service et de la déguiser en la camouflant avec d'autres programmes de même nature. Cela ajoute de la crédibilité à ma théorie que notre pirate a pour le moment restreint ses talents à des recherches sur les réseaux de failles connues.

Le second démon contaminé était rshd. Environ 10 fois aussi grosse que la version standard : il doit être capable de tout. Que veut dire rsh ici? RemoteSHell ou RootShell? Votre choix vaut le mien.

A ce stade, nous avons trouvé des versions corrompues de ls, ps, rshd et in.sockd et cela ne fait que commencer. Je suggère qu'après avoir terminé la lecture de cet article, vous alliez chercher sur le web un kit d'accès afin de savoir ce qu'ils font pour pouvoir les contrer. Vous devez savoir quoi chercher pour être en mesure de l'enlever.

Alors que les fichiers de log avaient été nettoyés, la console comportait toujours des messages d'erreur, dont certains après 2h35.L'un d'entre eux était un refus de donner l'accès en root sur / via nfs à 2h46. Cela coïncidait parfaitement avec le dernier accès en date à la page de man de NFS. Ainsi notre pirate avait-il trouvé une option intéressante et avait essayé de monter le système de fichiers de cet ordinateur via NFS mais il ne s'y était pas pris correctement. Je serais tenté de dire que tous les pirates font des erreurs. S'il faisaient tout avec perfection, nous ne les remarquerions jamais et il n'y aurait pas de problèmes. Mais ce sont les problèmes qui proviennent de leur erreurs qui peuvent nous causer du souci. Vous devez donc lire vos manuels. Plus vous connaissez votre système, mieux vous en décèlerez les aspects anormaux.

Une aspect utile de NFS pour stopper un pirate est que si le serveur s'arrête, tous les clients NFS avec des répertoires encore montés vont se bloquer. Vous devrez relancer la machine pour vous rétablir. Hmmm. Cela est une idée d'outil intéressante : écrire un script de détection de piratage qui, dans le cas où une machine distante essaye de pénétrer le système, désactive cette interface par ifconfig. Ceci dit, cela peut entraîner un refus de service si des utilisateurs autorisés sont déconnectés. Mais cela est utile pour empêcher la mise en péril de votre station de travail.

Arrivé à ce point, j'ai arrêté. J'ai appris ce que je m'étais proposé d'apprendre : comment retrouver les traces que laisse un pirate. Compte tenu du fait que le propriétaire de la machine avait tous ses fichiers sur média amovible (qui avait été retiré), il n'y avait aucun risque de mise en péril de ses données. Le répertoire ~janedoe était un disque Jaz monté qui était retiré pour la nuit. Il m'a donc suffi de mettre le CD dans le lecteur et de réinstaller. C'est la raison pour laquelle il faut conserver les fichiers des utilisateurs sur une partition séparée, et c'est pourquoi il faut conserver des copies de sauvegarde et garder en sécurité l'endroit où trouver les sources des programmes installés si vous ne pouvez conserver les archives d'origine.

Nous avons maintenant accumulé assez de preuves : il est temps de trouver une parade. Pour aller dans le sens des avertissements de Meinel dans The Happy Hacker quant au fait que vous pourriez en pâtir et que vous pourriez même aller en prison, je ne vous recommande pas d'essayer de pirater le système de l'intrus. Au Canada, le RCMP (i.e Royal Canadian Mounted Police à savoir la Police Montée Canadienne) a fini de pratiquer la politique de l'autruche. Je ne suis pas avocat : ne faites donc rien par vous-même qui soit basé sur cet article, si ce n'est aller un trouver un avocat. Ceci dit, il va de soi que nous sommes pointilleux chez nous sur la protection de la propriété. En plus de prendre un avocat, mon conseil est d'appeler la police. Les gens de la RCMP, du FBI, du BKA, du MI-5 ou du KGB sont prêts à recevoir tout appel amical, particulièrement si vous cherchez à savoir comment être un bon citoyen. Il se peut qu'ils aient de bons conseils à vous donner ou au moins de bons éléments à considérer. De plus, vous aurez quelqu'un pour vous aider à conduire votre procès.

Mes contacts avec l'Unité des Crimes Commerciaux de la RMCP (qui s'occupe également des abus de ressources réseau et/ou informatiques) se résument à cela : l'e-mail n'a aucune ambition de confidentialité. Vous pensiez que l'e-mail était secret et vous découvrez soudainement qu'il est plus dangereux qu'une carte postale. En tant qu'administrateur système, vous pouvez faire ce que vous voulez de votre ordinateur - dans la mesure où soit il vous appartient soit vous en êtes l'utilisateur attitré - dès lors que vous pensez à avertir les utilisateurs. Ainsi, je peux surveiller chaque bit que mes utilisateurs émettent ou reçoivent compte tenu du fait qu'ils en ont été avertis verbalement, électroniquement et par écrit de mon intention de le faire. Mon parcours sur le site web du FBI m'a montré que je n'étais pas le seul. Ne vous mettez pas en marge des lois concernant l'interception des communications électroniques. 

NOTE:
        Bien que j'ai essayé de faire une reconstitution des
        évènements aussi précise que possible, il est possible que
        j'ai mal lu une entrée de log ou que j'ai mal interprété
        quelque chose. Par ailleurs, cet article ne reflète que mon
        opinion et ne saurait être considéré comme la position
        officielle de mon employeur.

11.2 Appendice A : les programmes utiles dans un kit de détection d'intrusion

  • find, ps, ls, cp, rm, mv
  • gdb, nm, strings, file, strip
  • (GNU)tar, gzip, grep
  • less / more
  • vi / pico
  • tcsh / bash / csh / sh
  • mount
Pour des raisons de sécurité, ils devraient tous être liés statiquement.

11.3 Appendice B : Références

_______________________________________________________________________________

Copyright © 1999, Chris Kuethe

Publié dans le n°36 de la Linux Gazette, janvier 1999.

Adaptation française de Pierre Tane

"Linux Gazette...making Linux just a little more fun!"

Page suivante Page précédente Table des matières