Par Chris Kuethe , janvier 1999
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.
_______________________________________________________________________________
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!"